Hi Guillaume,
The way that I tried to resolved the ESB-261 is putting the camel-cxf
related jars into SL for the servicemix-camel component to use. It does
not include any camel-core jar.
I just checked the camel component resolver code, it will use the
ObjectHelper to load the component property file.
public static InputStream loadResourceAsStream(String name) {
InputStream in = null;
ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
if (contextClassLoader != null) {
in = contextClassLoader.getResourceAsStream(name);
}
if (in == null) {
in =
ObjectHelper.class.getClassLoader().getResourceAsStream(name);
}
return in;
}
I guess when the SU start , if the thread context class loader is not
set or the thread context class loader is the servicemix camel
component's class loader , the camel-cxf's component (which in the cxf
SL) will not be found.
BTW, When I put the cxf SL into the servicemix camel component,
camel-core can find the camel-cxf related jars.
Willem
Guillaume Nodet wrote:
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
