cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mandy Warren <>
Subject Re: Repackaging of cxf-api to remove Spring dependencies
Date Thu, 01 May 2014 12:42:19 GMT
Hi Christian,

This would work but I would basically be taking copies of cxf classes (like Destination etc)
and repackaging them into my own jar. It would mean that each time a new release of cxf occurs
I would have to check for changes and pull them in if required.

So it would solve my problem but wouldn't be a generic solution for everyone which is what
I had originally hoped for. 

Sent from a mobile device

> On 1 May 2014, at 11:06, Christian Schneider <> wrote:
> 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 <> 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 <>
>>>> 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
>>>> <>
>>> -- 
>>> Daniel Kulp
>>> -
>>> Talend Community Coder -
> -- 
> Christian Schneider
> Open Source Architect
> Talend Application Integration Division

View raw message