12 Replies Latest reply on Jul 6, 2010 3:30 AM by asoldano

jbossws-cxf and the spring libs in AS

asoldano Jun 24, 2010 4:34 PM

Hi,

the current jbossws-cxf integration allows users to provide their own spring configuration files and have the endpoint(s) specified in there be deployed using the jbossws customizations. One of the reasons for that is allowing cxf users to move their endpoints to jbossws while keeping all their configurations.

This currently implies having springs libs available in the big-ball-of-mud classloader / DefaultDomain. In the effort of preventing those libs from being visible to every user deployment even having nothing to do with WS, I've been reasoning on possible solutions (besides the obvious one that's removing them and expecting users to provide spring if they actually need to use that mean of configuring CXF).

One of the things I've tried is moving the "offending" libraries to the jbossws.deployers. Of course that's not enought, so I tried declaring an isolated classloader for the jbossws.deployer by providing a proper jboss-classloading.xml into the deployers/jbossws.deployer/META-INF

<classloading xmlns="urn:jboss:classloading:1.0"
              domain="JBossWSDeployerDomain"
              parent-domain="DefaultDomain"
              export-all="NON_EMPTY"
              import-all="true">
</classloading>

After having dealt with various classloading issues basically requiring to have jbossws-cxf integration, spring and cxf jars all together in the isolated classloader (due to to their dependencies/references), I've been able to deploy a test ws endpoint deployment coming with cxf ws-sec declaration through spring configuration file. Problems of course arise once the webapp generated for the ws endpoint by the deployer is first hit, as the classloader for that web app does not see anymore the classes from the jars in the isolated classloader.

We might probably end up considering completely different approaches to the jbossws-cxf configuration, but I'm wondering if someone here in the mean time has suggestions/idea on how we could keep support for spring configuration for now while limiting the consequences of that (perhaps some tricks with classloading configuration).

1. Re: jbossws-cxf and the spring libs in AS

alesj Jun 25, 2010 8:54 AM (in response to asoldano)

We might probably end up considering completely different approaches to the jbossws-cxf configuration, but I'm wondering if someone here in the mean time has suggestions/idea on how we could keep support for spring configuration for now while limiting the consequences of that (perhaps some tricks with classloading configuration).
You could change the deployment's classloading metadata's parent domain to point to your WS domain,
if you recognize that deployment as WS depolyment and no explicit classloading metadata is given.
Actions
2. Re: jbossws-cxf and the spring libs in AS

asoldano Jun 25, 2010 12:10 PM (in response to alesj)

Ales Justin wrote:

