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/
