Sebastian,
That is a very likely hypothesis. A solution might be to copy some of
the third party libraries to the lib/optional directory to get them
loaded in another classloader in the hierarchy (or the opposite, adding
more JAR files to the SU itself -- depending on the exact problem).
Regards,
Gert
Sebastian Gomez wrote:
Looking further into my problem I've come to the conclusion that it's
something to do with ClassLoaders. Doing
"ClassLoader.getSystemClassLoader()" (it's what my third party code
does) in a bean deployed in an embedded ServiceMix gives me a
different classloader than doing it in a standard ServiceMix. By
different I mean that the one in the embedded version has much more
classes. Reading about classloaders in ServiceMix I've seen the four
level hierarchy that exists in SM so my hypothesis is that getting the
SystemClassLoader in a standard JBI container returns a higher level
classloader than the ServiceMix container classloader (therefore it
won't find classes declared inside the container), while in an
embedded JBI container it returns a classloader with all the classes,
even those declared on the service unit level.
Does my hypothesis make sense? Please answer.
Best regards,
Sebastian Gomez.
On Fri, Aug 1, 2008 at 9:43 AM, Sebastian Gomez <[EMAIL PROTECTED]> wrote:
I've been investigating a bit and I've seen the
JSSESocketFactory.create(...) method starts with
if (sslFactory == null) {
initFactory();
}
that in case the sslFactory is not yet initialized, it creates a new
DefaultSSLSocketFactory.
My guess is that the embedded version does not initialize a
sslFactory, so when my third party code tries to create a socket it
creates a new one. On the other hand, in the standard version
somewhere ServiceMix must have created an sslFactory so my classes try
to use that socket and therefore get the security error. Does this
idea make sense? Does ServiceMix (not embedded) create some sslSocket
at any point?
Hope someone can help.
Sebastian Gomez.
On Thu, Jul 31, 2008 at 1:38 PM, Sebastian Gomez <[EMAIL PROTECTED]> wrote:
Hi.
I'm trying to send a signed message from a bean endpoint to a web
service outside the ESB. I know servicemix-bean is a service engine,
so I'm not supposed to do it that way, but I've got to use some third
party java classes to communicate with the WS. When these try to
create the SSLSocket for the connection, they throw the following
exception (pasted below). The thing is that this works using the
embedded jbi container, but when using the standard version it
doesn't. I don't know if it can be something to do with ports that
ServiceMix may or may not use depending on which version it's
executing.
Does anyone have any idea of what could be happening?
Thanks in advance.
Sebastian Gomez.
PS: Here is the exception trace:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.net.SocketException: third party class message
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:
java.net.SocketException: third party class message
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.j
ava:156)
at org.apache.axis.components.net.JSSESocketFactory.create(JSSESocketFac
tory.java:130)
at org.apache.axis.transport.http.HTTPSender.getSocket(HTTPSender.java:1
57)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:114)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrateg
y.java:71)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:150)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:120)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:180)
at org.apache.axis.client.Call.invokeEngine(Call.java:2564)
at org.apache.axis.client.Call.invoke(Call.java:2553)
at org.apache.axis.client.Call.invoke(Call.java:1753)
at third.party.class.invoke(Unknown Source)
at third.party.class.invoke(Unknown Source)
at myBean.myMethod(myBean.j
ava:133)
at myBean.onMessageExchange(myBean.ja
va:100)
at org.apache.servicemix.bean.BeanEndpoint.onProviderExchange(BeanEndpoi
nt.java:235)
at org.apache.servicemix.bean.BeanEndpoint.process(BeanEndpoint.java:211
)
at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLi
feCycle.java:538)
at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(Async
BaseLifeCycle.java:490)
at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLife
Cycle.java:46)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBoun
d(DeliveryChannelImpl.java:610)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlo
w.java:172)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.j
ava:167)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.jav
a:134)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)
