You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Mandy Warren <ma...@gmail.com> on 2014/04/30 21:57:36 UTC
Repackaging of cxf-api to remove Spring dependencies
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>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Side note: in tomee the fact cxf packages spring dependent classes
makes spring usage in tomee not working out of the box and we needed
to hack the cxf classloader. Would be great to extract it for cxf 3.0
in cxf-spring or something like that.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-04-30 21:57 GMT+02:00 Mandy Warren <ma...@gmail.com>:
> 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>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Mandy Warren <ma...@gmail.com>.
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 <ch...@die-schneider.net> 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 <dk...@apache.org> 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 <ma...@gmail.com> 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
>>> dkulp@apache.org - 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
>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <dk...@apache.org> 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 <ma...@gmail.com> 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
>> dkulp@apache.org - 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
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Mandy Warren <ma...@gmail.com>.
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 <dk...@apache.org> 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 <ma...@gmail.com> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Mandy Warren <ma...@gmail.com>.
Thanks Christian & Andrei,
Andrei - I think I understand what you are suggesting but will get back to you with further questions soon!
As requested, I have raised Jira CXF-5727
On 3 May 2014, at 16:27, Christian Schneider wrote:
> Normally we develop on master and then backport to the branches. This makes sure master always contains all features and they do not get lost accidently.
> Thanks for your engagement. I am looking forward to see your transport.
>
> Christian
>
> Am 02.05.2014 23:44, schrieb Mandy Warren:
>> Thanks Christian,
>>
>> Just to check the process, should I fork 2.7-fixes branch or master to implement the local-jndi transport? I'm new to git so pls bear with me! I guess once I have something to share I issue a pull request?
>>
>> I am also going to produce a separate project in my github which generates 2 wars and shows the transport in use. As soon as I have something to share I will let you know, hopefully in the next few days.
>>
>> Many thanks to everyone for being so supportive!
>>
>> Sent from a mobile device
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Christian Schneider <ch...@die-schneider.net>.
Normally we develop on master and then backport to the branches. This
makes sure master always contains all features and they do not get lost
accidently.
Thanks for your engagement. I am looking forward to see your transport.
Christian
Am 02.05.2014 23:44, schrieb Mandy Warren:
> Thanks Christian,
>
> Just to check the process, should I fork 2.7-fixes branch or master to implement the local-jndi transport? I'm new to git so pls bear with me! I guess once I have something to share I issue a pull request?
>
> I am also going to produce a separate project in my github which generates 2 wars and shows the transport in use. As soon as I have something to share I will let you know, hopefully in the next few days.
>
> Many thanks to everyone for being so supportive!
>
> Sent from a mobile device
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Mandy Warren <ma...@gmail.com>.
Hi,
I just wanted to apologise that I hadn't done any work on this over the last month.. been pretty hectic with work, sorry!
Hoping to have a bit more free time soon.
Mandy
On 3 May 2014, at 10:48, Andrei Shakirin wrote:
> Hi Mandy,
>
> You can provide your transport components either as git pull request or as a patch (attached to corresponded Jira Issue).
> In any case it make sense to create Jira Issue for that to keep the process traceable.
>
> As far as it is a new feature I would apply this to the master. Short documentation in CXF confluence wiki and system test are, of course, always welcome :)
> As Christian said, we can support you in design of shared part, if you have any questions.
>
> Shared code can be for instance a small interface registering per endpoint and containing methods for writing/reading message properties and content (PipedInput/PipedOutput stream or analogue of CXF CachedOutputStream).
> Destination will register this interface using JNDI with endpoint name. By request, Conduit will look up the interface an write request message there, Destination will read and create a new message and call own message observer. Vice versa for response.
>
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Mandy Warren [mailto:mandys.inbox@gmail.com]
>> Sent: Freitag, 2. Mai 2014 23:45
>> To: dev@cxf.apache.org
>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>
>> Thanks Christian,
>>
>> Just to check the process, should I fork 2.7-fixes branch or master to implement
>> the local-jndi transport? I'm new to git so pls bear with me! I guess once I have
>> something to share I issue a pull request?
>>
>> I am also going to produce a separate project in my github which generates 2
>> wars and shows the transport in use. As soon as I have something to share I will
>> let you know, hopefully in the next few days.
>>
>> Many thanks to everyone for being so supportive!
>>
>> Sent from a mobile device
>>
>>> On 2 May 2014, at 21:36, Christian Schneider <ch...@die-schneider.net>
>> wrote:
>>>
>>> I agree with Dan that you should not put the cxf api into the shared
>>> space. Create a small lib that contains the minimal information that needs to
>> be shared and build the transport upon this base. The users of your transport
>> will thank you if you make the shared part really small and simple.
>>>
>>> It would be great if you could upload your transport somehwere. I am sure we
>> can help a bit with designing the shared part.
>>>
>>> Christian
>>>
>>> Am 02.05.2014 11:44, schrieb Mandy Warren:
>>>> Just to clarify yes, I was doing exactly as Sergei described and Andrei
>> discussed, I am creating a new jndi local transport which duplicates local
>> transport except for the jndi lookup. If you give me a few days I can upload the
>> code to somewhere on github so you can see it in detail.
>>>>
>>>> As Andrei stated, it just relied on registering a Destination and hence
>> needed a fee interface classes that lived in cxf-api.
>>>>
>>>> Sent from a mobile device
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
RE: Repackaging of cxf-api to remove Spring dependencies
Posted by Andrei Shakirin <as...@talend.com>.
Hi Mandy,
You can provide your transport components either as git pull request or as a patch (attached to corresponded Jira Issue).
In any case it make sense to create Jira Issue for that to keep the process traceable.
As far as it is a new feature I would apply this to the master. Short documentation in CXF confluence wiki and system test are, of course, always welcome :)
As Christian said, we can support you in design of shared part, if you have any questions.
Shared code can be for instance a small interface registering per endpoint and containing methods for writing/reading message properties and content (PipedInput/PipedOutput stream or analogue of CXF CachedOutputStream).
Destination will register this interface using JNDI with endpoint name. By request, Conduit will look up the interface an write request message there, Destination will read and create a new message and call own message observer. Vice versa for response.
Regards,
Andrei.
> -----Original Message-----
> From: Mandy Warren [mailto:mandys.inbox@gmail.com]
> Sent: Freitag, 2. Mai 2014 23:45
> To: dev@cxf.apache.org
> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>
> Thanks Christian,
>
> Just to check the process, should I fork 2.7-fixes branch or master to implement
> the local-jndi transport? I'm new to git so pls bear with me! I guess once I have
> something to share I issue a pull request?
>
> I am also going to produce a separate project in my github which generates 2
> wars and shows the transport in use. As soon as I have something to share I will
> let you know, hopefully in the next few days.
>
> Many thanks to everyone for being so supportive!
>
> Sent from a mobile device
>
> > On 2 May 2014, at 21:36, Christian Schneider <ch...@die-schneider.net>
> wrote:
> >
> > I agree with Dan that you should not put the cxf api into the shared
> > space. Create a small lib that contains the minimal information that needs to
> be shared and build the transport upon this base. The users of your transport
> will thank you if you make the shared part really small and simple.
> >
> > It would be great if you could upload your transport somehwere. I am sure we
> can help a bit with designing the shared part.
> >
> > Christian
> >
> > Am 02.05.2014 11:44, schrieb Mandy Warren:
> >> Just to clarify yes, I was doing exactly as Sergei described and Andrei
> discussed, I am creating a new jndi local transport which duplicates local
> transport except for the jndi lookup. If you give me a few days I can upload the
> code to somewhere on github so you can see it in detail.
> >>
> >> As Andrei stated, it just relied on registering a Destination and hence
> needed a fee interface classes that lived in cxf-api.
> >>
> >> Sent from a mobile device
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
> >
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Mandy Warren <ma...@gmail.com>.
Thanks Christian,
Just to check the process, should I fork 2.7-fixes branch or master to implement the local-jndi transport? I'm new to git so pls bear with me! I guess once I have something to share I issue a pull request?
I am also going to produce a separate project in my github which generates 2 wars and shows the transport in use. As soon as I have something to share I will let you know, hopefully in the next few days.
Many thanks to everyone for being so supportive!
Sent from a mobile device
> On 2 May 2014, at 21:36, Christian Schneider <ch...@die-schneider.net> wrote:
>
> I agree with Dan that you should not put the cxf api into the shared space. Create a small lib that contains the minimal information that needs to be shared and build the transport upon this
> base. The users of your transport will thank you if you make the shared part really small and simple.
>
> It would be great if you could upload your transport somehwere. I am sure we can help a bit with designing the shared part.
>
> Christian
>
> Am 02.05.2014 11:44, schrieb Mandy Warren:
>> Just to clarify yes, I was doing exactly as Sergei described and Andrei discussed, I am creating a new jndi local transport which duplicates local transport except for the jndi lookup. If you give me a few days I can upload the code to somewhere on github so you can see it in detail.
>>
>> As Andrei stated, it just relied on registering a Destination and hence needed a fee interface classes that lived in cxf-api.
>>
>> Sent from a mobile device
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Christian Schneider <ch...@die-schneider.net>.
I agree with Dan that you should not put the cxf api into the shared
space. Create a small lib that contains the minimal information that
needs to be shared and build the transport upon this
base. The users of your transport will thank you if you make the shared
part really small and simple.
It would be great if you could upload your transport somehwere. I am
sure we can help a bit with designing the shared part.
Christian
Am 02.05.2014 11:44, schrieb Mandy Warren:
> Just to clarify yes, I was doing exactly as Sergei described and Andrei discussed, I am creating a new jndi local transport which duplicates local transport except for the jndi lookup. If you give me a few days I can upload the code to somewhere on github so you can see it in detail.
>
> As Andrei stated, it just relied on registering a Destination and hence needed a fee interface classes that lived in cxf-api.
>
> Sent from a mobile device
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Mandy Warren <ma...@gmail.com>.
Just to clarify yes, I was doing exactly as Sergei described and Andrei discussed, I am creating a new jndi local transport which duplicates local transport except for the jndi lookup. If you give me a few days I can upload the code to somewhere on github so you can see it in detail.
As Andrei stated, it just relied on registering a Destination and hence needed a fee interface classes that lived in cxf-api.
Sent from a mobile device
> On 2 May 2014, at 10:25, Andrei Shakirin <as...@talend.com> wrote:
>
> Hi Sergei,
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Freitag, 2. Mai 2014 10:53
>> To: dev@cxf.apache.org
>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>
>> Hi Andrei
>>> On 02/05/14 09:37, Andrei Shakirin wrote:
>>> Hi Dan,
>>>
>>>> -----Original Message-----
>>>> From: Daniel Kulp [mailto:dkulp@apache.org]
>>>> Sent: Donnerstag, 1. Mai 2014 23:49
>>>> To: dev@cxf.apache.org
>>>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>>>
>>>>
>>>> On May 1, 2014, at 3:22 PM, Andrei Shakirin <as...@talend.com>
>> wrote:
>>>>
>>>>> Hi Dan,
>>>>>
>>>>> I was not really happy with the problem described by Mandy:
>>>>> to have some API classes available for more than one application
>>>> (Destination, Conduit and AbstractTransportFactory in that case) we
>>>> need to share whole Spring dependencies as well.
>>>>
>>>> The problem is that you would need to stick a bunch of other things into the
>>>> shared space depending on what you need to do. For example, if you want
>> to
>>>> handle fastinfoset services, you would need to put the fastinfoset jar into the
>>>> shared area. You need xmlschema in the shared area. Woodstox is
>> needed
>>>> in the shared area. With 2.x, you would need wsdl4j.jar, etc.... Basically, if
>>>> you are going to share parts of CXF, you really need to share the
>>>> dependencies of CXF as well, that includes spring.
>>>
>>> This is true, but the fact is that API classes we are sharing are not dependent
>> on Spring at all (they imports only java.*, cxf.message.*, ws.addressing.*
>> packages).
>>> In this case, the Spring classes principally can be loaded from the individual
>> applications by their class loaders: Mandy made some experiments to achieve
>> that by repackaging cxf-api.jar.
>>> Therefore splitting spring dependent classes from api / core would help here.
>>>
>>> I have seen the similar situation in some other use cases as well: when users
>> would like to share Bus or ManagementComponent interfaces.
>>>
>>>> Personally, I think for this case, there should be a jar in the
>>>> shared area that handles the communication between wars and such that
>>>> has NO dependency on CXF at all. Not destination, not conduit, etc... A CXF
>> Destination/Conduit/etc....
>>>> would depend on that, but it would live in the individual apps that need it.
>>>
>>> Yes, this is a solution proposed by Christian - it definitely will work.
>>> However our goal was to reuse existing LocalTransport mechanism, where
>> LocalConduit can see the LocalDestination registered for the endpoint. This
>> works perfectly, beside shared lib problem.
>> What about the idea of introducing specifically a CXF JNDI transport - it would
>> act as a 'Local' transport, except that it won't reuse the existing LocalTransport
>> but rather work with JNDI (presumably available as a CXF independent shared
>> library) ?
>
> AFAIK Mandy will start working on contribution of JNDI transport
>
>>
>> I'm rereading the thread, I wonder why would need cxf api in shared lib at all
>> now ? I actually thought Mandy created a CXF JNDITransport :-), more or less a
>> copy & paste of LocalTransport except that it has JNDIConduit &
>> JNDIDestination...
>
> Well, it is matter of using JNDI.
> Currently JNDI there was used to lookup destinations registered by other applications (war).
> In order to use destinations created in other web app, the Destination interface should be loaded in shared class loader.
> The LocalTransport mechanism is completely reused, the difference is only that Destinations in TransportFactory are looked up using JNDI.
>
> But of course, option proposed by Christian and Dan is valid: we can share a code completely independent from CXF and call it from CXF Conduit and Destination (without sharing anything from CXF). JNDI still can be used to lookup custom shared interface.
>
> Generally, independent form Mandy use case, for me this is kind of limitation:
> It is very difficult to share CXF API interfaces or abstract classes independent from third parties (Spring) itself, without sharing these third parties as well.
>
> Regards,
> Andrei.
>>
>> Cheers, Sergey
>>
>>
>>> Regards,
>>> Andrei.
>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>> Therefore I find the idea to separate spring and blueprint dependent
>>>>> classes
>>>> great and very useful.
>>>>>
>>>>> @Sergey: I think the most important is to extract bus.spring.* and
>>>> configuration.spring.* classes, often used to instantiate bus,
>>>> servers and proxies from spring configuration. Spring AOP + Class
>>>> scanner are not so critical from my perspective.
>>>>>
>>>>> Regarding the release: of course, would be nice to have this in
>>>>> 3.0.0, but
>>>> agree with Sergei that it is a big change requiring additional tests
>>>> (especially for OSGi), documentation updates, migration guides.
>>>>> My +1 for pursue it in 3.1.0.
>>>>>
>>>>> Regards,
>>>>> Andrei.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Daniel Kulp [mailto:dkulp@apache.org]
>>>>>> Sent: Donnerstag, 1. Mai 2014 18:03
>>>>>> To: dev@cxf.apache.org
>>>>>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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
>> <ma...@gmail.com>
>>>>>> 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
>>>>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder
>>>>>>> - http://coders.talend.com
>>>>>>
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>>>>> http://coders.talend.com
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>>> http://coders.talend.com
>
RE: Repackaging of cxf-api to remove Spring dependencies
Posted by Andrei Shakirin <as...@talend.com>.
Hi Sergei,
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Freitag, 2. Mai 2014 10:53
> To: dev@cxf.apache.org
> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>
> Hi Andrei
> On 02/05/14 09:37, Andrei Shakirin wrote:
> > Hi Dan,
> >
> >> -----Original Message-----
> >> From: Daniel Kulp [mailto:dkulp@apache.org]
> >> Sent: Donnerstag, 1. Mai 2014 23:49
> >> To: dev@cxf.apache.org
> >> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
> >>
> >>
> >> On May 1, 2014, at 3:22 PM, Andrei Shakirin <as...@talend.com>
> wrote:
> >>
> >>> Hi Dan,
> >>>
> >>> I was not really happy with the problem described by Mandy:
> >>> to have some API classes available for more than one application
> >> (Destination, Conduit and AbstractTransportFactory in that case) we
> >> need to share whole Spring dependencies as well.
> >>
> >> The problem is that you would need to stick a bunch of other things into the
> >> shared space depending on what you need to do. For example, if you want
> to
> >> handle fastinfoset services, you would need to put the fastinfoset jar into the
> >> shared area. You need xmlschema in the shared area. Woodstox is
> needed
> >> in the shared area. With 2.x, you would need wsdl4j.jar, etc.... Basically, if
> >> you are going to share parts of CXF, you really need to share the
> >> dependencies of CXF as well, that includes spring.
> >>
> >
> > This is true, but the fact is that API classes we are sharing are not dependent
> on Spring at all (they imports only java.*, cxf.message.*, ws.addressing.*
> packages).
> > In this case, the Spring classes principally can be loaded from the individual
> applications by their class loaders: Mandy made some experiments to achieve
> that by repackaging cxf-api.jar.
> > Therefore splitting spring dependent classes from api / core would help here.
> >
> > I have seen the similar situation in some other use cases as well: when users
> would like to share Bus or ManagementComponent interfaces.
> >
> >> Personally, I think for this case, there should be a jar in the
> >> shared area that handles the communication between wars and such that
> >> has NO dependency on CXF at all. Not destination, not conduit, etc... A CXF
> Destination/Conduit/etc....
> >> would depend on that, but it would live in the individual apps that need it.
> >
> > Yes, this is a solution proposed by Christian - it definitely will work.
> > However our goal was to reuse existing LocalTransport mechanism, where
> LocalConduit can see the LocalDestination registered for the endpoint. This
> works perfectly, beside shared lib problem.
> >
> What about the idea of introducing specifically a CXF JNDI transport - it would
> act as a 'Local' transport, except that it won't reuse the existing LocalTransport
> but rather work with JNDI (presumably available as a CXF independent shared
> library) ?
AFAIK Mandy will start working on contribution of JNDI transport
>
> I'm rereading the thread, I wonder why would need cxf api in shared lib at all
> now ? I actually thought Mandy created a CXF JNDITransport :-), more or less a
> copy & paste of LocalTransport except that it has JNDIConduit &
> JNDIDestination...
Well, it is matter of using JNDI.
Currently JNDI there was used to lookup destinations registered by other applications (war).
In order to use destinations created in other web app, the Destination interface should be loaded in shared class loader.
The LocalTransport mechanism is completely reused, the difference is only that Destinations in TransportFactory are looked up using JNDI.
But of course, option proposed by Christian and Dan is valid: we can share a code completely independent from CXF and call it from CXF Conduit and Destination (without sharing anything from CXF). JNDI still can be used to lookup custom shared interface.
Generally, independent form Mandy use case, for me this is kind of limitation:
It is very difficult to share CXF API interfaces or abstract classes independent from third parties (Spring) itself, without sharing these third parties as well.
Regards,
Andrei.
>
> Cheers, Sergey
>
>
> > Regards,
> > Andrei.
> >
> >>
> >> Dan
> >>
> >>
> >>> Therefore I find the idea to separate spring and blueprint dependent
> >>> classes
> >> great and very useful.
> >>>
> >>> @Sergey: I think the most important is to extract bus.spring.* and
> >> configuration.spring.* classes, often used to instantiate bus,
> >> servers and proxies from spring configuration. Spring AOP + Class
> >> scanner are not so critical from my perspective.
> >>>
> >>> Regarding the release: of course, would be nice to have this in
> >>> 3.0.0, but
> >> agree with Sergei that it is a big change requiring additional tests
> >> (especially for OSGi), documentation updates, migration guides.
> >>> My +1 for pursue it in 3.1.0.
> >>>
> >>> Regards,
> >>> Andrei.
> >>>
> >>>> -----Original Message-----
> >>>> From: Daniel Kulp [mailto:dkulp@apache.org]
> >>>> Sent: Donnerstag, 1. Mai 2014 18:03
> >>>> To: dev@cxf.apache.org
> >>>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
> >>>>
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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
> <ma...@gmail.com>
> >>>> 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
> >>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder
> >>>>> - http://coders.talend.com
> >>>>>
> >>>>
> >>>> --
> >>>> Daniel Kulp
> >>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> >>>> http://coders.talend.com
> >>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> >> http://coders.talend.com
> >
>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andrei
On 02/05/14 09:37, Andrei Shakirin wrote:
> Hi Dan,
>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: Donnerstag, 1. Mai 2014 23:49
>> To: dev@cxf.apache.org
>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>
>>
>> On May 1, 2014, at 3:22 PM, Andrei Shakirin <as...@talend.com> wrote:
>>
>>> Hi Dan,
>>>
>>> I was not really happy with the problem described by Mandy:
>>> to have some API classes available for more than one application
>> (Destination, Conduit and AbstractTransportFactory in that case) we need to
>> share whole Spring dependencies as well.
>>
>> The problem is that you would need to stick a bunch of other things into the
>> shared space depending on what you need to do. For example, if you want to
>> handle fastinfoset services, you would need to put the fastinfoset jar into the
>> shared area. You need xmlschema in the shared area. Woodstox is needed
>> in the shared area. With 2.x, you would need wsdl4j.jar, etc.... Basically, if
>> you are going to share parts of CXF, you really need to share the dependencies
>> of CXF as well, that includes spring.
>>
>
> This is true, but the fact is that API classes we are sharing are not dependent on Spring at all (they imports only java.*, cxf.message.*, ws.addressing.* packages).
> In this case, the Spring classes principally can be loaded from the individual applications by their class loaders: Mandy made some experiments to achieve that by repackaging cxf-api.jar.
> Therefore splitting spring dependent classes from api / core would help here.
>
> I have seen the similar situation in some other use cases as well: when users would like to share Bus or ManagementComponent interfaces.
>
>> Personally, I think for this case, there should be a jar in the shared area that
>> handles the communication between wars and such that has NO dependency on
>> CXF at all. Not destination, not conduit, etc... A CXF Destination/Conduit/etc....
>> would depend on that, but it would live in the individual apps that need it.
>
> Yes, this is a solution proposed by Christian - it definitely will work.
> However our goal was to reuse existing LocalTransport mechanism, where LocalConduit can see the LocalDestination registered for the endpoint. This works perfectly, beside shared lib problem.
>
What about the idea of introducing specifically a CXF JNDI transport -
it would act as a 'Local' transport, except that it won't reuse the
existing LocalTransport but rather work with JNDI (presumably available
as a CXF independent shared library) ?
I'm rereading the thread, I wonder why would need cxf api in shared lib
at all now ? I actually thought Mandy created a CXF JNDITransport :-),
more or less a copy & paste of LocalTransport except that it has
JNDIConduit & JNDIDestination...
Cheers, Sergey
> Regards,
> Andrei.
>
>>
>> Dan
>>
>>
>>> Therefore I find the idea to separate spring and blueprint dependent classes
>> great and very useful.
>>>
>>> @Sergey: I think the most important is to extract bus.spring.* and
>> configuration.spring.* classes, often used to instantiate bus, servers and proxies
>> from spring configuration. Spring AOP + Class scanner are not so critical from
>> my perspective.
>>>
>>> Regarding the release: of course, would be nice to have this in 3.0.0, but
>> agree with Sergei that it is a big change requiring additional tests (especially
>> for OSGi), documentation updates, migration guides.
>>> My +1 for pursue it in 3.1.0.
>>>
>>> Regards,
>>> Andrei.
>>>
>>>> -----Original Message-----
>>>> From: Daniel Kulp [mailto:dkulp@apache.org]
>>>> Sent: Donnerstag, 1. Mai 2014 18:03
>>>> To: dev@cxf.apache.org
>>>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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 <ma...@gmail.com>
>>>> 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
>>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>>>> http://coders.talend.com
>>>>>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>>> http://coders.talend.com
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>> http://coders.talend.com
>
RE: Repackaging of cxf-api to remove Spring dependencies
Posted by Andrei Shakirin <as...@talend.com>.
Hi Dan,
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Donnerstag, 1. Mai 2014 23:49
> To: dev@cxf.apache.org
> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>
>
> On May 1, 2014, at 3:22 PM, Andrei Shakirin <as...@talend.com> wrote:
>
> > Hi Dan,
> >
> > I was not really happy with the problem described by Mandy:
> > to have some API classes available for more than one application
> (Destination, Conduit and AbstractTransportFactory in that case) we need to
> share whole Spring dependencies as well.
>
> The problem is that you would need to stick a bunch of other things into the
> shared space depending on what you need to do. For example, if you want to
> handle fastinfoset services, you would need to put the fastinfoset jar into the
> shared area. You need xmlschema in the shared area. Woodstox is needed
> in the shared area. With 2.x, you would need wsdl4j.jar, etc.... Basically, if
> you are going to share parts of CXF, you really need to share the dependencies
> of CXF as well, that includes spring.
>
This is true, but the fact is that API classes we are sharing are not dependent on Spring at all (they imports only java.*, cxf.message.*, ws.addressing.* packages).
In this case, the Spring classes principally can be loaded from the individual applications by their class loaders: Mandy made some experiments to achieve that by repackaging cxf-api.jar.
Therefore splitting spring dependent classes from api / core would help here.
I have seen the similar situation in some other use cases as well: when users would like to share Bus or ManagementComponent interfaces.
> Personally, I think for this case, there should be a jar in the shared area that
> handles the communication between wars and such that has NO dependency on
> CXF at all. Not destination, not conduit, etc... A CXF Destination/Conduit/etc....
> would depend on that, but it would live in the individual apps that need it.
Yes, this is a solution proposed by Christian - it definitely will work.
However our goal was to reuse existing LocalTransport mechanism, where LocalConduit can see the LocalDestination registered for the endpoint. This works perfectly, beside shared lib problem.
Regards,
Andrei.
>
> Dan
>
>
> > Therefore I find the idea to separate spring and blueprint dependent classes
> great and very useful.
> >
> > @Sergey: I think the most important is to extract bus.spring.* and
> configuration.spring.* classes, often used to instantiate bus, servers and proxies
> from spring configuration. Spring AOP + Class scanner are not so critical from
> my perspective.
> >
> > Regarding the release: of course, would be nice to have this in 3.0.0, but
> agree with Sergei that it is a big change requiring additional tests (especially
> for OSGi), documentation updates, migration guides.
> > My +1 for pursue it in 3.1.0.
> >
> > Regards,
> > Andrei.
> >
> >> -----Original Message-----
> >> From: Daniel Kulp [mailto:dkulp@apache.org]
> >> Sent: Donnerstag, 1. Mai 2014 18:03
> >> To: dev@cxf.apache.org
> >> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
> >>
> >>
> >> 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.
> >>
> >>
> >> Thoughts?
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >> On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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 <ma...@gmail.com>
> >> 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
> >>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> >>> http://coders.talend.com
> >>>
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> >> http://coders.talend.com
> >
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Daniel Kulp <dk...@apache.org>.
On May 1, 2014, at 3:22 PM, Andrei Shakirin <as...@talend.com> wrote:
> Hi Dan,
>
> I was not really happy with the problem described by Mandy:
> to have some API classes available for more than one application (Destination, Conduit and AbstractTransportFactory in that case) we need to share whole Spring dependencies as well.
The problem is that you would need to stick a bunch of other things into the shared space depending on what you need to do. For example, if you want to handle fastinfoset services, you would need to put the fastinfoset jar into the shared area. You need xmlschema in the shared area. Woodstox is needed in the shared area. With 2.x, you would need wsdl4j.jar, etc…. Basically, if you are going to share parts of CXF, you really need to share the dependencies of CXF as well, that includes spring.
Personally, I think for this case, there should be a jar in the shared area that handles the communication between wars and such that has NO dependency on CXF at all. Not destination, not conduit, etc… A CXF Destination/Conduit/etc…. would depend on that, but it would live in the individual apps that need it.
Dan
> Therefore I find the idea to separate spring and blueprint dependent classes great and very useful.
>
> @Sergey: I think the most important is to extract bus.spring.* and configuration.spring.* classes, often used to instantiate bus, servers and proxies from spring configuration. Spring AOP + Class scanner are not so critical from my perspective.
>
> Regarding the release: of course, would be nice to have this in 3.0.0, but agree with Sergei that it is a big change requiring additional tests (especially for OSGi), documentation updates, migration guides.
> My +1 for pursue it in 3.1.0.
>
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: Donnerstag, 1. Mai 2014 18:03
>> To: dev@cxf.apache.org
>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>>
>>
>> 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.
>>
>>
>> Thoughts?
>>
>> Dan
>>
>>
>>
>>
>> On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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 <ma...@gmail.com>
>> 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
>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>>> http://coders.talend.com
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
>> http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
RE: Repackaging of cxf-api to remove Spring dependencies
Posted by Andrei Shakirin <as...@talend.com>.
Hi Dan,
I was not really happy with the problem described by Mandy:
to have some API classes available for more than one application (Destination, Conduit and AbstractTransportFactory in that case) we need to share whole Spring dependencies as well.
Therefore I find the idea to separate spring and blueprint dependent classes great and very useful.
@Sergey: I think the most important is to extract bus.spring.* and configuration.spring.* classes, often used to instantiate bus, servers and proxies from spring configuration. Spring AOP + Class scanner are not so critical from my perspective.
Regarding the release: of course, would be nice to have this in 3.0.0, but agree with Sergei that it is a big change requiring additional tests (especially for OSGi), documentation updates, migration guides.
My +1 for pursue it in 3.1.0.
Regards,
Andrei.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Donnerstag, 1. Mai 2014 18:03
> To: dev@cxf.apache.org
> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>
>
> 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.
>
>
> Thoughts?
>
> Dan
>
>
>
>
> On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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 <ma...@gmail.com>
> 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
> > dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> > http://coders.talend.com
> >
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder -
> http://coders.talend.com
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <dk...@apache.org> 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 <ma...@gmail.com> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Daniel Kulp <dk...@apache.org>.
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.
Thoughts?
Dan
On Apr 30, 2014, at 7:12 PM, Daniel Kulp <dk...@apache.org> 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 <ma...@gmail.com> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Repackaging of cxf-api to remove Spring dependencies
Posted by Daniel Kulp <dk...@apache.org>.
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 <ma...@gmail.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com