You could change the deployment's classloading metadata's parent domain to point to your WS domain,
if you recognize that deployment as WS depolyment and no explicit classloading metadata is given.
Yes... the problem is that currently the deployment is recognized as a WS one after the classloading phase (in real phase) as in most cases the only way of doing that is finding jaxws annotations on the endpoint. Is the shared annotation repository (which we don't use yet, we have a jira for that) also populated after the classloader for the deployment unit is setup, isn't it?
Actions
3. Re: jbossws-cxf and the spring libs in AS

alesj Jun 25, 2010 12:20 PM (in response to asoldano)

Yes... the problem is that currently the deployment is recognized as a WS one after the classloading phase (in real phase) as in most cases the only way of doing that is finding jaxws annotations on the endpoint.
What about if you search for this Spring WS config file?
Is the shared annotation repository (which we don't use yet, we have a jira for that) also populated after the classloader for the deployment unit is setup, isn't it?
Yes.
Actions
4. Re: jbossws-cxf and the spring libs in AS

asoldano Jun 25, 2010 12:34 PM (in response to alesj)

Ales Justin wrote:

Yes... the problem is that currently the deployment is recognized as a WS one after the classloading phase (in real phase) as in most cases the only way of doing that is finding jaxws annotations on the endpoint.
What about if you search for this Spring WS config file?
Unfortunately this would not always work either, as that config file is optional. Basically you can deploy a simple jaxws endpoint in jar having no descriptors at all. 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).
Actions
5. Re: jbossws-cxf and the spring libs in AS

asoldano Jun 25, 2010 1:10 PM (in response to alesj)

Ales Justin wrote:
Is the shared annotation repository (which we don't use yet, we have a jira for that) also populated after the classloader for the deployment unit is setup, isn't it?
Yes.

ok... just asked because I remember some requirements for annotation scanning without classloading (http://community.jboss.org/wiki/PapakiAnnotationScanningRequirements , aop section), but don't actually know the status of that.
Actions
6. Re: jbossws-cxf and the spring libs in AS

alesj Jun 25, 2010 4:02 PM (in response to asoldano)

ok... just asked because I remember some requirements for annotation scanning without classloading (http://community.jboss.org/wiki/PapakiAnnotationScanningRequirements , aop section), but don't actually know the status of that.
You can still have this option, if you use Javassist based JBossReflect.
While we would still load the annotations, the actual owning classes won't be loaded -- see here:
* http://java.dzone.com/articles/jboss-microcontainer-scanning

But since this is probably only needed when doing some bytecode manipulation, e.g. AOP,
we actually by default already load the classes, as JDK's reflection currently still out performs Javassist's.
Actions
7. Re: jbossws-cxf and the spring libs in AS

alesj Jun 25, 2010 4:27 PM (in response to asoldano)

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
* hopefully we can lookup @Endpoint annotation w/o crs
* if there is @Endpoint present in deployment, add crs to deployment's classpath
** if spring is already in deployment, only add (crs - spring)

Just thinking out loud ... :-)
Actions
8. Re: jbossws-cxf and the spring libs in AS

asoldano Jun 26, 2010 3:00 AM (in response to alesj)

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 the 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:

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:
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 "linked" to 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 for cxf).
Just thinking out loud ... :-)
Me too... considering my classloading / MC knowledge here is most probably not the same as yours...
Actions
9. Re: jbossws-cxf and the spring libs in AS

alesj Jul 2, 2010 8:35 AM (in response to asoldano)

Thinking about it, specially since the only known / useful marker is @Endpoint annotation,
why don't we simply say if users want to use this new cxf, they need to place either
* jboss-classloading.xml with parent domain pointing to your WS domain
* custom jboss-ws.xml file, which we recognize and hack the classloading metadata ourselves

We forced Seam users to have jboss-app.xml with CL isolaton ...
As I think it will be hard to get any proper transaprent magic working in this case.
Actions
10. Re: jbossws-cxf and the spring libs in AS

asoldano Jul 3, 2010 3:14 AM (in response to alesj)

Hi Ales,
Ales Justin wrote:

Thinking about it, specially since the only known / useful marker is @Endpoint annotation,
why don't we simply say if users want to use this new cxf, they need to place either
* jboss-classloading.xml with parent domain pointing to your WS domain
* custom jboss-ws.xml file, which we recognize and hack the classloading metadata ourselves
this would be fine for the "advanced usecase" in which the spring based configuration is used, etc.
On the countrary, we can't ask users to add jboss-classloading.xml to a simple standard jaxws deployment (of course, the JavaEE certification testsuite would also fail for this) and without that the user deployment would not see CXF jars, which currently need to live together with the Spring ones in the isolated domain (see the last part of my first message in this thread).
As I think it will be hard to get any proper transaprent magic working in this case.
I see... currently the direction that's been considered the most viable is to remove the Spring libs from the AS distribution (https://jira.jboss.org/browse/JBAS-8131) and ask users to install them if they need / want to use the spring configuration.
Actions
11. Re: jbossws-cxf and the spring libs in AS

alesj Jul 5, 2010 9:01 AM (in response to asoldano)

I see... currently the direction that's been considered the most viable is to remove the Spring libs from the AS distribution (https://jira.jboss.org/browse/JBAS-8131) and ask users to install them if they need / want to use the spring configuration.
I thought WS/CXF couldn't work w/o Spring?

If it can, then simply have a Spring domain, and the WS users that want to use it,
would simply add proper jboss-classloading.xml, w/o the need for full Spring jars.
Actions
12. Re: jbossws-cxf and the spring libs in AS

asoldano Jul 6, 2010 3:30 AM (in response to alesj)

I see... currently the direction that's been considered the most viable is to remove the Spring libs from the AS distribution (https://jira.jboss.org/browse/JBAS-8131) and ask users to install them if they need / want to use the spring configuration.
I thought WS/CXF couldn't work w/o Spring?
JBossWS-CXF can now work without Spring (well, I still need to install that jbws version to AS trunk), but everything that users would configure using Spring (basically WS-*) would not be available then. So basic jaxws funcitonalities work without spring, everything else need spring available to jbossws at deploy time and to the user deployment at runtime.
Actions

Go to original post