ok i'm ok to revert it if you think so
- Romain 2012/1/30 David Blevins <[email protected]> > 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 > > > >
