As an enthusiast and grateful OpenEJB user, I figured in addition to cutting over my projects to use the new release, I'd post something at J.N about it in case others are interested. Here are the truncated release notes from their user mailing list.

Download binaries here:

http://openejb.apache.org/download.html
(check http://cwiki.apache.org/OPENEJB/openejb-30.html of the above page hasn't synched yet)

Apache OpenEJB 3.0 Release Notes

New Features:

* [OPENEJB-769] Dependency Injection of Enums
* [OPENEJB-768] Dependency Injection of Collections and Maps using Java Generics
* [OPENEJB-758] @EJB references to local interfaces in other ears
* [OPENEJB-777] Transaction Logging
* [OPENEJB-788] Host based authorization on remote client requests

Improvements:

* [OPENEJB-784] Improved support for annotation inheritance
* [OPENEJB-787] Improved client request thread pooling and backlog control
* [OPENEJB-760] Improved Circular and Lazy EJB reference resolution between ears
* [OPENEJB-764] New openejb.validation.output.level property settable to TERSE, MEDIUM, or VERBOSE
* [OPENEJB-763] Auto create non-jta-data-source as a clone of jta-data-source and vice versa
* [OPENEJB-756] Allow CMP2 ejbSelect returning void for UPDATE and DELETE queries
* [OPENEJB-759] Improved and expanded EJB reference resolution
* [OPENEJB-215] Passivation/Activation of non-Serializable Stateful SessionBeans
* [OPENEJB-770] Validation: Bean class with no Interfaces
* [OPENEJB-775] Validation: Bean-class-only annotations not used on interfaces
* [OPENEJB-773] Validation: Combined use of @Stateless @Stateful and @MessageDriven on same class
* [OPENEJB-774] Validation: Component and Business Interfaces are interface types
* [OPENEJB-771] Validation: Use of @Stateless, @Stateful or @MessageDriven on an interface or abstract class
* [OPENEJB-779] Validation: Conflicting use of @RolesAllowed, @PermitAll on a class
* [OPENEJB-780] Validation: Conflicting use of @RolesAllowed, @PermitAll, @DenyAll on a method
* [OPENEJB-781] Validation: Timeout method syntax
* [OPENEJB-770] Validation: Bean class with no Interfaces
* [OPENEJB-771] Validation: Use of @Stateless, @Stateful or @MessageDriven on an interface or abstract class
* [OPENEJB-773] Validation: Combined use of @Stateless @Stateful and @MessageDriven on same class
* [OPENEJB-774] Validation: Component and Business Interfaces are interface types
* [OPENEJB-775] Validation: Bean-class-only annotations not used on interfaces

Bugs:

* [OPENEJB-767] Paths with spaces may result in "Unable to scrape for @Stateful, @Stateless or @MessageDriven annotations"
* [OPENEJB-778] Application in apps dir are sometimes not loaded at startup
* [OPENEJB-607] Cannot access server(s): null:-1 when InitialContext.PROVIDER_URL is hostname not IP address
* [OPENEJB-766] EJBs and persistence units in a web application nested in an ear are not detected
* [OPENEJB-765] POJO webservices broken in Tomcat initialized with OpenEJBListener
* [OPENEJB-782] RollbackException swallowed in TransactionPolicy
* [OPENEJB-700] Must have java.sun.com access when online to deploy: Cannot unmarshall the ejb-jar.xml file
* [OPENEJB-761] Tomcat EAR double deployment
* [OPENEJB-750] EJB 2 Entity bean with CMP field mapped to CMR field causes ClassFormatError
* [OPENEJB-717] ServiceRef converts JAX-RPC handlers into JAX-WS handlers
* [OPENEJB-762] CMP finder with no results: NullPointerException in TransactionPolicy.logSystemException()
* [OPENEJB-754] Print out the provider in Configuring PersistenceUnit(name=testFacadePu, provider=null) log message
* [OPENEJB-757] JavaAgent upgrade/uninstall with Tomcat

Clearly these objects all would benefit from having a name, description and ID field. But consider these as well: joule, watt, newton. Now, the first three units were SI base units. The second three can be defined in terms of the first three. For example, a newton is equal to m∙kg∙s⁻². So it becomes clear that units need to be able to be defined according to an underlying terminology.

So, let's say we have a Term class, with a coefficient, a radix and an exponent. The newton Unit instance would now contain a List of three Term instances. The first term has a coefficient of 1, a radix of the "meter" instance, and an exponent of 1. The second term is much like the first, save for the fact that its radix is equal to the "kilogram" instance of the Unit class. The third follows a similar pattern, but in addition to referencing the "second" Unit instance, it also has an exponent of -2.

Now, for consistency and convenience, we'll define base units in terms of themselves. So, a "meter" instance contains a list of one Term, with a coefficient of 1, a radix of the "meter" instance, and an exponent of 1.

Finally, we can also give the Unit class a boolean field, in order to distinguish between base units and derived units. This very basic definition of units and terms will suffice for what I'm trying to explain.

Now, so far, we have two entities, Unit and Term, and a very simple Many-to-Many relationship between them. But here's where the trouble starts.

Part of the purpose of capturing the concept of a Unit in an object-oriented manner is so that we can use them to create constraints on logical behavior that are more rich and efficient than we'd be able to accomplish were they mere text fields. We also want to capture, in some way, the relationships between different units.

To illustrate the first point, consider that you're writing an application where you want to add together a collection of units to determine their sum total. Now, imagine your assumption is that you're trying to get a combined measurement of mass. If you have an object that represents "3 kilograms" and another that represents "5 kilograms" you can easily accomplish this. But what if in addition to these, someone slipped in an object representing "4 seconds"? What is 3kg + 5kg + 4s?

Now we're dealing with dimensional analysis. There are rules that stipulate, you cannot add these together. It'll break your logic. So, what you want to do--what you need to do, is to somehow capture the idea that your "kilogram" units are tied to the concept of "mass", that your "second" objects are tied to the concept of "time", that your "tesla" objects are tied to the concept of "magnetic flux density", and so forth.

But what are these concepts "time", "mass", "magnetic flux density", "photoelastic work", "molar entropy", and so forth? Well, it turns out there is some fog in the answer to that question. Depending on which poorly written wikipedia article you find, these concepts are collectively called "quantities", "dimensions", "magnitudes" or even "quantitative properties of particles". It turns out there is no highly rigorous name for them, but since Object-Oriented programming is nothing if not nominalist and aristotelian in nature, they needed to be named. In order not to limit my future use of the above terms, I decided against adopting any of them and named these objects according to their relationship to the Unit. Since these concepts serve to limit the scope of what the unit can be used to quantify, I refer to them as the Quantitative Scopes of a unit. Please, if you're a physicist studying dimensional analysis, don't be upset.

Because, whatever these are called, we are now straying into trouble with Java. Case in point, how does one best represent a quantitative scope?

Well, generics give us one tantalizing option. I'd like to be able to create a new Unit<Mass>(), and keep it in a Set<Unit<Mass>>. I think this would afford me with the best and easiest way to constrain the use of these units. However, that leaves us with the difficult problem of how "Mass" is represented.

We have only two options here. Class or Interface. Class is problematic, because every instance of "Mass" would be identical to every other. So, it makes more sense to use Interfaces. Ah, but herein lies the rub, because our original goal was to make these objects persistent. And Interfaces, bless their bytecode, certainly do not fit this bill.

So, it seems objects are the only option. But this, once again, leaves us with the problem of instance control. I could rattle off 126 examples of a QuantitativeScope object, each differing from the other only in name. But if we define each as a class, then presumably we'd have 126 database tables filled with carbon copied records, which is just not going to happen. Thus, the quandary. Interfaces cannot be made persistent, but classes are the wrong instrument to accomplish the goal.

Well, what about enums? It's an idea--an enum would nicely solve the persistence problem, but it doesn't save us on the application layer because enum-valued objects cannot be used in generic fields. Furthermore, enum-valud objects cannot be given generic fields themselves. This makes sense, given what enums are for, but it leads us back to the same problem. How, given all three of these tools, are we to accomplish the goal of being able to discriminate easily between units of different quantitative scope while not abandoning the ability to persist the objects?

I came up with an ugly hack to solve this problem. The good news is that it makes the best use of the available technology that I'm able to determine. The bad news is that it's an ugly hack and it fills me with doubt about Java and JPA. But I'm invested in making this work, so here goes:

First, I created a "Scope" enum, with 126 different values in it. Scope.Mass, Scope.Time, etc. Then, I made 126 corresponding interfaces, "Mass", "Time", etc., that extend a base "QuantitativeScope" interface. Third, I made a generified "Graft" class that serves to bind one of these interfaces "Q extends QuantitativeScope" to one of these enum-valued objects. Finally, I defined a library class containing 126 public abstract final instances of this "Graft" class, each mapped to the appropriate "Scope" enum-valued object. With these graft instances, I was set.

Now, when defining a Unit, I can pass one of these "Graft" objects to the UnitFactory. It can get both the generic type from this Graft object, and assign the Graft.getScope() enum-valued object to a "scope" field in the Unit class. When I persist the Unit into JPA, the "scope" field, which is defined as @Enumerated(EnumType.STRING), goes into the database. When I get a collection of Unit objects back out of the database, I can run them through a seive and inspect each of their Unit.getScope() values in a switch statement, then place them into appropriately generified Set objects. This piece works sort of like a coin sorter, but when I'm done I can ask for the Set<Unit<Mass>> and know that my results are reliable.

The main problem with this workaround is that I had to duplicate a lot of data and encase it into interfaces, a large enum, and a graft object library in order to make it function. There are other lingering problems with this approach as well, and I'm sure that I'll uncover more and more of them as I continue.

What this has taught me is that enums and generics are exceedingly tricky to use. Although with generics, Types can now be used as compile-time constraints on behavior, they don't help you at runtime, and are therefore tough to work into a persistence application. This worsens the intrinsic impedence mismatch between the application layer and the persistence layer in application design. Further, enums in Java behave like pseudotypes, somewhere between Interfaces and Classes, but because they cannot be used as Generic Types, they even further aggravate the impedence mismatch when worked into a persistent application design. If I could have used the enum valued objects in the generic fields, this would be a non-problem.

Finally, the best solution for my particular problem might have nothing to do with enums or generics after all. What I'm trying to replicate through this design is actually Invariants, Preconditions and Postconditions on method behavior, class definitions, and collection compositions. There are languages such as VDM-SL and Eiffel that wonderfully exemplify this sort of language feature, and old tools such as iContract that might make it useful in Java, but it's a shame that these useful tools are not built into the language itself.

Neither option is attractive. Lesson learned.

As my software engineering professor Mats Heimdahl would sagely advise, "It depends."

The truth is that regardless of how big or small your transactions are, it's easy to get them wrong, and you need to do them correctly each time in order to guarantee that your application and tests perform and behave in a predictable manner. So, if you can abstract this element of your software, you are likely to be much better off.

To make a long story short, David showed me a pattern that I found indespensable for testing, because it mimics the lambda capabilities of languages like LISP.

Here's a look.

I have a base testing class that contains infrastructure for my tests. It looks something like this:

package org.eremite.corm.party.testutil;

import junit.framework.TestCase;
import org.eremite.corm.Archetype;

import javax.annotation.security.RunAs;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.naming.Context;
import javax.naming.NamingException;
import java.util.Iterator;
import java.util.Set;
import java.util.concurrent.Callable;

public abstract class CascadeTestBase extends TestCase {

    protected Context context = ContextFactory.reference();
    protected BeanManager mgr;

    public void setUp() throws Exception {
        super.setUp();
        mgr = (BeanManager) context.lookup(
            "BeanManagerLocal");
    }

    public void tearDown() throws Exception {
        super.tearDown();
    }

    protected static void traceln(Object... o) {
//        for(Object item : o) System.out.println(item);
    }

    protected boolean hasArchetypeWithID(Set s, long ID) {
        Iterator<Archetype> iter = 
            (Iterator<Archetype>) s.iterator();
        while (iter.hasNext()) {
            Archetype a = iter.next();
            if (a != null && a.getID() == ID) return true;
        }
        return false;
    }

    protected Archetype getArchetypeWithID(Set s, long ID) {
        Iterator<Archetype> iter = 
            (Iterator<Archetype>) s.iterator();
        while (iter.hasNext()) {
            Archetype a = iter.next();
            if (a != null && a.getID() == ID) return a;
        }
        return null;
    }

    protected void clear(String... tables) {
        for (String table : tables) mgr.clear(table);
    }

    public class Retriever<A extends Archetype> {
        private String table;
        private long ID;

        public Retriever(String table, long ID) {
            this.table = table;
            this.ID = ID;
        }

        public A fetch() {
            ExtendedBeanManager<A> mgr = null;

            try {
                mgr = 
                    (ExtendedBeanManager<A>) 
                        context.lookup(
                            "ExtendedBeanManagerLocal");
                            
            } catch (NamingException e) {
                e.printStackTrace();
            }

            return mgr.find(table, ID);
        }

        public A fetchWith(String column) {

            ExtendedBeanManager<A> mgr = null;

            try {
                mgr = (ExtendedBeanManager<A>) 
                    context.lookup(
                        "ExtendedBeanManagerLocal");
            } catch (NamingException e) {
                e.printStackTrace();
            }

            return mgr.findAll(table, column, ID).
                iterator().next();
        }
    }

    // - - - - - - - - - - - - - - - - - - - - - - - - - - -
    //  Courtesy of David Blevins from the OpenEJB project
    //  These beans will get picked up if you have an empty
    //  src/test/resources/META-INF/ejb-jar.xml
    //  file which simply contains the text "<ejb-jar/>"
    // - - - - - - - - - - - - - - - - - - - - - - - - - - -

    public static interface Caller {
        public <V> V call(Callable<V> callable) 
            throws Exception;
    }

    @Stateless
    @TransactionAttribute(
        TransactionAttributeType.REQUIRES_NEW)
    public static class TransactionBean implements Caller {
        public <V> V call(Callable<V> callable) 
            throws Exception {
            return callable.call();
        }
    }

    @Stateless
    @RunAs("manager")
    public static class SecureBean implements Caller {
        public <V> V call(Callable<V> callable) 
            throws Exception {
            return callable.call();
        }
    }

    @Stateless
    @RunAs("manager")
    @TransactionAttribute(
        TransactionAttributeType.REQUIRES_NEW)
    public static class SecureTransactedBean 
        implements Caller {
        public <V> V call(Callable<V> callable) 
            throws Exception {
            return callable.call();
        }
    }

    public void testTransaction() throws Exception {
        Caller transactional = (Caller) 
            context.lookup("TransactionBeanLocal");
        for(Callable item : getCalls()) {
            transactional.call(item);
        }
    }

    // Test cases are required to implement this method.
    public abstract Callable[] getCalls();
}

Note, most importantly, the enterprise beans at the bottom. One of them, "TransactionBean", is the one I use in my test classes to actually perform my transactions.

Now, for the sake of brevity, I'm going to refrain from describing the data model that I'm testing. For now assume it's a commercial object-relational model that closely obeys the principle of least astonishment, and that every entity extends a managed superclass "Archetype". Also, without going into the implementation details, here is the interface definition for the BeanManager class used in the class above:

package org.eremite.corm.party.testutil;

import org.eremite.corm.Archetype;

import javax.ejb.Local;
import java.util.List;

@Local
public interface BeanManager<A extends Archetype> {

    public long persist(Archetype a);
    public void merge(Archetype a);
    public void remove(Archetype a);
    public long sizeOf(String table);
    public void clear(String table);
    public void flush();

    public List<A> query(String s);
    public A find(String table, long ID);
    public List<A> findAll(String table);
    public List<A> findAll(String table, String field);
    public List<A> findAll(
        String table, String field, long ID);
}

Given the two base utilities above, I can now do the following in my individual test classes in order to ensure the cascading behavior for collection-valued and field-valued entity references from any given entity:

package org.eremite.corm.party;

import org.eremite.corm.Archetype;
import org.eremite.corm.party.address.Address;
import org.eremite.corm.party.address.AssociatedAddress;
import org.eremite.corm.party.testutil.CascadeTestBase;

import java.util.Set;
import java.util.concurrent.Callable;

public class AddressCascadeTest extends CascadeTestBase {

    private Address address1, address2, address3;
    private Party party1;
    private AssociatedAddress aa1;
    private Archetype party2, party3, aa2, aa3;
    private long ID, partyID, aaID;
    Retriever<Address> bean;

    /**
     * Initialize objects and persist.
     * @return Callable block
     */
    private Callable unitOfWork_01() {
        return new Callable() {
            public Object call() {
                // initialize objects
                address1 = new Address();
                party1 = new Party();
                aa1 = new AssociatedAddress(
                    party1, address1);

                // ensure that the objects are wired up
                assertTrue(
                    address1.getParties().contains(aa1));
                    
                assertTrue(
                    party1.getAddresses().contains(aa1));
                    
                assertEquals(party1, aa1.getParty());
                assertEquals(address1, aa1.getAddress());

                mgr.persist(address1);
                mgr.flush();

                // assign the IDs
                ID = address1.getID();
                partyID = party1.getID();
                aaID = aa1.getID();

                // ensure the IDs are nonzero
                assertNotSame(0, ID);
                assertNotSame(0, partyID);
                assertNotSame(0, aaID);

                // Done.
                return null;
            }
        };
    }

    /**
     * Verify cascading persist and make updates.
     * @return Callable block
     */
    private Callable unitOfWork_02() {
        return new Callable() {
            public Object call() {
                // Verify base conditions
                assertEquals(1, mgr.sizeOf("Address"));
                assertEquals(1, mgr.sizeOf(
                    "AssociatedAddress"));
                    
                assertEquals(1, mgr.sizeOf("Party"));

                // Get new copy of stem object from DB
                bean = new Retriever<Address>(
                    "Address", ID);
                    
                address2 = bean.fetchWith("parties");
                assertNotNull(address2);

                // Get object from collection-valued ref
                Set<AssociatedAddress> assocs = 
                    address2.getParties();
                    
                assertNotNull(assocs);
                assertEquals(1, assocs.size());
                assertTrue(hasArchetypeWithID(assocs, aaID));
                aa2 = getArchetypeWithID(assocs, aaID);
                assertNotNull(aa2);

                // Make some changes.
                address2.setName("address");
                aa2.setName("associated address");

                // Done.
                return null;
            }
        };
    }

    /**
     * Verify cascading updates and delete the stem object.
     * Verify the scope of the cascading delete.
     * Remove objects left over from the cascading delete.
     * Verify the objects were removed.
     * @return Callable block
     */
    private Callable unitOfWork_03() {
        return new Callable() {
            public Object call() {
                // Verify base conditions
                assertEquals(1, mgr.sizeOf("Address"));
                assertEquals(1, mgr.sizeOf(
                    "AssociatedAddress"));
                    
                assertEquals(1, mgr.sizeOf("Party"));

                // Get new copy of stem object from db
                address3 = bean.fetchWith("parties");
                assertNotNull(address3);

                // Get object from collection-valued ref
                Set<AssociatedAddress> assocs = 
                   address3.getParties();
                assertNotNull(assocs);
                assertEquals(1, assocs.size());
                assertTrue(hasArchetypeWithID(assocs, aaID));
                aa3 = getArchetypeWithID(assocs, aaID);
                assertNotNull(aa3);

                // Verify earlier changes.
                assertEquals(
                    address2.getName(), 
                    address3.getName());
                    
                assertEquals(
                    aa2.getName(), 
                    aa3.getName());

                // Remove stem object
                mgr.remove(address3);
                mgr.flush();

                // Verify scope of cascading deletion
                assertEquals(0, mgr.sizeOf("Address"));
                assertEquals(0, mgr.sizeOf(
                    "AssociatedAddress"));
                    
                assertEquals(1, mgr.sizeOf("Party"));

                // Clean up leftovers
                mgr.remove(new Retriever<Party>(
                    "Party", 
                    partyID).fetch());
                    
                mgr.flush();

                // Verify cleanup
                assertEquals(0, mgr.sizeOf("Party"));

                // Done.
                return null;
            }
        };
    }

    /**
     * Retrieve units of work for this test case
     * @return Callable[] units of work
     */
    public Callable[] getCalls() {
        return new Callable[]{
                unitOfWork_01(),
                unitOfWork_02(),
                unitOfWork_03()
        };
    }
}

Now, the three objects that encapsulate the units of work in the test case above obey the originally stated principle that "procedures operate in the environment in which they were created." We are sending each of the code blocks wrapped up in these anonymous inner classes to be executed by another object.

But, more importantly, we're sending their environments with them. This is the environment we assembled in this particular test case, which contains the object IDs, and the memory references.

By making CascadeTestBase class abstract, I force all of the subclasses to implement the getCalls() method, which is called by the lone test case in CascadeTestBase.

By using anonymous inner classes, I am able to generate unnamed implementations of the Callable interface and pass their contents and their enclosing environments around in a manner functionally identical to lambda calls in LISP!

Next time I'll show you how I implemented ALL of the CRUD tests for my first persistence module using this pattern in fewer than 200 lines of code.