Hi Dan
On 01/05/14 17:03, Daniel Kulp wrote:
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.
AOP handler can be quote handy indeed, the class scanning is only used
by JAX-RS for now - I could it move it to JAX-RS if that can help, but I
wonder, it is just two classes (Spring AOP + Class scanner), and it is
optional, so may be we can just keep it there and thus keep the option
for reusing it (the class scanner) in JAX-WS namespace handlers too later ?
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.
IMHO we might want to do a 3.0.0 release first and then possibly pursue
it in 3.1.0, etc to give us more time to experiment and retest
Thanks, Sergey
Thoughts?
Dan
On Apr 30, 2014, at 7:12 PM, 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
