[jboss-user] [JBoss Microcontainer] - jbossws-cxf and the spring libs in AS

[Alessio Soldano]

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion

"jbossws-cxf and the spring libs in AS"

To view the discussion, visit: http://community.jboss.org/message/549784#549784

--------------------------------------------------------------
> Ales Justin wrote:
> > While of course spring would not be needed in that case, the deployment unit classloader would not see the required cxf classes from cxf jars (as those need to be in the isolated classloader together with the spring jars because some classes in cxf jars references classes in spring jars).
> This looks more complicated then, and it would be good to know the details.
> 
> e.g. we could add "the needed cxf classes that rely on spring" (crs) dynamically
Sound interesting... let's see how that could be done
> * hopefully we can lookup @Endpoint annotation w/o crs
Yes, we can as that "@Endpoint" is actually @WebService / @WebServiceProvider, which stay in the jaxws api jar. The code doing the check is in the jbossws container integration, which has no direct reference/dependency on anything stack specific.

> * if there is @Endpoint present in deployment, add crs to deployment's classpath
ok (well, if there deployment is a ws one, we need at least "cxf - crs", whole "cxf + spring" if there's the spring descriptor, but let's go on with the reasoning)... when / how to do that? shouldn't this happen before the real stage?
Besides that, this assumes we isolate crs from the rest of CXF classes. crs are almost always alone in separate "spring" packages in cxf (except for few particular cases which I could probably work on @Apache if we come to a solution requiring that)... are you thinking about specifying the packages to be included in a given classloader/domain?

Btw, here is the current dependency situation:
 http://community.jboss.org/servlet/JiveServlet/showImage/3568/dep1.jpg  http://community.jboss.org/servlet/JiveServlet/downloadImage/3568/450-277/dep1.jpg 

basically the jbossws-cxf integration uses cxf as well as spring directly when there's need to (actually right now it detects if spring is available on the classloader at deploy time, but that can be easily changed into looking for the existence of the spring conf file).
Coming to a situation like the following should not be a major problem:
 http://community.jboss.org/servlet/JiveServlet/showImage/3569/dep2.jpg  http://community.jboss.org/servlet/JiveServlet/downloadImage/3569/450-227/dep2.jpg 
iow we could isolate jbws_crs into different jars from the rest of jbossws-cxf integration, for simplyfing the isolation. Doing the same on apache cxf stuff is instead much more complicated and can't be easily done.

> ** if spring is already in deployment, only add (crs - spring)
Oh.. this is something I've been thinking about too, but finally thought it was probably asking too much ;-) Well, if there's a way for using the spring already included in the user deployment... that would most probably be the best solution, especially because we would not include spring at all in the AS.
We're of course able to detect that at deploy time (simply trying loading a spring class using the classloader for the deployment unit). Again, the problem then is the jars of jbossws-cxf integration (as well as the CXF ones) are loaded from a classloader that does not see spring. Ideally, for completing the deployment, we would need to get another classloader seeing everything (what's on the server, including "crs" + spring) and use that. I've been trying something on this line few days ago, basically loading a "bootstrap" jbossws-cxf-integration class for the first time in the deployment unit's classloader (in a case where spring is included in the deployment) and trying going on with the deployment process there (expecting this to work because the parent of the unit cl is the jbossws.deployer one using the big-ball-of-mud domain). But that failed, as far as I understand because in there I of course use cxf and jbossws-cxf-integration classes that come from jars already loaded by the common classloader that does not see spring.
Perhaps the solution here, if any, also lies in being able to separate "crs" from other classes (either by jar structure refactoring for jbws or by specifying packages in the jboss-classloading.xml or equivalent).
> Just thinking out loud ... :-)
Me too... considering my classloading / MC knowledge here is most probably not the same as yours...

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/549784#549784]

Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2114]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100626/3ff69406/attachment-0001.html