Home » Archived » SeMantic Information Logistics Architecture (SMILA) » Best Practise to include Webservice into Pipeline
| |
| Re: Best Practise to include Webservice into Pipeline [message #783338 is a reply to message #765713] |
Wed, 25 January 2012 14:39   |
 Stephan Mehlhase
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
On 12/14/2011 04:02 PM, Juergen Schumacher wrote:
> Hi,
>
> Am 14.12.2011, 14:34 Uhr, schrieb Stephan Mehlhase
> <stephan.mehlhase@eml.org>:
>> we have a pipeline which needs to submit and receive data from a
>> Webservice (WSDL available), is there a straight-forward best practise
>> how to achieve this?
>>
>> My naive approach would be implementing this in a pipelet ...
>
> I would do it like this, too. Theoretically it would be possible to
> invoke the
> webservice from the SMILA BPEL workflow directly and use XPath
> statements to
> copy values from the webservice result to the SMILA records (there is an
> example for this in the o.e.s.processing.bpel.test bundle) ... but it's
> quite
> probably much easier to do this in a pipelet. At least if you are more
> accustomed
> to writing Java code instead of BPEL (:
>
> Regards,
> Juergen.
Hi,
thanks for that reply. I went with this approach and it worked fine,
until I recently changed my webservice client to use JAX. Now I'm
running into strange classpath problems.
I have a JAR containing the generated client code from wsimport. It also
contains all the libraries needed. But when executing the code to access
the webservice I get the following exception:
Caused by: javax.xml.ws.WebServiceException: Provider
com.sun.xml.ws.spi.ProviderImpl not found
at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:38)
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:133)
at javax.xml.ws.spi.Provider.provider(Provider.java:82)
at javax.xml.ws.Service.<init>(Service.java:56)
at org.eml.mwpws.LMWebService.<init>(LMWebService.java:42)
[....]
... 32 more
Caused by: java.lang.ClassNotFoundException: com.sun.xml.ws.spi.ProviderImpl
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:34)
... 42 more
I can definetely see the class com.sun.xml.ws.spi.ProviderImpl in the
jar. Also, I see that javax.xml.ws.spi.FactoryFinder is in the jar. So
it cannot access one class in the jar from another class in the jar? To
make matters worse, the class org.eml.mwpws.LMWebService is the one
created by wsimport and is also in the jar file. I'm very confused here,
and I'm not sure how to approach this problem.
Stephan
--
Stephan Mehlhase
European Media Laboratory GmbH
Schloss-Wolfsbrunnenweg 35
69118 Heidelberg
Amtsgericht Mannheim / HRB 335719
Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and
Managing
Director: Prof. Dr.-Ing. Andreas Reuter
http://www.eml-development.de
Testen Sie auch unsere neue Android Applikation zur Mediensteuerung:
http://market.android.com/search?q=pname:org.eml.upnp
|
|
| | |
| Re: Best Practise to include Webservice into Pipeline [message #783686 is a reply to message #783375] |
Thu, 26 January 2012 08:23 |
Stephan Mehlhase
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Hi,
I tried it and got the following error (not exception!):
Caused by: java.lang.LinkageError: loader constraint violation: when
resolving field "DATETIME" the class loader (instance of
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the
referring class, javax/xml/datatype/DatatypeConstants, and the class
loader (instance of <bootloader>) for the field's resolved type,
javax/xml/namespace/QName, have different Class objects for that type
The trace is (much longer):
at
com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.<clinit>(RuntimeBuiltinLeafInfoImpl.java:224)
at
com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.<init>(RuntimeTypeInfoSetImpl.java:61)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:129)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:81)
at
com.sun.xml.bind.v2.model.impl.ModelBuilder.<init>(ModelBuilder.java:152)
at
com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.<init>(RuntimeModelBuilder.java:89)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:431)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:288)
at
com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1111)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:154)
at
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:211)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:372)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:220)
at com.sun.xml.ws.spi.ProviderImpl$2.run(ProviderImpl.java:218)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.ws.spi.ProviderImpl.getEPRJaxbContext(ProviderImpl.java:217)
at com.sun.xml.ws.spi.ProviderImpl.<clinit>(ProviderImpl.java:88)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:36)
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:95)
at javax.xml.ws.spi.Provider.provider(Provider.java:82)
at javax.xml.ws.Service.<init>(Service.java:56)
at org.eml.mwpws.LMWebService.<init>(LMWebService.java:42)
[....]
My Manifest looks like this:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: TrainingPipelet
Bundle-SymbolicName: TrainingPipelet
Bundle-Version: 1.0.0.qualifier
SMILA-Pipelets: Pipelet1,
Pipelet2,
Pipelet3,
Pipelet4
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Require-Bundle: org.eclipse.smila.blackboard;bundle-version="0.9.0",
org.eclipse.smila.processing;bundle-version="0.9.0",
org.eclipse.smila.datamodel;bundle-version="0.9.0",
org.apache.commons.logging;bundle-version="1.1.1",
org.eclipse.smila.utils;bundle-version="0.9.0"
Bundle-ClassPath: ws-client-jar-with-dependencies.jar,
.
I'm using SMILA 0.9.
Stephan
On 01/25/2012 04:52 PM, Juergen Schumacher wrote:
> Just had a quit look at the source code of this FactoryFinder, and I think
> it could help to wrap the critical code section in
>
> final ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
> try {
>
> // Webservice client initialization goes here
>
> } finally {
> Thread.currentThread().setContextClassLoader(tccl);
> }
>
> If I'm not mistaken the FactoryFinder tries to use this
> ThreadContextClassLoader
> and there are always such problems when it's used in OSGi contexts.
>
> Cheers,
> Juergen.
--
Stephan Mehlhase
European Media Laboratory GmbH
Schloss-Wolfsbrunnenweg 35
69118 Heidelberg
Amtsgericht Mannheim / HRB 335719
Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and
Managing
Director: Prof. Dr.-Ing. Andreas Reuter
http://www.eml-development.de
Testen Sie auch unsere neue Android Applikation zur Mediensteuerung:
http://market.android.com/search?q=pname:org.eml.upnp
|
|
|
| Re: Best Practise to include Webservice into Pipeline [message #783713 is a reply to message #783686] |
Thu, 26 January 2012 09:29 |
Juergen Schumacher
Messages: 35
Registered: July 2009 |
Member |
|
|
Am 26.01.2012, 09:23 Uhr, schrieb Stephan Mehlhase
<stephan.mehlhase@eml.org>:
> Hi,
>
> I tried it and got the following error (not exception!):
>
> Caused by: java.lang.LinkageError: loader constraint violation: when
> resolving field "DATETIME" the class loader (instance of
> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the
> referring class, javax/xml/datatype/DatatypeConstants, and the class
> loader (instance of <bootloader>) for the field's resolved type,
> javax/xml/namespace/QName, have different Class objects for that type
Ok ... maybe it's not obvious, but we're getting closer (:
Can you remove everything from your webservice JAR that is also part
of the JDK? Especially all java/javax stuff?
Regards,
Jürgen.
|
|
|
| Re: Best Practise to include Webservice into Pipeline [message #783840 is a reply to message #783713] |
Thu, 26 January 2012 15:05 |
Stephan Mehlhase
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
On 01/26/2012 10:29 AM, Juergen Schumacher wrote:
> Am 26.01.2012, 09:23 Uhr, schrieb Stephan Mehlhase
> <stephan.mehlhase@eml.org>:
>
>> Hi,
>>
>> I tried it and got the following error (not exception!):
>>
>> Caused by: java.lang.LinkageError: loader constraint violation: when
>> resolving field "DATETIME" the class loader (instance of
>> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the
>> referring class, javax/xml/datatype/DatatypeConstants, and the class
>> loader (instance of <bootloader>) for the field's resolved type,
>> javax/xml/namespace/QName, have different Class objects for that type
>
> Ok ... maybe it's not obvious, but we're getting closer (:
>
> Can you remove everything from your webservice JAR that is also part
> of the JDK? Especially all java/javax stuff?
>
> Regards,
> Jürgen.
Hi,
thanks! After removing javax.* from the classpath it started to work. :)
Stephan
--
Stephan Mehlhase
European Media Laboratory GmbH
Schloss-Wolfsbrunnenweg 35
69118 Heidelberg
Amtsgericht Mannheim / HRB 335719
Managing Partner: Dr. h. c. Dr.-Ing. E. h. Klaus Tschira, Scientific and
Managing
Director: Prof. Dr.-Ing. Andreas Reuter
http://www.eml-development.de
Testen Sie auch unsere neue Android Applikation zur Mediensteuerung:
http://market.android.com/search?q=pname:org.eml.upnp
|
|
| | | | |
Goto Forum:
Current Time: Thu Apr 18 16:05:34 GMT 2024
Powered by FUDForum. Page generated in 0.02676 seconds |
] 
Search
Help
Register
Login
Home
