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 <[email protected]> > >> >> 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 <[email protected] >>> 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
