Johan's blog
EJB Components inside war
When a new software release is announced with the magic words "it simplifies development", I am always skeptic. Simpler development often means that you don't have to write code for default behavior. Which is good, but it often leads to a way of programming where you forget that what you are doing is default, and that if you are doing something else, you're not doing "defaults" anymore, hence you have to do it "another way". That other way is then often the way it used to be in the previous version (without "simplified development"). Pity enough, since you are so used to the default way, you don't remember how to do it the other way. At least, that is what happens with me. A long time ago (more than 2 years!), you had to specify everything that had to do with EJB-behavior in one or more (euh, it always turned out to be in "more", which was part of the complexity) xml configuration files. But at least, you knew that you were using Container Managed Transaction or not. Today, you don't bother too much anymore, since the defaults are great for 95% of the cases. Which make the remaining 5% extra difficult.
But there are simplifications that I like too, though. I have just read this blog entry from Ken Saks. In the EJB 3.1 spec, it might be possible that you can package EJB components inside a war. Now, that is something that I do support very much! Today, I was working on a small POC, where I initially only needed a simple stateless Session Bean and a JSP. That currently means that I have an EAR with two components, since the Session Bean goes into the ejb-jar, and the jsp goes into a war. Two components, two descriptors, two places where configuration and inter-component communication can go wrong.
In the future, it will hopefully be possible to have EJB components inside a war. For small projects, that would definitely be a big help. Below is a quote from Ken's blog:
Here are some more details about how the new packaging approach would likely be defined :
EJB component classes are packaged within WEB-INF/classes and/or in WEB-INF/lib.
EJB components share the same classloader as other classes in WEB-INF/classes and WEB-INF/lib.
EJB components share the .war's module-level component environment. For example, a resource-ref defined within web.xml would be visible to any EJB components in the .war.
EJB components have visibility to any persistence units defined within the .war.
ejb-jar.xml is optional. If needed, it is placed in WEB-INF/.
There are no special restrictions placed on a .war just because it contains EJB components. It can be deployed as a stand-alone .war or included within an .ear along with any number of other .wars or ejb-jars.
The full EJB feature set is available. For example, it would be possible to define a message-driven bean by placing a bean class annotated with @MessageDriven within WEB-INF/classes.
That sounds great. And also important, the author clearly says that it is not the goal to create some new flavor of EJB component that uses Web Container API's.
Simplifications rule.
