Lasta Di

Japanese page here.

Lasta Di とは?

simple DI container for LastaFlute, forked from Seasar as Java8

GitHub Page

is there:

Two components

Quick component
convention registration, hot reloading (prototype)
Rich component
flexible manual registration (singleton)

How to inject

Both components can be injected by @Resource annotation.

e.g. injection definition @Java
@Resource
private AbcLogic abcLogic;

Quick component

Application's business logics, are prototype e.g. Action class, Logic class...

Convention provides auto regsitration:

Package
[your domain].app (e.g. com.example.app)
Class Name
e.g. app.web.AbcAction, auto regsitered as Action to Lasta Di

Class name suffixes are e.g. following:

Action
...app.web.AbcAction
Form
...app.web.AbcForm
Assist
...app.web.AbcAssist (or ...app.assist.AbcAssist)
Logic
...app.logic.AbcLogic
(Others)
AbcValidator, AbcConverter, AbcHelper, AbcService
e.g. Quick components @Directory
com.example
 |-app // application package
 |  |-logic
 |  |  |-AbcLogic
 |  |-web // web package
 |     |-AbcAction
 |     |-AbcForm
 |-bizfw
 |-dbflute
 |-mylasta

And these components can be hot-reloaded so you don't need to reboot in local development. So you can get quick trial-and-error programming with Lasta Di.

Rich component

Application's common classes, are singleton e.g. Manager class

Package
[your domain].bizfw (e.g. com.example.bizfw) *actually free but recommended
Class Name
e.g. bizfw.AbcManager, basically you can set free name

You can register by your Di xml app.xml flexibly.

e.g. Rich components @Directory
|-src/main/java
|  |-com.example
|    |-app
|    |-bizfw *recommended package for rich components
|    |  |-AbcManager
|    |-dbflute
|    |-mylasta
|-src/main/resources
   |-app.xml *your Di xml, you can regsiter here
e.g. Di xml @app.xml
<components>
    <include path="convention.xml"/>
    <component name="abcManager">...bizfw.AbcManager</component>
</components>

Lightening Boot

Simple logic in Lasta Di, speed is prior.

And following features:

Small dependencies
Javassit, JTA, Slf4j (only three)
Lazy Loading
Minimum initialization in (in hot, warm)

ConnectionPool (DBCP)

Implementation

Lasta Di has the original connection pool, which can handle transactions.

ConnectionPool
interface of connection pool, checkOut(), checkInTx()
SimpleConnectionPool
simple implementation of connection pool
PooledDataSource
data source using connection pool

if you use Lasta Di with LastaFlute, you can use the extended implementation classes which have more rich functions. (e.g. HookedConnectionPool, HookedPooledDataSource)

Transaction

Implementation (for Architect)

Lasta Di has the original JTA implementation, which is related to connection pool.

LaTransactionManager
simple implementation of TransactionManager interface
LaUserTransaction
simple implementation of UserTransaction interface
LaTransaction
simple implementation of Transaction interface

if you use Lasta Di with LastaFlute, you can use the extended implementation classes which have more rich functions. (e.g. HookedTransactionManager, HookedUserTransaction, RomanticTransaction)

javax.transaction.Transactional (for Developer)

javax.transaction.Transactional is supported. You can use it as default in several Quick component (e.g. Logic, Service).

However if you use Lasta Di with LastaFlute, you can use the TransactionStage interface provided by LastaFlute which is programatic transaction. So the annotation may be small use.

Attention, the annotation process is implemented by interceptor (AOP) so you can use it at public method. And Lasta Di can support "this" call of AOP so you can use the annotation in the same class.

e.g. Transactional annotation use @Java
@Transactional
public void registerMember() {
    ...
}

(While, if you use LastaFlute, you can use the interface TransactionStage instead of the annotation)

lasta_di.properties

Application settigs for Lasta Di.

e.g. lasta_di.properties is here @Directory
|-src/main/java
|  |-com.example...
|-src/main/resources
   |-app.xml
   |-lasta_di.properties
smart.deploy.mode.location (optional: cool as default)
e.g. abc_env.properties: lasta_di.smart.deploy.mode
Settings for smart deploy mode (hot, warm, cool). e.g. hot provides you quick programming in development. While, cool should be set in production.
smart.package1 (basically required)
e.g. com.example.app
Settings for application package treated as smark deploy.
You can set smart.package2, and 3...

Di xml

Di xml Overview

You can register your components in app.xml.

