It makes sense.
Regards
JB
On 10/27/2011 09:10 AM, Gert Vanthienen wrote:
L.S.,
Yeah, either one of those solutions would obviously be a lot better, the
dev:dynamic-import is just a workaround or a way to test if adding more
imports to a bundle solves the problem.
However, wouldn't it be better if we could solve that in the components
themselves, e.g. if we add a 'Require-Bundle' for the shared library JARs to
all of our own components? I know that this is not being recommended
usually, but in our case, I don't think we support the use of multiple
versions of the same JBI component anyway and it would ease the transition
from ServiceMix 3 to ServiceMix 4 somewhat.
Wdyt?
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Thu, Oct 27, 2011 at 3:10 AM, Freeman Fang<[email protected]>wrote:
Hi,
Besides the Dynamic-Import way Gert mentioned here, I think Servicemix also
provide another solution.
I believe you're using JBI packaging in OSGi container, right?
If so, you can specify a classpath for your xbean.xml to refer classes
from other OSGi bundles, you needn't add dependency in your pom.xml or use
provided scope for this dependency(otherwise it will add dependency jar into
your SA, which can cause ClassCastException as you encounter, as those
dependencies already available in OSGi container).
Take a look at[1], the "New in Servicemix 4.2.0" part, I think you just
need add
<classpath>
<library>osgi:servicemix-**soap2</library>
</classpath>
to your xbean.xml
This is a common issue when you use JBI pakcaging for SA, but if you use
OSGi packaging, you won't see such issue, that's why we encourage to use
OSGi packaging for OSGi container.
We have cxf-wsdl-first-osgi-package(**for OSGi packaging) and
cxf-wsdl-first(for JBI packaging) examples shipped with SMX 4.x kit, which
can demonstrate what's difference between two packaging.
[1]http://servicemix.apache.**org/classloaders.html<http://servicemix.apache.org/classloaders.html>
Freeman
On 2011-10-27, at 上午5:00, Stefan Essl wrote:
Hi Gert,
thanks, this worked!
Please let me know if you need some more information on this issue!
Thanks,
Stefan
Am 26.10.2011 um 22:41 schrieb Gert Vanthienen:
Stefan,
No problem, sorry for not being more clear. It is a command you can enter
in
the servicemix console - out takes one parameter, the bundle id for the
servicemix camel bundle.
Regards,
Gert
On Oct 26, 2011 10:20 PM, "Stefan Essl"<
[email protected]**stuttgart.de<[email protected]>>
wrote:
Hi Gert,
sorry, but what's a dev:dynamic-import? I'm not that deep into SMX just
yet...
Thanks,
Stefan
Am 26.10.2011 um 22:17 schrieb Gert Vanthienen:
Stefan,
Just quickly glanced over the code and I'm beginning to suspect that
the
OSGi metadata for our JBI components might be the problem here. I'll
take a
better look in the morning, but if my guess is right, doing a
dev:dynamic-import on the ServiceMix camel bundle will avoid the issue,
even
with the original SA you were using.
Regards,
Gert
On Oct 26, 2011 9:35 PM, "Stefan Essl"<
[email protected]**stuttgart.de<[email protected]>>
wrote:
Hi Gert,
I'm running SMX 4.3.0 with the default servicemix-camel component.
If I add servicemix-shared, I get:
java.lang.**ClassNotFoundException:
org.apache.servicemix.soap.**util.stax.StaxSource in classloader
org.apache.xbean.spring.**context.**FileSystemXmlApplicationContex**t
Thanks,
Stefan
Am 26.10.2011 um 21:28 schrieb Gert Vanthienen:
Stefan,
And what happens if you add servicemix-shared as a dependency
instead?
Anyway, the new exception is because you now have two instances of
the
same
class active - one that's living inside the SA and another one in the
shared
library, so that's why you get this odd-looking exception.
One more question: what version of ServiceMix are you using? If
these
is
just the default servicemix-camel component and a normal SU/SA, you
definitely shouldn't bump into this thing so we should try to figure
out
what's wrong here to get it fixed.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.**blogspot.com/<http://gertvanthienen.blogspot.com/>
On Wed, Oct 26, 2011 at 9:10 PM, Stefan Essl<
[email protected]**stuttgart.de<[email protected]>>
wrote:
Hi Gert,
I get this within a servicemix-camel SU. If I add servicemix-soap2
to
the
maven dependencies, the SA deploys fine, but I get a really weird
error
on
execution:
java.lang.ClassCastException:
org.apache.servicemix.soap.**util.stax.StaxSource cannot be cast to
org.apache.servicemix.soap.**util.stax.StaxSource
Thanks,
Stefan
Am 26.10.2011 um 20:34 schrieb Gert Vanthienen:
Stefan,
What JBI component is the SU that causes the exception using? This
class
should be part of the default servicemix-shared shared library (it's
part
of
servicemix-soap2 to be exact) that contains the code that's being
used
by
all JBI components so you shouldn't really bump into this by using
just
the
standard JBI components.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.**blogspot.com/<http://gertvanthienen.blogspot.com/>
On Wed, Oct 26, 2011 at 7:46 PM, Stefan Essl<
[email protected]**stuttgart.de<[email protected]>>
wrote:
Hi everybody,
if I try to deploy my SA, I get the error:
java.lang.**ClassNotFoundException:
org.apache.servicemix.soap.**util.stax.StaxSource
I guess I'm missing some maven dependencies, but I can't work out
which
one...
Thanks,
Stefan
------------------------------**---------------
Freeman Fang
FuseSource
Email:[email protected]
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
