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)
>>
>
