Here's where we moved away from scanning N number ejb-jar.xml files in a webapp
to just scanning one ejb-jar.xml.
When we originally created the EJBs in .war concept we did it by scanning each
jar in a webapp and creating an EjbModule for each jar. The war then became an
.ear effectively and hence we called it 'collapsed ear.
The standard version we got added to the spec ended up differently, you get
only get WEB-INF/ejb-jar.xml. It was a long discussion in the Expert Group and
we considered all options, but eventually the group went with
"WEB-INF/ejb-jar.xml" with no exceptions or alterations. As well as we knew
there'd be confusion with the way OpenEJB used to do it, this text was added
which explicitly describes the approach we used to take and says "that's not
legal"
EJB 3.1, section 20.4 Enterprise Beans Packaged in a .war
A .jar file in WEB-INF/lib that contains enterprise beans is not
considered an independent Java EE “module” in the way that a .war
file, stand-alone ejb-jar file, or an .ear-level ejb-jar file is
considered a module. Such a .jar does not define its own module
name or its own namespace for ejb-names, environment dependencies,
persistence units, etc. All such namespaces are scoped to the
enclosing .war file. In that sense, the packaging of enterprise
bean classes in a WEB-INF/lib .jar is merely a convenience. It is
semantically equivalent to packaging the classes within
WEB-INF/classes.
That said, it would be great to support META-INF/ejb-jar.xml as a
vendor-specific option because there might exist applications written to our
old way of doing things, but we'd have to do it in a way that essentially
merges them together in to one ejb-jar.xml where the WEB-INF/ejb-jar.xml wins
in the case of any conflict (it overrides any META-INF/ejb-jar.xml files).
I personally see that as a bit low on the needs list. Adding in a scanning.xml
file would be higher.
-David
On Feb 15, 2011, at 9:54 PM, David Blevins wrote:
> I had to temporarily gut our webapp scanning enhancements (include/exclude).
> Bottom line is that a WebModule can have at most one EjbModule (itself). The
> spec Collapsed EAR approach ended up being slightly different than our own.
> We can put all that back, but just to get things moving I gutted the extra
> features and boiled it down to the minimum.
>
> When we put back the scanning include/export enhancements, we need to do it
> differently than we had before:
>
> 2011-02-15 19:35:30,199 - WARN - ADJUST THE EXCLUDE/INCLUDE!!!. Current
> settings: openejb.deployments.classpath.exclude='',
> openejb.deployments.classpath.include=''
> 2011-02-15 19:35:32,383 - INFO - Searched 63 classpath urls in 2184
> milliseconds. Average 34 milliseconds per url.
> 2011-02-15 19:35:32,530 - INFO - Configuring enterprise application:
> /tmp/apache-tomcat-7.0.8/webapps/examples
>
> Only the WEB-INF/lib/*.jar files and WEB-INF/classes/ parts of the webapp
> classpath are eligible for scanning. So for this particular app that'd be
> these jars:
>
> /tmp/apache-tomcat-7.0.8/webapps/examples/WEB-INF/lib/jstl.jar
> /tmp/apache-tomcat-7.0.8/webapps/examples/WEB-INF/lib/standard.jar
>
> We were also adding the persistence units twice which resulted in any apps
> that referenced a unit by name to fail.
>
> -David
>
