Hi Sergei, > -----Original Message----- > From: Sergey Beryozkin [mailto:sberyoz...@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:dk...@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 <ashaki...@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:dk...@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 > <mandys.in...@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 > >>>>> dk...@apache.org - http://dankulp.com/blog Talend Community Coder > >>>>> - http://coders.talend.com > >>>>> > >>>> > >>>> -- > >>>> Daniel Kulp > >>>> dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > >>>> http://coders.talend.com > >>> > >> > >> -- > >> Daniel Kulp > >> dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > >> http://coders.talend.com > > >
