This could simplify things considerably. You're right, we had a 'delegate to JSR109Service' approach in place for the AbstractWebContainer and the EJBDeployer. I mainly did this because I was not happy with the order of deployment (subdepoyment start/create before parent start/create). Realy the EJB/Webapp should be up before the webservice.
For the client programming model we might want to consider a simmilar 'tight' integration. -thomas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Freitag, 21. November 2003 18:18 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Sharing classes between WebContainer and JSR109Deployer *was* AW: [JBoss-dev] Re: deployment classloader in AbstractWebContaine r Its seems to me that we need to instead of having the JSR109Service be a competely seperate deployer from the AbstractWebContainer (which by the way needs to be broken up into a deployer + a container to address some class override issues), that the AbstractWebContainer either needs to incorporate the processing of the webservice.xml descriptor, or delegate directly to the JSR109Service as part of being a j2ee1.4 web app deployer. You actually had done this in the past, why did we decide to make them completely seperated? Adding the war jars to the parent web service deployment is not going to be violating scoping as the scope of the web app and web service have to be the same. Really the bigger issues is getting better integration with tomcat5 so that we install or obtain the web app class loader earlier on. -- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx Jung , Dr. Christoph wrote: > > All right. I changed the ws4ee classloading to use the subdeployment > ucl (which is indeed equal to the parent [EJB,WAR] ucl, see > DeploymentInfo(parent,...)). > > Thanks to your hint, the observed inconsistencies in the EJB case thus > went away. > > However, we still have the problem that bytecode from WEB-INF/classes > and WEB-INF/lib (which is referenced in the webservice.xml, e.g., by > defining a service endpoint interface, and needs to be loaded by > JSR109Service.start(...)) > > - either will never find its way into the war-ucl (tomcats > useJbossClassloader=no option) > - or wont be inserted until > AbstractWebContainer.start(...)->performDeploy(...) is executed > (which comes AFTER JSR109Service.start(...) due to ws4ee being > a subdeployment to the war). > > The current workaround in JSR109Service.start(...) (which I know is > certainly conflicting with the idea of allowing "scoped" war > classloading in > general) is to simply inject these urls into the war-ucl before trying to > load bytecode: > > //TODO CGJ: we need to share classes between a war and its > //webservice-subdeployment. We do that, similar to the EJB > case, > > //by the dis sharing the ucl. However, we need to hence > extend the > //ucl with web-inf/classes and lib at this point. > //This somehow conflicts with the notion of jboss-decoupled > //classloading for which I would propose to add another > //slot into DeploymentInfo that carries the > //final "Classloader applicationClassLoader" as used by the > //individual containers and that should be constructed at > //initialisation time (or is equivalent to ucl per default). > URL warURL = sdi.parent.localUrl != null ? > sdi.parent.localUrl : sdi.parent.url; > String warPath=warURL.getFile(); > try{ > File classesDir = new File(warPath, "WEB-INF/classes"); > if (classesDir.exists()) > sdi.parent.ucl.addURL(classesDir.toURL()); > File libDir = new File(warPath, "WEB-INF/lib"); > if (libDir.exists()) > { > File[] jars = libDir.listFiles(); > int length = jars != null ? jars.length : 0; > for (int j = 0; j < length; j++) > sdi.parent.ucl.addURL(jars[j].toURL()); > } > } catch(MalformedURLException e) { > throw new DeploymentException("Could not extend ws4ee > deployment ucl.",e); > } > > As a better solution which bundles the knowledge about war structure > in a central place and which is consistent with the existing > classloading options, I would propose to extend DeploymentInfo with > another "ClassLoader applicationLoader;" which could be equal to ucl > per default, but which would be set to the actual WebCtxLoader in the > Tomcat case or a similar construct for other web containers already > during AbstractWebContainer.init(...) calling a new > ConcreteWebContainer.constructWebLoader(...) method. This > applicationLoader could then be consistently used by JSR109Service to > load shared classes. > > What do you think? > CGJ > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
