cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Repackaging of cxf-api to remove Spring dependencies
Date Thu, 01 May 2014 16:03:28 GMT

I decided to try and experiment a bit with this idea.  Just pushed a “split-spring” branch
for folks to look at.

Basically, I did a few things:

1) Pulled bus/spring and configuration/spring into a new rt/spring bundle
2) Pulled bus/blueprint and configuration/blueprint (and related blueprint only schemas) into
a new rt/aries-blueprint bundle
3) updated all the poms/features.xml to pull them (optional for cxf-spring and provided+optional
for cxf-aries-blueprint)

Cuts the core jar by about 105K.

This does result in cxf-core not having any blueprint/aries deps at all.   The other bundles
do, but core doesn’t.  Core still has a couple of spring deps though.  There is the SpringBeanFactory
invoker thing, the helper for dealing with AOP classes, and the new classpath scanning stuff.
  The SpringBeanFactory could be moved to cxf-spring if we change the @FactoryType annotation
a bit so “Spring” is not one of the core types.  Not a big deal.   The AOP handling and
classpath scanning stuff would be a bigger issue though.

So, the question is, do we want to pursue this further for 3.0 or not?    For spring users,
they would need to add cxf-spring to the deps (minor) update and they would save about 40K
due to lack of the aries stuff.  For non-spring users, they could save 105K in space.    We’d
certainly need to go back and retest the samples and OSGi stuff which could be a big undertaking.



On Apr 30, 2014, at 7:12 PM, 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 <> 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
>> <>
> -- 
> Daniel Kulp
> -
> Talend Community Coder -

Daniel Kulp -
Talend Community Coder -

View raw message