techMusings

EJB 3.0 further notes..

One of the big focus items is ease of use. JDK1.5 (since this will be in J2EE 1.5) will be required - hence generics and metadata will be leveraged. Also, since the jump is from 2.1 to 3.0, then a new model is possible, not backwards compat with the existing 1.x and 2.x models (though the existing will still be supported) -- i think this is to enable a significant change.

Apparently there is a desire in the EJB expert group to provide a POJO persistence mechanism, not entity related and, to my surprise, not JDO related.

We were asked to list titles of features we'd like to see then rate the list, I'll avoid the ratings but provide a few of the titles the group came up with:

• Enable easier testing outside of the container for TDD (most popular)


• Provide a mechanism to specific JMS selectors at runtime (perhaps via JMX) to allow dynamic reconfig of message consumption


• More powerful EJB-QL constructs


• Allow dynamic specification of EJB-QL


• Allow escaping to SQL instead for EJB-QL to allow use of stored procs / vendor extensions


• Reduce the need for deployment descriptors, perhaps via more aggresive defaulting (how much info is needed for a stateless session bean for example)


• Use of metadata to provide dd type info


• Cache invalidation (perhaps extended to a generic cache capability)


• If remote interface is akin to business instance methods, and home interface to statics, why not just make them that -- ie home is generated from the statics and the others from public instance methods (defaulting could go either way on this)


• Remove the ejb prefix (eg ejbMyMethod) in the implementation -- this would also allow the imp to actually implement the remote interface -- compile time safety, also corba style