Perhaps you can create a small core for your transport that is
independent of cxf and can be installed into the tomcat (or other
server) classloader. Your cxf transport would then access this jar to
communicate between wars.
So the whole cxf code could reside inside the wars and only one jar
needs to be shared.
Do you think that could work?
Christian
Am 01.05.2014 09:21, schrieb Mandy Warren:
Thanks for the reply Dan, I am sorry I only tried my work out on 2.7.x and
didn't realise that 3.0.0 has changed the packaging of jars.
My requirement was to ensure that the system classloader did not load spring
classes and instead the individual wars had their own copy of spring. This way
each war could run on its own version of spring and be independent of others
and no dodgy classloader issues would happen. This was very close to being
achievable with the cxf-api.jar as only a few classes had spring imports. I had
managed to get the jndi solution to only register Destination interface objects
hence that also only required cxf-api.jar
It might be my requirement is not feasible now but I will play around with
3.0.0 and take a more detailed look.
Many thanks for taking the time to reply and to Romain for his comments,
Mandy
Sent from a mobile device
On 1 May 2014, at 00:12, Daniel Kulp <[email protected]> wrote:
Just about every jar that has any level of significantly configurable
functionality in CXF has some classes in it that depend on spring. jaxws,
jaxrs, http, ws-security, ws-policy, etc…. I certainly would NOT want to
just about double the number of jars/modules we have to deal with to pull
spring out of everything and into separate jars.
That said, spring should be completely optional. If the spring jars are not
there, CXF should be able to detect that and work fine without it (minus all
the xml configuration and the JMS transport).
With 3.0, it’s even a bit more complicated as API is gone and merged with
cxf-rt-core into just cxf-core. Would definitely need to play more to figure
out what spring stuff could even be pulled out there successfully.
Dan
On Apr 30, 2014, at 3:57 PM, Mandy Warren <[email protected]> wrote:
Hi,
I am working on a new transport which will look very much like
LocalTransport but use JNDI to register the destinations. The idea is that
this will allow for war-war comms on a single thread with only a very
minimal set of jars on the system classpath.
I've successfully prototyped this and run the initial code past Andrei, I
am now trying to productionise it so I can get this groups feedback as to
whether it could be a useful addition to CXF.
One thing which my solution requires is for the Spring dependencies in
cxf-api to be moved into their own jar. This way, all I require on the
shared classpath is the cut down cxf-api and not all the Spring libraries.
I was wondering whether you would consider this repackaging as an option
for a future release? There are only a very small amount of classes which
would need to be moved, namely those in
cxf/api/src/main/java/org/apache/cxf/configuration/spring
Many thanks
Mandy
<https://fisheye6.atlassian.com/browse/cxf>
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