e.g. app.xml is here @Directory
|-src/main/java
|  |-com.example...
|-src/main/resources
   |-app.xml
   |-lasta_di.properties

You can get rich components by setting comopnent tags with your classes.

e.g. settings for rich components @app.xml
<components>
    <!-- settings for rich components -->
    <component name="abcManager">...bizfw.AbcManager</component>
    <component name="stuManager">...bizfw.StuManager</component>
    <component name="xyzManager">...bizfw.XyzManager</component>
</components>

You can get quick components by including convention.xml.

e.g. settings for rich components @app.xml
<components>
    <include path="convention.xml"/> <!-- needs for quick components -->

    <!-- settings for rich components -->
    <component name="abcManager">...bizfw.AbcManager</component>
</components>

You can get library components provided from frameworks, e.g. LastaFlute, DBFlute, by including their xml.

e.g. Di xml @app.xml
<components>
    <include path="convention.xml"/>
    <include path="dbflute.xml"/>
    <include path="lastaflute.xml"/>

    <component name="abcManager">...bizfw.AbcManager</component>
</components>

Di xml Hierarchy

Embedded xml in Lasta Di are colored:

e.g. Di xml Hierarchy, embedded is colored @app.xml
...Reading lasta_di.xml
...Reading   redefiner.xml
...Reading   smartdeploy.xml
...Reading     smart/hotdeploy.xml
...Reading       convention.xml
...Reading         embedded_convention.xml
...Reading       creator.xml
...Reading         convention.xml (recycle)
...Reading         customizer.xml
...Reading           lastafw_customizer.xml
...Reading           embedded_customizer.xml
...Reading             tx_customizer.xml
...Reading         lastafw_creator.xml
...Reading           convention.xml (recycle)
...Reading           customizer.xml (recycle)
...Reading         embedded_creator.xml
...Reading           convention.xml (recycle)
...Reading           customizer.xml (recycle)
...Reading       customizer.xml (recycle)
...Reading app.xml
...Reading   convention.xml
...Reading     embedded_convention.xml
...Reading   dbflute.xml
...Reading     rdb.xml
...Reading       jta.xml
...Reading         jta+userTransaction.xml
...Reading         jta+transactionManager.xml
...Reading       jdbc.xml
...Reading         jta.xml (recycle)
...Reading         lastaflute_assist.xml
...Reading           lastaflute_director.xml
...Reading       tx_aop.xml
...Reading         jta.xml (recycle)
...Reading   lastaflute.xml
...Reading     lastaflute_core.xml
...Reading       lastaflute_assist.xml (recycle)
...Reading     lastaflute_db.xml
...Reading       jta.xml (recycle)
...Reading     lastaflute_web.xml
...Reading       lastaflute_core.xml (recycle)
...Reading       lastaflute_db.xml (recycle)
...Reading       convention.xml (recycle)

Di xml Expression

Using JavaScript engine 'Nashorn' as expression parser.

Redefiner

Yon can customize embedded Di xml.

Switch Di xml Wholly
e.g. sea+.xml: switch Di xml wholly
Copy the original Di xml to the redefined Di xml and fix it.
Switch Component
e.g. sea+mystic.xml: switch the embedded 'mystic' to the defined 'mystic'
No need to define 'namespace' and 'include' in the redefined Di xml.
This is the most useful.
Remove Component
e.g. sea+mystic.xml: nothing defined means removing embedded 'mystic'
Add Component
e.g. sea++.xml: the defined components are added to embedded Di xml as low priority
e.g. ++sea.xml: the defined components are added to embedded Di xml as high priority
e.g. switch component 'userTransaction' fixedly @Directory
|-src/main/resources
|  |-app.xml
|  |-jta+userTransaction.xml // userTransaction is switched fixedly

// lasta-di.jar contains jta.xml, which has component 'userTransaction'
e.g. switch component 'mystic' in unit test @Directory
|-src/main/resources
|  |-app.xml
|  |-sea.xml // in production
|
|-src/test/resources
   |-sea+mystic.xml // mystic is switched in unit test

Major Classes

SingletonLaContainer
has your components
ConnectionPool
manages database connections

Maven Repository

See github page.

If you use LastaFlute, you don't need Lasta Di dependency because LastaFlute depends it.

Code Reading Hint

Lasta Di Boot World

Lasta Di Boot World

Thanks, Frameworks

Lasta Di is forked from Seasar, and inherits it, thankful wonderful functions.

And also forked from S2ClassBuilder (called Redefiner in Lasta Di), provides flexible Di xml.

Thanks.