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 <[email protected]> wrote: > > Hi Sergei, > >> -----Original Message----- >> From: Sergey Beryozkin [mailto:[email protected]] >> Sent: Freitag, 2. Mai 2014 10:53 >> To: [email protected] >> 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:[email protected]] >>>> Sent: Donnerstag, 1. Mai 2014 23:49 >>>> To: [email protected] >>>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies >>>> >>>> >>>> On May 1, 2014, at 3:22 PM, Andrei Shakirin <[email protected]> >> 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:[email protected]] >>>>>> Sent: Donnerstag, 1. Mai 2014 18:03 >>>>>> To: [email protected] >>>>>> 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 <[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 >>>>>> >>>>>> -- >>>>>> Daniel Kulp >>>>>> [email protected] - http://dankulp.com/blog Talend Community Coder - >>>>>> http://coders.talend.com >>>> >>>> -- >>>> Daniel Kulp >>>> [email protected] - http://dankulp.com/blog Talend Community Coder - >>>> http://coders.talend.com >
