This blog picks up on some unfinished items mentioned in the first blog. More specifically, this blog will focus on:

• auto-injecting session beans;
• entity-only bundles;
• transaction rollback.

Note that if the reader wants to run the example source, he or she is referred to the aformentioned previous blog in which more information on setting up the environment and getting the sources to compile/run can be found. To get the samples running, you always need to start ezb-command.jar and entitybeans.jar. Besides those 2 bundles, you either need to start combinedbean.jar (includes 2 stateless beans) or statelessbean1.jar and statelessbean2.jar (both bundles contain 1 stateless bean).

Auto-injecting session beans

In EJB3 (and therefore also in EZB) it is possible to inject a reference to a session bean through using the ‘@EJB’ annotation. When using this annotation, you can supply the product-specific name of the EJB to which it should be mapped (could be any kind of name – even though it is often a JNDI one). As it turns out, EZB almost completely supports this feature; both when the EJB to be injected is defined within the same bundle (use combinedbean.jar) and when it is defined in a different bundle (use statelessbean1.jar and statelessbean2.jar) the reference is injected properly and no lookup takes place:

    @EJB(mappedName="SL2")
    private Stateless2Remote m_stateless2 = null;

    @EJB
    private Stateless2Remote m_stateless2NotAutoInjected = null;

    // ... and some code using it:

    if (m_stateless2 == null) {
        // '@EJB' injection did not take place, performing lookup
        try {
            m_stateless2 = (Stateless2Remote)new InitialContext().lookup(
                String.format("%s_%s@Remote", "net.luminis.ezb.stateless2.impl.Stateless2Impl", Stateless2Remote.class.getName()));
        } catch (NamingException e) {
            e.printStackTrace(); // lookup failed.
        }
    }

Note though, that the mappedName must be set both here and in the implementation of the session bean to be injected. If this is not done, EZB cannot find/inject it. I.e. in the code above, at the point where m_stateless2 has been set, the member variable m_stateless2NotAutoInjected is still null.

Entity-only bundles

When deploying ones bundles you’re likely to combine related functionality. It’s possible to simply put everything in a single bundle, but not desirable; the more fine-grained your design, the easier it is to re-use a specific bit of functionality. When you decide to define an entity-only bundle, EZB requires that you include the line

net.luminis.ezb.entitybeans.Kangaroo

both in persistence.xml of the entity-bundle, but also in all bundles using the entity-bundle. This inconvenience may be corrected, but for now, it’s not a very flexible way of working; when you add an entity bean to your entity-bundle, you not only have to update the persistence.xml in that bundle, but also in all bundles using it!

Rollback

Finally, the source code attached to this blog also includes an example of how EZB handles a transaction rollback. It is possible to trigger such a rollback by using:

m_sessionContext.setRollbackOnly();

to signal the session to perform a rollback of every action associated with the current transaction. In this example the functionality is illustrated through using the command

ezb use_injected_max

which not only uses an injected session bean to create a Kangaroo entity, but also triggers a rollback if 4 Kangaroos have already been created. (Check the methods addKangaroo() and addKangarooWithMaximumCheck() in Stateless2Impl to find out more.