You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2012/01/30 14:52:51 UTC
Re: WebApp Scanning
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
>
Re: WebApp Scanning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
ok
i'm ok to revert it if you think so
- Romain
2012/1/30 David Blevins <da...@gmail.com>
> 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
> >
>
>