When starting to write the response, I think i found an issue. The SU classloader should be used by camel to create the context and discover components. This classloader SU will have several parents: one being the servicemix-camel component classloader, and several ones for the referenced shared libraries. However, I think one problem is that camel-core is defined in the servicemix-camel component, but camel components packaged in SL will need this jar too. The problem is that SLs can not reference components classloaders, this is the other way around. Furthermore, a shared library can not even reference another shared library. So I don't even see how it would work referencing a SL from the component, as camel-core will not be available to the SL classloader, hence the camel components in the SL should not be able to be instanciated. For your cxf SL, is camel-core included in the SL ? If yes, this is a bad idea, as each SL would have its own camel-core copy and they would not work together.
On Tue, Jul 29, 2008 at 11:45 AM, Willem Jiang <[EMAIL PROTECTED]> wrote: > Hi Guillaume, > > There are two issues in the ESB-261, the first is the camel-shared library > which contains camel-cxf component can not work in the Camel-SU( Please see > the issue description); the other is activemq camel component related issue( > I think it is resolved by taking activemq camel component out of > activemq-core). > > BTW, the 01-camel-shared library just contains camel-cxf component relates > jars. > My question is how does the service-camel component interact with the camel > SU, specially from the class loader perspective ? > > Thanks, > > Willem > > Guillaume Nodet wrote: >> >> I think some of the problems comes from the fact that ActiveMQ >> includes the activemq camel component, but ActiveMQ is in the >> container classpath, whereas Camel is not. So the activemq camel >> component can not really work, unless you put camel-core in the >> container classpath, or put a copy of activemq in the SU / SL and >> specifiy that you want the self first delegation instead of the >> default parent first. Have you tried for a component other than the >> activemq one ? >> >> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Hi Guillaume, >>> >>> Cool , I will head to write a camel-example to show how to create this >>> kind >>> of SU which is using this camel extension SL :) >>> >>> Cheers, >>> >>> Willem >>> >>> >>> Guillaume Nodet wrote: >>> >>>> >>>> I'm actually working on the OSGi bits and should commit something very >>>> soon, so we would not need such a shared library in smx4. >>>> For smx3, is the point #2 really needed ? I would have thought >>>> referencing the SL from the SU would work without problems and without >>>> the need to hack the component's jbi.xml. >>>> >>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> >>>>> 2008/7/28 Willem Jiang <[EMAIL PROTECTED]>: >>>>> >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> The camel component just contains the core camel jars, but some use >>>>>> cases >>>>>> require the use of addon components (for example camel-cxf) which are >>>>>> not >>>>>> present in the core camel jars. If you have multiple SU's with a >>>>>> dependency >>>>>> on an addon component then you will hit classloading conflicts >>>>>> (ClassCastException typically ). You currently need to: >>>>>> >>>>>> 1) Add the camel extension components to a jbi shared library >>>>>> >>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your >>>>>> shared >>>>>> library. >>>>>> >>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this >>>>>> enhancement >>>>>> is to add a placeholder shared library to the camel-core component. >>>>>> The >>>>>> shared library can be empty but will need to exist in the hot deploy >>>>>> directory. >>>>>> >>>>>> This would eliminate the need to hack the camel component's jbi.xml, >>>>>> you >>>>>> would just need to edite the camel shared library pom.xml and override >>>>>> the >>>>>> old camel shared library in the deploy directory. >>>>>> >>>>>> >>>>> >>>>> Yeah, sounds good to me. The other option would just be to use OSGi >>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and >>>>> then its no longer an issue >>>>> >>>>> -- >>>>> James >>>>> ------- >>>>> http://macstrac.blogspot.com/ >>>>> >>>>> Open Source Integration >>>>> http://open.iona.com >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
