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 <[email protected]> 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 <[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 > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com >
