You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Sebastian Gomez <sa...@gmail.com> on 2008/08/01 09:43:06 UTC
Re: SocketException in servicemix-bean
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 <sa...@gmail.com> 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)
>
Re: SocketException in servicemix-bean
Posted by Sebastian Gomez <sa...@gmail.com>.
Hi Gert, thanks for answering.
I came to a solution without having to play around very much with the
jars and lib directories, but I wanted to be sure that this was
occurring because of the classloader and not because of something
else. Telling me that my hypothesis is very likely makes me more
certain that the issue is because of that, so I'll believe it unless
someone tells me the opposite.
Thanks for helping.
Sebastian Gomez.
On Mon, Aug 4, 2008 at 10:04 PM, Gert Vanthienen
<ge...@skynet.be> wrote:
> 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 <sa...@gmail.com> 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 <sa...@gmail.com>
>>> 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)
>>>>
>>>>
>>
>>
>
>
Re: SocketException in servicemix-bean
Posted by Gert Vanthienen <ge...@skynet.be>.
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 <sa...@gmail.com> 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 <sa...@gmail.com> 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)
>>>
>>>
>
>
Re: SocketException in servicemix-bean
Posted by Sebastian Gomez <sa...@gmail.com>.
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 <sa...@gmail.com> 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 <sa...@gmail.com> 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)
>>
>