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 2011/02/16 06:54:03 UTC
WebApp Scanning
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 David Blevins <da...@gmail.com>.
On Feb 20, 2011, at 10:42 PM, Shawn Jiang wrote:
> The problem is still there.
>
> I changed openejb source revision in AHP to 1071151 to avoid the failures
> for now.
Thanks Shawn! I was going to suggest that, but as always you're one step ahead of me! :)
-David
> On Thu, Feb 17, 2011 at 10:48 AM, Shawn Jiang <ge...@gmail.com> wrote:
>
>> Following change[1] mentioned in your mail breaks geronimo TCK completely.
>> the app could not be deployed at all with following error:
>>
>> Caused by: org.apache.openejb.OpenEJBException: Unable to create annotation
>> scanner for web module testConnClient_web_vehicle_web: Module classloader is
>> not a BundleReference. Only use BundleFactoryFinder in an pure osgi
>> environment
>> at
>> org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
>> at
>> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
>> at
>> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
>> ... 46 more
>>
>>
>> [1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
>>
>> On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <da...@gmail.com>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
>>>
>>>
>>
>>
>> --
>> Shawn
>>
>
>
>
> --
> Shawn
Re: WebApp Scanning
Posted by Shawn Jiang <ge...@gmail.com>.
The problem is still there.
I changed openejb source revision in AHP to 1071151 to avoid the failures
for now.
On Thu, Feb 17, 2011 at 10:48 AM, Shawn Jiang <ge...@gmail.com> wrote:
> Following change[1] mentioned in your mail breaks geronimo TCK completely.
> the app could not be deployed at all with following error:
>
> Caused by: org.apache.openejb.OpenEJBException: Unable to create annotation
> scanner for web module testConnClient_web_vehicle_web: Module classloader is
> not a BundleReference. Only use BundleFactoryFinder in an pure osgi
> environment
> at
> org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
> at
> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
> at
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
> ... 46 more
>
>
> [1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
>
> On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <da...@gmail.com>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
>>
>>
>
>
> --
> Shawn
>
--
Shawn
Re: WebApp Scanning
Posted by Ivan <xh...@gmail.com>.
You might refer to OPENEJB-1413 for detailed info.
2011/2/18 David Blevins <da...@gmail.com>
> You had proposed at one point a slightly different deploy chain for
> Geronimo. If I remember correctly it was quite small and concise.
>
> Do you still have that code aroud?
>
>
> -David
>
>
> On Feb 17, 2011, at 6:34 PM, Ivan wrote:
>
> > I added some filtered options to prevent DeploymentLoader parsing other
> > modules in the past. From Geronimo side, DeploymentLoader only needs to
> load
> > EjbModule and WsModule, but to make the codes also work correctly in
> OpenEJB
> > itself, DeploymentLoader has to create a dummy WebModule for discovering
> > EjbModule in the web application.
> >
> > 2011/2/17 David Blevins <da...@gmail.com>
> >
> >>
> >> On Feb 16, 2011, at 6:48 PM, Shawn Jiang wrote:
> >>
> >>> Following change[1] mentioned in your mail breaks geronimo TCK
> >> completely.
> >>> the app could not be deployed at all with following error:
> >>>
> >>> Caused by: org.apache.openejb.OpenEJBException: Unable to create
> >> annotation
> >>> scanner for web module testConnClient_web_vehicle_web: Module
> classloader
> >> is
> >>> not a BundleReference. Only use BundleFactoryFinder in an pure osgi
> >>> environment
> >>> at
> >>>
> >>
> org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
> >>> at
> >>>
> >>
> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
> >>> at
> >>>
> >>
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
> >>> ... 46 more
> >>
> >> Thanks. I think we may need to rework that part of the integration. We
> >> never used to involve anything but EjbModules in the Geronimo/OpenEJB
> code,
> >> using the OpenEJB WebModule deployment code seems unnecessary given
> Geronimo
> >> isn't going to use any part of the WebModule created.
> >>
> >> I'll hack on it.
> >>
> >>
> >> -David
> >>
> >>
> >>>
> >>> [1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
> >>>
> >>> On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <
> david.blevins@gmail.com
> >>> 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
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Shawn
> >>
> >>
> >
> >
> > --
> > Ivan
>
>
--
Ivan
Re: WebApp Scanning
Posted by David Blevins <da...@gmail.com>.
You had proposed at one point a slightly different deploy chain for Geronimo. If I remember correctly it was quite small and concise.
Do you still have that code aroud?
-David
On Feb 17, 2011, at 6:34 PM, Ivan wrote:
> I added some filtered options to prevent DeploymentLoader parsing other
> modules in the past. From Geronimo side, DeploymentLoader only needs to load
> EjbModule and WsModule, but to make the codes also work correctly in OpenEJB
> itself, DeploymentLoader has to create a dummy WebModule for discovering
> EjbModule in the web application.
>
> 2011/2/17 David Blevins <da...@gmail.com>
>
>>
>> On Feb 16, 2011, at 6:48 PM, Shawn Jiang wrote:
>>
>>> Following change[1] mentioned in your mail breaks geronimo TCK
>> completely.
>>> the app could not be deployed at all with following error:
>>>
>>> Caused by: org.apache.openejb.OpenEJBException: Unable to create
>> annotation
>>> scanner for web module testConnClient_web_vehicle_web: Module classloader
>> is
>>> not a BundleReference. Only use BundleFactoryFinder in an pure osgi
>>> environment
>>> at
>>>
>> org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
>>> at
>>>
>> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
>>> at
>>>
>> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
>>> ... 46 more
>>
>> Thanks. I think we may need to rework that part of the integration. We
>> never used to involve anything but EjbModules in the Geronimo/OpenEJB code,
>> using the OpenEJB WebModule deployment code seems unnecessary given Geronimo
>> isn't going to use any part of the WebModule created.
>>
>> I'll hack on it.
>>
>>
>> -David
>>
>>
>>>
>>> [1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
>>>
>>> On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <david.blevins@gmail.com
>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Shawn
>>
>>
>
>
> --
> Ivan
Re: WebApp Scanning
Posted by Ivan <xh...@gmail.com>.
I added some filtered options to prevent DeploymentLoader parsing other
modules in the past. From Geronimo side, DeploymentLoader only needs to load
EjbModule and WsModule, but to make the codes also work correctly in OpenEJB
itself, DeploymentLoader has to create a dummy WebModule for discovering
EjbModule in the web application.
2011/2/17 David Blevins <da...@gmail.com>
>
> On Feb 16, 2011, at 6:48 PM, Shawn Jiang wrote:
>
> > Following change[1] mentioned in your mail breaks geronimo TCK
> completely.
> > the app could not be deployed at all with following error:
> >
> > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> annotation
> > scanner for web module testConnClient_web_vehicle_web: Module classloader
> is
> > not a BundleReference. Only use BundleFactoryFinder in an pure osgi
> > environment
> > at
> >
> org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
> > at
> >
> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
> > at
> >
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
> > ... 46 more
>
> Thanks. I think we may need to rework that part of the integration. We
> never used to involve anything but EjbModules in the Geronimo/OpenEJB code,
> using the OpenEJB WebModule deployment code seems unnecessary given Geronimo
> isn't going to use any part of the WebModule created.
>
> I'll hack on it.
>
>
> -David
>
>
> >
> > [1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
> >
> > On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <david.blevins@gmail.com
> >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
> >>
> >>
> >
> >
> > --
> > Shawn
>
>
--
Ivan
Re: WebApp Scanning
Posted by David Blevins <da...@gmail.com>.
On Feb 16, 2011, at 6:48 PM, Shawn Jiang wrote:
> Following change[1] mentioned in your mail breaks geronimo TCK completely.
> the app could not be deployed at all with following error:
>
> Caused by: org.apache.openejb.OpenEJBException: Unable to create annotation
> scanner for web module testConnClient_web_vehicle_web: Module classloader is
> not a BundleReference. Only use BundleFactoryFinder in an pure osgi
> environment
> at
> org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
> at
> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
> at
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
> ... 46 more
Thanks. I think we may need to rework that part of the integration. We never used to involve anything but EjbModules in the Geronimo/OpenEJB code, using the OpenEJB WebModule deployment code seems unnecessary given Geronimo isn't going to use any part of the WebModule created.
I'll hack on it.
-David
>
> [1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
>
> On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <da...@gmail.com>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
>>
>>
>
>
> --
> Shawn
Re: WebApp Scanning
Posted by Shawn Jiang <ge...@gmail.com>.
Following change[1] mentioned in your mail breaks geronimo TCK completely.
the app could not be deployed at all with following error:
Caused by: org.apache.openejb.OpenEJBException: Unable to create annotation
scanner for web module testConnClient_web_vehicle_web: Module classloader is
not a BundleReference. Only use BundleFactoryFinder in an pure osgi
environment
at
org.apache.openejb.config.DeploymentLoader.addWebModule(DeploymentLoader.java:619)
at
org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:228)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:311)
... 46 more
[1]https://svn.apache.org/repos/asf/openejb/trunk/openejb3@1071152
On Wed, Feb 16, 2011 at 1:54 PM, David Blevins <da...@gmail.com>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
>
>
--
Shawn
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
> >
>
>
Re: WebApp Scanning
Posted by 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
>