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
<[EMAIL PROTECTED]> 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 <[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)
>>>>
>>>>
>>
>>
>
>
