Re: Using XStream in OSGi Project
Hi Dhiego, that means that the class loader of the XStream bundle don't have access to your Project2 class loader. You need to register a composed class loader to XStream. Have a look to this code: https://github.com/onexus/onexus/blob/develop/org.onexus.resource.serializer.xstream/src/main/java/org/onexus/resource/serializer/xstream/internal/ResourceSerializer.java The important part is: this.xstream.setClassLoader(new RegisteredClassLoader()); And then at activation time all the bundles that produce classes that you want to be able to serialize you must register their class loader using the register method. I still have one problem with XStream, imagine I serialize an instance of class A (Project2 bundle) then I reload Project2 bundle then it's imposible to recover the serialized instance because we have a new version of class A. May be someone in the list knows a better aproach. Regards, Jordi On Thu, Jan 24, 2013 at 6:34 AM, Dhiego Abrantes de Oliveira Martins dhiegoabran...@gmail.com wrote: Hi all, I'm developing a project that uses XStream lib to manipulate XML. There are a Project1 that is a service and have a maven dependence to xstream. The Project2 is a implementation of Project1 and have a transient dependency of XStream through Project1. The Project3 is just a client of Project2, just a consumer. I can start Project1 and Project2 normally. But, when I start the Project3 and some method try to use XStream lib, I get that error: Exception in thread Thread-12 java.lang.NoClassDefFoundError: org/xmlpull/v1/XmlPullParserFactory at com.thoughtworks.xstream.io.xml.XppDriver.createParser(XppDriver.java:57) at com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:58) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886) at br.ufpe.cin.main.ServiceDescriptorImpl.__getServiceDescriptors(ServiceDescriptorImpl.java:24) at br.ufpe.cin.main.ServiceDescriptorImpl.getServiceDescriptors(ServiceDescriptorImpl.java) at ipojo.example.hello.client.HelloClient.__invokeHelloServices(HelloClient.java:94) at ipojo.example.hello.client.HelloClient.invokeHelloServices(HelloClient.java) at ipojo.example.hello.client.HelloClient.__run(HelloClient.java:54) at ipojo.example.hello.client.HelloClient.run(HelloClient.java) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ClassNotFoundException: org.xmlpull.v1.XmlPullParserFactory not found by com.springsource.org.xmlpull [53] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317) at org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 11 more My installed bundles: START LEVEL 1 ID State Level Name [ 0] [Active ] [0] System Bundle (4.0.3) [ 1] [Active ] [1] Distributed OSGi Distribution Software Single-Bundle Distribution (1.3.1) [ 2] [Active ] [1] Apache Felix Bundle Repository (1.4.3) [ 3] [Active ] [1] Apache Felix Configuration Admin Service (1.2.6) [ 4] [Active ] [1] Apache Felix EventAdmin (1.2.2) [ 5] [Active ] [1] Apache Felix iPOJO (1.6.0) [ 6] [Active ] [1] Apache Felix iPOJO Arch Command (1.6.0) [ 7] [Active ] [1] Apache Felix Shell Service (1.4.2) [ 8] [Active ] [1] Apache Felix Shell TUI (1.4.1) [ 9] [Active ] [1] Hello Service (1.0.0) [ 10] [Active ] [1] Hello Service Provider (1.0.0) [ 12] [Active ] [1] Adder Service Provider (0.0.1.SNAPSHOT) [ 13] [Active ] [1] Adder Service Interface (0.0.1.SNAPSHOT) [ 36] [Active ] [1] Hello Client (1.0.0) [ 42] [Active ] [1] Thoughtworks XStream (1.4.1) [ 49] [Active ] [1] Service Descriptor Specification (1.0.0) [ 50] [Active ] [1] Service Descriptor Provider (1.0.0) [ 52] [Active ] [1] Java XML Stream API (StAX) (1.0.1) [ 53] [Active ] [1] XMLPULL V1 API (1.1.4.c) Best regards! []'s Dhiego -- a10! i fins aviat. J:-Deu - To unsubscribe, e-mail:
Re: Using XStream in OSGi Project
Thanks Jodi! Is the best approach to work with xstream? Can I just start xstream bundle? I'm was trying to find some approach more 'automatic', like: a) embbed into project1 Abs, __ *Dhiego** **Abrantes** de Oliveira Martins* *Computer Science, M.Sc. Candidate at UFPE* www.dhiegoabrantes.com +55 83 .1081 ***Any fool can write code that a computer can understand. Good programmers write code that humans can understand*. (Martin Fowler) 2013/1/24 Jordi Deu-Pons jo...@jordeu.net Hi Dhiego, that means that the class loader of the XStream bundle don't have access to your Project2 class loader. You need to register a composed class loader to XStream. Have a look to this code: https://github.com/onexus/onexus/blob/develop/org.onexus.resource.serializer.xstream/src/main/java/org/onexus/resource/serializer/xstream/internal/ResourceSerializer.java The important part is: this.xstream.setClassLoader(new RegisteredClassLoader()); And then at activation time all the bundles that produce classes that you want to be able to serialize you must register their class loader using the register method. I still have one problem with XStream, imagine I serialize an instance of class A (Project2 bundle) then I reload Project2 bundle then it's imposible to recover the serialized instance because we have a new version of class A. May be someone in the list knows a better aproach. Regards, Jordi On Thu, Jan 24, 2013 at 6:34 AM, Dhiego Abrantes de Oliveira Martins dhiegoabran...@gmail.com wrote: Hi all, I'm developing a project that uses XStream lib to manipulate XML. There are a Project1 that is a service and have a maven dependence to xstream. The Project2 is a implementation of Project1 and have a transient dependency of XStream through Project1. The Project3 is just a client of Project2, just a consumer. I can start Project1 and Project2 normally. But, when I start the Project3 and some method try to use XStream lib, I get that error: Exception in thread Thread-12 java.lang.NoClassDefFoundError: org/xmlpull/v1/XmlPullParserFactory at com.thoughtworks.xstream.io.xml.XppDriver.createParser(XppDriver.java:57) at com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:58) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886) at br.ufpe.cin.main.ServiceDescriptorImpl.__getServiceDescriptors(ServiceDescriptorImpl.java:24) at br.ufpe.cin.main.ServiceDescriptorImpl.getServiceDescriptors(ServiceDescriptorImpl.java) at ipojo.example.hello.client.HelloClient.__invokeHelloServices(HelloClient.java:94) at ipojo.example.hello.client.HelloClient.invokeHelloServices(HelloClient.java) at ipojo.example.hello.client.HelloClient.__run(HelloClient.java:54) at ipojo.example.hello.client.HelloClient.run(HelloClient.java) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ClassNotFoundException: org.xmlpull.v1.XmlPullParserFactory not found by com.springsource.org.xmlpull [53] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317) at org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 11 more My installed bundles: START LEVEL 1 ID State Level Name [ 0] [Active ] [0] System Bundle (4.0.3) [ 1] [Active ] [1] Distributed OSGi Distribution Software Single-Bundle Distribution (1.3.1) [ 2] [Active ] [1] Apache Felix Bundle Repository (1.4.3) [ 3] [Active ] [1] Apache Felix Configuration Admin Service (1.2.6) [ 4] [Active ] [1] Apache Felix EventAdmin (1.2.2) [ 5] [Active ] [1] Apache Felix iPOJO (1.6.0) [ 6] [Active ] [1] Apache Felix iPOJO Arch Command (1.6.0) [ 7] [Active ] [1] Apache Felix Shell Service (1.4.2) [ 8] [Active ] [1] Apache Felix Shell TUI (1.4.1) [ 9] [Active ] [1] Hello Service (1.0.0) [ 10] [Active ] [1] Hello Service Provider (1.0.0) [ 12] [Active ] [1] Adder Service Provider (0.0.1.SNAPSHOT) [ 13] [Active ] [
Re: Using XStream in OSGi Project
Thanks Jordi! Is the best approach to work with xstream? Can I just start xstream bundle? I'm was trying to find some approach more 'automatic', like: a) embbed xstream libs into project1; or just install xstream bundles in container to project1 use it automatically; The classloader solution is a workaround? Best regards! []'s Dhiego 2013/1/24 Jordi Deu-Pons jo...@jordeu.net Hi Dhiego, that means that the class loader of the XStream bundle don't have access to your Project2 class loader. You need to register a composed class loader to XStream. Have a look to this code: https://github.com/onexus/onexus/blob/develop/org.onexus.resource.serializer.xstream/src/main/java/org/onexus/resource/serializer/xstream/internal/ResourceSerializer.java The important part is: this.xstream.setClassLoader(new RegisteredClassLoader()); And then at activation time all the bundles that produce classes that you want to be able to serialize you must register their class loader using the register method. I still have one problem with XStream, imagine I serialize an instance of class A (Project2 bundle) then I reload Project2 bundle then it's imposible to recover the serialized instance because we have a new version of class A. May be someone in the list knows a better aproach. Regards, Jordi On Thu, Jan 24, 2013 at 6:34 AM, Dhiego Abrantes de Oliveira Martins dhiegoabran...@gmail.com wrote: Hi all, I'm developing a project that uses XStream lib to manipulate XML. There are a Project1 that is a service and have a maven dependence to xstream. The Project2 is a implementation of Project1 and have a transient dependency of XStream through Project1. The Project3 is just a client of Project2, just a consumer. I can start Project1 and Project2 normally. But, when I start the Project3 and some method try to use XStream lib, I get that error: Exception in thread Thread-12 java.lang.NoClassDefFoundError: org/xmlpull/v1/XmlPullParserFactory at com.thoughtworks.xstream.io.xml.XppDriver.createParser(XppDriver.java:57) at com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:58) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886) at br.ufpe.cin.main.ServiceDescriptorImpl.__getServiceDescriptors(ServiceDescriptorImpl.java:24) at br.ufpe.cin.main.ServiceDescriptorImpl.getServiceDescriptors(ServiceDescriptorImpl.java) at ipojo.example.hello.client.HelloClient.__invokeHelloServices(HelloClient.java:94) at ipojo.example.hello.client.HelloClient.invokeHelloServices(HelloClient.java) at ipojo.example.hello.client.HelloClient.__run(HelloClient.java:54) at ipojo.example.hello.client.HelloClient.run(HelloClient.java) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ClassNotFoundException: org.xmlpull.v1.XmlPullParserFactory not found by com.springsource.org.xmlpull [53] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1317) at org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1481) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 11 more My installed bundles: START LEVEL 1 ID State Level Name [ 0] [Active ] [0] System Bundle (4.0.3) [ 1] [Active ] [1] Distributed OSGi Distribution Software Single-Bundle Distribution (1.3.1) [ 2] [Active ] [1] Apache Felix Bundle Repository (1.4.3) [ 3] [Active ] [1] Apache Felix Configuration Admin Service (1.2.6) [ 4] [Active ] [1] Apache Felix EventAdmin (1.2.2) [ 5] [Active ] [1] Apache Felix iPOJO (1.6.0) [ 6] [Active ] [1] Apache Felix iPOJO Arch Command (1.6.0) [ 7] [Active ] [1] Apache Felix Shell Service (1.4.2) [ 8] [Active ] [1] Apache Felix Shell TUI (1.4.1) [ 9] [Active ] [1] Hello Service (1.0.0) [ 10] [Active ] [1] Hello Service Provider (1.0.0) [ 12] [Active ] [1] Adder Service Provider (0.0.1.SNAPSHOT) [ 13] [Active ] [1] Adder Service Interface (0.0.1.SNAPSHOT) [ 36] [Active ] [1] Hello Client (1.0.0) [ 42]
Re: Using XStream in OSGi Project
The classloader solution is a workaround? I don't think it's a workaround. Because of the OSGi class loading mechanism, there is a need to use the correct class loader when you are unserializing your class instance. I don't known if there is a better way to do this. -- a10! i fins aviat. J:-Deu - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Converting XStream to OSGi
Hi everyone,
In my OSGi-based project, I need to use the XStream open source library
http://xstream.codehaus.org/
Unfortunately, there is no OSGi version of the project, so I created an
empty Maven project and added XStream as a dependency as follows
(pom.xml file is attached):
dependencies
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.4.2/version
/dependency
/dependencies
I then configured BND to embed XStream and its dependencies:
!-- Packaging --
packagingbundle/packaging
!-- Build --
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.3.7/version
extensionstrue/extensions
configuration
instructions
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
Export-Package
com.thoughtworks.xstream,
com.thoughtworks.xstream.io,
com.thoughtworks.xstream.io.xml,
/Export-Package
Embed-Dependency
*;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2,
/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
/plugin
/plugins
/build
When I look in the generated Jar, I find an xstream-1.4.2.jar file as
well as the com/toughworks/xstream folder hierarchy with the class files
(which seems redundant with the xstream-1.4.2.jar file, but the class in
the latest are not the same than the ones under com/toughworks/xstream
folder).
My problem is that there is no trace anywhere of the transitive
dependencies.
When installing the bundle, I have the following error message in felix:
ERROR: Bundle xstream-osgi [5] Error starting
file:/home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
xstream-osgi [5]: Unable to resolve 5.0: missing requirement [5.0]
osgi.wiring.package; (osgi.wiring.package=com.bea.xml.stream))
What am I doing wrong? Is there a cleaner way to convert to OSGi a
library that I do not develop?
Kind regards,
Ben
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
!-- === --
!-- POM relationships --
!-- === --
!-- Maven coordinates --
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream-osgi/artifactId
version1.4.2/version
!-- Dependencies --
dependencies
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.4.2/version
/dependency
/dependencies
!-- === --
!-- Build settings --
!-- === --
!-- Packaging --
packagingbundle/packaging
!-- Build --
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.3.7/version
extensionstrue/extensions
configuration
instructions
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
Export-Package
com.thoughtworks.xstream,
com.thoughtworks.xstream.io,
com.thoughtworks.xstream.io.xml,
/Export-Package
Embed-Dependency
*;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2,
/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Converting XStream to OSGi
Hi, Am 11.04.2012 um 12:12 schrieb Benoît Thiébault: Hi everyone, In my OSGi-based project, I need to use the XStream open source library http://xstream.codehaus.org/ ... Export-Package com.thoughtworks.xstream, com.thoughtworks.xstream.io, com.thoughtworks.xstream.io.xml, /Export-Package Embed-Dependency *;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2, /Embed-Dependency ... When I look in the generated Jar, I find an xstream-1.4.2.jar file as well as the com/toughworks/xstream folder hierarchy with the class files (which seems redundant with the xstream-1.4.2.jar file, but the class in the latest are not the same than the ones under com/toughworks/xstream folder). Looks like you would want to use the _exportcontents directive instead of the Export-Package directive. The former just creates the Export-Package header while the latter also copies the packages. Also you might want to inline the library using the inline:=true directive in Embed-Dependency My problem is that there is no trace anywhere of the transitive dependencies. When installing the bundle, I have the following error message in felix: ERROR: Bundle xstream-osgi [5] Error starting file:/home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jarfile:///home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle xstream-osgi [5]: Unable to resolve 5.0: missing requirement [5.0] osgi.wiring.package; (osgi.wiring.package=com.bea.xml.stream)) This probably comes from the dependency analysis of the xtsream classes which generates the Import-Package statements. Looks like com.bea.xml.stream may be consumed by xstreams if available. You might want to define these imports as optional, such as: Import-Package com.bea.*;resolution:=optional /Import-Package Regards Felix What am I doing wrong? Is there a cleaner way to convert to OSGi a library that I do not develop? Kind regards, Ben pom.xml - To unsubscribe, e-mail: users-unsubscr...@felix.apache.orgmailto:users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.orgmailto:users-h...@felix.apache.org
Re: Converting XStream to OSGi
Hi Felix and thanks for your answer, I used the _exportcontents directive instead of the Export-Package directive and did not notice any difference. Still only XStream files in the Jar, no dependency (maybe this is normal, I only export XStream packages, not its dependencies). I used the inline argument and now the generated jar only contains class files, no more embedded jar. Looks cleaner that way. Regarding the optional import argument, I had to explicitly declare all the imports (before, I used no Import-Package tag, which is the same as Import-Package*/Import-Package). Now, I have the following: Import-Package com.bea.xml.stream;resolution:=optional, com.ctc.wstx.stax;resolution:=optional, javax.security.auth, javax.swing, javax.swing.plaf, javax.xml.datatype, javax.xml.namespace, javax.xml.parsers, javax.xml.stream, javax.xml.transform, javax.xml.transform.sax, javax.xml.transform.stream, net.sf.cglib.proxy;resolution:=optional, nu.xom;resolution:=optional, org.codehaus.jettison;resolution:=optional, org.codehaus.jettison.mapped;resolution:=optional, org.dom4j;resolution:=optional, org.dom4j.io;resolution:=optional, org.dom4j.tree;resolution:=optional, org.jdom;resolution:=optional, org.jdom.input;resolution:=optional, org.joda.time;resolution:=optional, org.joda.time.format;resolution:=optional, org.kxml2.io;resolution:=optional, org.w3c.dom, org.xml.sax, org.xml.sax.helpers, org.xmlpull.mxp1;resolution:=optional, org.xmlpull.v1;resolution:=optional, sun.misc, sun.reflect /Import-Package For sun.misc and sun.reflect, I created two empty OSGi bundles just exporting the packages to make them available in OSGi context. Notice there are plenty of resolution:=optional arguments. I am not very happy about those, I just added one for each unresolved constraint error message in Felix. It seems to work (I started the bundle and successfully used some basic functions of XStream with another one), but I am not very confident with the way I declared almost everything as optional... Kind regards, Ben Le 11/04/2012 13:58, Felix Meschberger a écrit : Hi, Am 11.04.2012 um 12:12 schrieb Benoît Thiébault: Hi everyone, In my OSGi-based project, I need to use the XStream open source library http://xstream.codehaus.org/ ... Export-Package com.thoughtworks.xstream, com.thoughtworks.xstream.io, com.thoughtworks.xstream.io.xml, /Export-Package Embed-Dependency *;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2, /Embed-Dependency ... When I look in the generated Jar, I find an xstream-1.4.2.jar file as well as the com/toughworks/xstream folder hierarchy with the class files (which seems redundant with the xstream-1.4.2.jar file, but the class in the latest are not the same than the ones under com/toughworks/xstream folder). Looks like you would want to use the_exportcontents directive instead of theExport-Package directive. The former just creates the Export-Package header while the latter also copies the packages. Also you might want to inline the library using the inline:=true directive in Embed-Dependency My problem is that there is no trace anywhere of the transitive dependencies. When installing the bundle, I have the following error message in felix: ERROR: Bundle xstream-osgi [5] Error starting file:/home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jarfile:///home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle xstream-osgi [5]: Unable to resolve 5.0: missing requirement [5.0] osgi.wiring.package; (osgi.wiring.package=com.bea.xml.stream)) This probably comes from the dependency analysis of the xtsream classes which generates the Import-Package statements. Looks like com.bea.xml.stream may be consumed by xstreams if available. You might want to define these imports as optional, such as: Import-Package
Re: Converting XStream to OSGi
Hi,
before you go too deep with this check this bundle:
http://search.maven.org/#artifactdetails|org.apache.servicemix.bundles|org.apache.servicemix.bundles.xstream|1.4.2_2|bundle
Christian
Am 11.04.2012 12:12, schrieb Benoît Thiébault:
Hi everyone,
In my OSGi-based project, I need to use the XStream open source
library http://xstream.codehaus.org/
Unfortunately, there is no OSGi version of the project, so I created
an empty Maven project and added XStream as a dependency as follows
(pom.xml file is attached):
dependencies
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.4.2/version
/dependency
/dependencies
I then configured BND to embed XStream and its dependencies:
!-- Packaging --
packagingbundle/packaging
!-- Build --
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.3.7/version
extensionstrue/extensions
configuration
instructions
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
Export-Package
com.thoughtworks.xstream,
com.thoughtworks.xstream.io,
com.thoughtworks.xstream.io.xml,
/Export-Package
Embed-Dependency
*;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2,
/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
/plugin
/plugins
/build
When I look in the generated Jar, I find an xstream-1.4.2.jar file as
well as the com/toughworks/xstream folder hierarchy with the class
files (which seems redundant with the xstream-1.4.2.jar file, but the
class in the latest are not the same than the ones under
com/toughworks/xstream folder).
My problem is that there is no trace anywhere of the transitive
dependencies.
When installing the bundle, I have the following error message in felix:
ERROR: Bundle xstream-osgi [5] Error starting
file:/home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
xstream-osgi [5]: Unable to resolve 5.0: missing requirement [5.0]
osgi.wiring.package; (osgi.wiring.package=com.bea.xml.stream))
What am I doing wrong? Is there a cleaner way to convert to OSGi a
library that I do not develop?
Kind regards,
Ben
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Converting XStream to OSGi
I tried that bundle and had a unresolved constraint error on
com.ctc.wstx.stax...
But thanks for the link
Le 11/04/2012 12:31, Christian Schneider a écrit :
Hi,
before you go too deep with this check this bundle:
http://search.maven.org/#artifactdetails|org.apache.servicemix.bundles|org.apache.servicemix.bundles.xstream|1.4.2_2|bundle
Christian
Am 11.04.2012 12:12, schrieb Benoît Thiébault:
Hi everyone,
In my OSGi-based project, I need to use the XStream open source
library http://xstream.codehaus.org/
Unfortunately, there is no OSGi version of the project, so I created
an empty Maven project and added XStream as a dependency as follows
(pom.xml file is attached):
dependencies
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.4.2/version
/dependency
/dependencies
I then configured BND to embed XStream and its dependencies:
!-- Packaging --
packagingbundle/packaging
!-- Build --
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.3.7/version
extensionstrue/extensions
configuration
instructions
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
Export-Package
com.thoughtworks.xstream,
com.thoughtworks.xstream.io,
com.thoughtworks.xstream.io.xml,
/Export-Package
Embed-Dependency
*;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2,
/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
/plugin
/plugins
/build
When I look in the generated Jar, I find an xstream-1.4.2.jar file as
well as the com/toughworks/xstream folder hierarchy with the class
files (which seems redundant with the xstream-1.4.2.jar file, but the
class in the latest are not the same than the ones under
com/toughworks/xstream folder).
My problem is that there is no trace anywhere of the transitive
dependencies.
When installing the bundle, I have the following error message in felix:
ERROR: Bundle xstream-osgi [5] Error starting
file:/home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
xstream-osgi [5]: Unable to resolve 5.0: missing requirement [5.0]
osgi.wiring.package; (osgi.wiring.package=com.bea.xml.stream))
What am I doing wrong? Is there a cleaner way to convert to OSGi a
library that I do not develop?
Kind regards,
Ben
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Dr Benoît Thiébault
Project Manager
Artenum Toulouse - Science Groupware
http://www.artenum.com
Bâtiment Calfocenter
10, rue Marguerite-Long
31320 Castanet-Tolosan
France
Phone: +33 (0)5 82 95 19 00
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Converting XStream to OSGi
I guess you might need another bundle.
Try mvn:org.codehaus.woodstox/woodstox-core-asl/4.1.1 it exports this
package.
Christian
Am 11.04.2012 15:37, schrieb Benoît Thiébault:
I tried that bundle and had a unresolved constraint error on
com.ctc.wstx.stax...
But thanks for the link
Le 11/04/2012 12:31, Christian Schneider a écrit :
Hi,
before you go too deep with this check this bundle:
http://search.maven.org/#artifactdetails|org.apache.servicemix.bundles|org.apache.servicemix.bundles.xstream|1.4.2_2|bundle
Christian
Am 11.04.2012 12:12, schrieb Benoît Thiébault:
Hi everyone,
In my OSGi-based project, I need to use the XStream open source
library http://xstream.codehaus.org/
Unfortunately, there is no OSGi version of the project, so I created
an empty Maven project and added XStream as a dependency as follows
(pom.xml file is attached):
dependencies
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.4.2/version
/dependency
/dependencies
I then configured BND to embed XStream and its dependencies:
!-- Packaging --
packagingbundle/packaging
!-- Build --
build
plugins
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version2.3.7/version
extensionstrue/extensions
configuration
instructions
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
Export-Package
com.thoughtworks.xstream,
com.thoughtworks.xstream.io,
com.thoughtworks.xstream.io.xml,
/Export-Package
Embed-Dependency
*;groupId=com.thoughtworks.xstream;artifactId=xstream;version=1.4.2,
/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
/instructions
/configuration
/plugin
/plugins
/build
When I look in the generated Jar, I find an xstream-1.4.2.jar file
as well as the com/toughworks/xstream folder hierarchy with the
class files (which seems redundant with the xstream-1.4.2.jar file,
but the class in the latest are not the same than the ones under
com/toughworks/xstream folder).
My problem is that there is no trace anywhere of the transitive
dependencies.
When installing the bundle, I have the following error message in
felix:
ERROR: Bundle xstream-osgi [5] Error starting
file:/home/ben/Felix-4.0.2/bundle/xstream-osgi-1.4.2.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
xstream-osgi [5]: Unable to resolve 5.0: missing requirement [5.0]
osgi.wiring.package; (osgi.wiring.package=com.bea.xml.stream))
What am I doing wrong? Is there a cleaner way to convert to OSGi a
library that I do not develop?
Kind regards,
Ben
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
XStream and OSGi
Hi all, in an OSGi-based project of mine I'm trying to use XStream to marshall/unmarshall data structures to/from XML. Saving data to XML is no big issue, but restoring it from XML throws a CannotResolveClass [1] exception. I've googled a bit and it seems that XStream requires some tampering with ClassLoaders [2, 3], which I usually try to avoid, even more within an OSGi container. Question 1: Were any of you able to use XStream within an OSGi container successfully? Question 2: Do you suggest any other XML marshalling/unmarshalling library that is more OSGi-friendly, so to say? [1]: com.thoughtworks.xstream.mapper.CannotResolveClassException [2]: http://xstream.codehaus.org/faq.html#Serialization_ClassLoader [3]: http://osdir.com/ml/java.xstream.user/2008-08/msg00015.html Thanks, -- Guido Spadotto - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Hi Guido, Why don't you use jaxb + camel. Please have a look here in the doc : http://camel.apache.org/jaxb.html Regards, Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com On Mon, Aug 17, 2009 at 2:57 PM, Guido Spadotto gspado...@soluta.netwrote: Hi all, in an OSGi-based project of mine I'm trying to use XStream to marshall/unmarshall data structures to/from XML. Saving data to XML is no big issue, but restoring it from XML throws a CannotResolveClass [1] exception. I've googled a bit and it seems that XStream requires some tampering with ClassLoaders [2, 3], which I usually try to avoid, even more within an OSGi container. Question 1: Were any of you able to use XStream within an OSGi container successfully? Question 2: Do you suggest any other XML marshalling/unmarshalling library that is more OSGi-friendly, so to say? [1]: com.thoughtworks.xstream.mapper.CannotResolveClassException [2]: http://xstream.codehaus.org/faq.html#Serialization_ClassLoader [3]: http://osdir.com/ml/java.xstream.user/2008-08/msg00015.html Thanks, -- Guido Spadotto - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
In the [3] link in your message the guy has tried this: xStream.setClassLoader(Thread.currentThread().getContextClassLoader()); Instead he should have tried this xStream.setClassLoader(getClass().getClassLoader()); The idea is to tell xStream to load classes from your own class loader, aka your bundle. I am not familiar with XStream but I would guess serialization works because you pass XStream an Object, it picks up a Class from it and uses reflection to serialize. On the deserialization pass however XStream has only a String for the name of the class to deserialize. It can't get that class from it's own class loader because it does not import it. XStream would have to import the entire world so it can deserialize any class it meets. This can be done with the following header in the XStream bundle manifest. Dynamic-Import: * This will cause the XStream bundle to import the entire world on demand - it could work but is a bad idea - all kinds of classes clashing inside the XStream class space :) Instead you tell XStream to use your bundle's ClassLoader to resolve String names to Class objects living inside your bundle. They don't need to even be exported because XStream uses reflection and only needs a Class object. This approach will work safely if all deserialized classes are located in one bundle. If you build object graphs out of classes from many bundles I am afraid you can have problems. To resolve the issue without importing the world some fancy classload bridging has to be done. Look here if you fancy the gory details: http://rinswind.blogspot.com/2009/08/classload-acrobatics-dynamic-code.html As I said I am not familiar with XStream - I am familiar with the problem as I understand it. So forgive me if I am completely out of line :) Cheers, Todor Guido Spadotto wrote: Hi all, in an OSGi-based project of mine I'm trying to use XStream to marshall/unmarshall data structures to/from XML. Saving data to XML is no big issue, but restoring it from XML throws a CannotResolveClass [1] exception. I've googled a bit and it seems that XStream requires some tampering with ClassLoaders [2, 3], which I usually try to avoid, even more within an OSGi container. Question 1: Were any of you able to use XStream within an OSGi container successfully? Question 2: Do you suggest any other XML marshalling/unmarshalling library that is more OSGi-friendly, so to say? [1]: com.thoughtworks.xstream.mapper.CannotResolveClassException [2]: http://xstream.codehaus.org/faq.html#Serialization_ClassLoader [3]: http://osdir.com/ml/java.xstream.user/2008-08/msg00015.html Thanks, - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Todor Boev wrote: In the [3] link in your message the guy has tried this: xStream.setClassLoader(Thread.currentThread().getContextClassLoader()); Instead he should have tried this xStream.setClassLoader(getClass().getClassLoader()); The idea is to tell xStream to load classes from your own class loader, aka your bundle. I am not familiar with XStream but I would guess serialization works because you pass XStream an Object, it picks up a Class from it and uses reflection to serialize. On the deserialization pass however XStream has only a String for the name of the class to deserialize. It can't get that class from it's own class loader because it does not import it. XStream would have to import the entire world so it can deserialize any class it meets. This can be done with the following header in the XStream bundle manifest. Dynamic-Import: * This will cause the XStream bundle to import the entire world on demand - it could work but is a bad idea - all kinds of classes clashing inside the XStream class space :) Instead you tell XStream to use your bundle's ClassLoader to resolve String names to Class objects living inside your bundle. They don't need to even be exported because XStream uses reflection and only needs a Class object. This approach will work safely if all deserialized classes are located in one bundle. If you build object graphs out of classes from many bundles I am afraid you can have problems. To resolve the issue without importing the world some fancy classload bridging has to be done. Look here if you fancy the gory details: http://rinswind.blogspot.com/2009/08/classload-acrobatics-dynamic-code.html As I said I am not familiar with XStream - I am familiar with the problem as I understand it. So forgive me if I am completely out of line :) Cheers, Todor Thanks Todor and Charles for your highly appreciated suggestions. I think that Todor spotted the technical issue with quite a remarkable conciseness, and you're not out of line. 'Captatio benevolentiae' apart ;) I of course am in the case of scattered among several bundle classes, so either I refactor the contents of my bundles or I have to do some Classload acrobatics. Another guy claimed he solved this issue [1], but I won't believe until I see it running. Thanks again for your support. [1]: http://archive.timeindexing.codehaus.org/lists/org.codehaus.xstream.user/msg/19183331.p...@talk.nabble.com -- Guido Spadotto - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Guido Spadotto wrote Thanks Todor and Charles for your highly appreciated suggestions. I think that Todor spotted the technical issue with quite a remarkable conciseness, and you're not out of line. 'Captatio benevolentiae' apart ;) I of course am in the case of scattered among several bundle classes, so either I refactor the contents of my bundles or I have to do some Classload acrobatics. Another guy claimed he solved this issue [1], but I won't believe until I see it running. If your objects are scattered among several bundles you might want to give the Apache Sling dynamic classloader a try: http://svn.apache.org/repos/asf/sling/trunk/bundles/commons/classloader/ It provides the DynamicClassLoaderManager services which gives you a classloader that is able to load all publically available classes from all bundles, and the private classes from the bundle getting the classloader from the service. Using this classloader we fixed in Sling all these classloader problems for unmarshalling something with avoid the dynamic import *. Regards Carsten -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Carsten Ziegeler said the following on 08/17/2009 04:33 PM: ... http://svn.apache.org/repos/asf/sling/trunk/bundles/commons/classloader/ It provides the DynamicClassLoaderManager services which gives you a classloader that is able to load all publically available classes from all bundles, and the private classes from the bundle getting the classloader from the service. Using this classloader we fixed in Sling all these classloader problems for unmarshalling something with avoid the dynamic import *. Interesting, but I would like to now more about advantages/disadvantages compared with danymic import *. I know a bundle should ideally explicitly declare the packages it needs, but if this isn't possible with dynamic import * the environment knows about this peculiarity of the bundle. Cheers, reto -- Reto Bachmann-Gmür trialox.org Tel: +41445005015 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Carsten Ziegeler wrote:
If your objects are scattered among several bundles you might want to
give the Apache Sling dynamic classloader a try:
http://svn.apache.org/repos/asf/sling/trunk/bundles/commons/classloader/
It provides the DynamicClassLoaderManager services which gives you a
classloader that is able to load all publically available classes from
all bundles, and the private classes from the bundle getting the
classloader from the service.
Using this classloader we fixed in Sling all these classloader problems
for unmarshalling something with avoid the dynamic import *.
Thanks Carsten,
I'm now injecting the DynamicClassLoader using SCR in my code:
/**
* The Sling Dynamic ClassLoader manager.
* It is mandatory, so no need for null reference checking.
* @scr.reference cardinality=1..1 bind=setDynCl
*unbind=unsetDynCl
*/
protected DynamicClassLoaderManager dynClService = null;
protected synchronized void unsetDynCl(DynamicClassLoaderManager
dynCl) {
this.dynClService = null;
}
protected synchronized void setDynCl(DynamicClassLoaderManager dynCl) {
this.dynClService = dynCl;
if (this.xstream!=null){
this.xstream.setClassLoader(dynCl.getDynamicClassLoader());
}
}
But - sorry for the naive question - is this enough to make the dynCL
see all my
bundle classes, or do I have to instruct the CL which bundles it has to
harvest?
I'm asking this because I see that in the /impl/DynCLFactory class
there's this method:
/**
* Notify that a bundle is used as a source for class loading.
* @param bundle The bundle.
*/
public void addUsedBundle(final Bundle bundle) {
final long id = bundle.getBundleId();
this.usedBundles.add(id);
}
But I don't know how and if I am supposed to invoke it.
--
Guido Spadotto
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Guido Spadotto wrote:
Thanks Carsten,
I'm now injecting the DynamicClassLoader using SCR in my code:
/**
* The Sling Dynamic ClassLoader manager.
* It is mandatory, so no need for null reference checking.
* @scr.reference cardinality=1..1 bind=setDynCl
*unbind=unsetDynCl
*/
protected DynamicClassLoaderManager dynClService = null;
protected synchronized void unsetDynCl(DynamicClassLoaderManager
dynCl) {
this.dynClService = null;
}
protected synchronized void setDynCl(DynamicClassLoaderManager dynCl) {
this.dynClService = dynCl; if (this.xstream!=null){
this.xstream.setClassLoader(dynCl.getDynamicClassLoader());
}
}
But - sorry for the naive question - is this enough to make the dynCL
see all my
bundle classes, or do I have to instruct the CL which bundles it has to
harvest?
That's all you have to do - of course the classes in question need to be
exported by the bundles.
I'm asking this because I see that in the /impl/DynCLFactory class
there's this method:
/**
* Notify that a bundle is used as a source for class loading.
* @param bundle The bundle.
*/
public void addUsedBundle(final Bundle bundle) {
final long id = bundle.getBundleId();
this.usedBundles.add(id);
}
But I don't know how and if I am supposed to invoke it.
No, that's an internal method which is used for caching the found
classes - it keeps track where the classes come from and if such a
bundle is updated.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
Guido Spadotto wrote: Another guy claimed he solved this issue [1], but I won't believe until I see it running. ... [1]: http://archive.timeindexing.codehaus.org/lists/org.codehaus.xstream.user/msg/19183331.p...@talk.nabble.com On second though I think this wrapper function should work even if you assemble object graphs from classes exported by many bundles. As soon as you give XStream a Class object to start from it does not need any special class loading magic. It only needs the (always available) reflection API to traverse bundle class spaces. It can touch private classes and create empty instances too - as long as it uses reflection to do so. Often even that wrapper function is too complicated. The class you deserialize is likely imported in the local bundle because you usually do an explicit cast: Person newJoe = (Person) xstream.fromXML(xml); So in most normal usecases the solution I proposed first should work - pass in the local ClassLoader. Or to be safer use the wrapper - it will force you to provide a Class object which in most cases will be a type literal: Person newJoe = (Person) xstream.readClass(xml, Person.class); //Bit Redundant On the other hand if you want to have a bundle that deserializes types it never sees (e.g. it treats the results as Object) and do not want to worry about providing a Class object the dynamic bridge will work better. The bridge becomes risky when there are multiple versions of the same package within the OSGi container. This is because it uses the PackageAdmin service to map String names to exporter bundles. In a multi version situation however PackageAdmin.getExportedPackage() will always return the highest version of the package. But what if you pass the deserialized object to code that was compiled against a lower incompatible version? Bridges are cool but risky: They create a class space that resembles the good old java class path with it's first-see first-pick policy. As we know such a class space does not tolerate multiple versions of the same thing :P Cheers, Todor - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
On Mon, Aug 17, 2009 at 10:57 PM, Guido Spadottogspado...@soluta.net wrote: Question 1: Were any of you able to use XStream within an OSGi container successfully? We have used xstream in an osgi app. To make it work we: - added the relevant jars to the bundle that was using xstream (we only had the one bundle that used xstream, so we didn't consider this an issue) - modified the bundle classpath to include those jars (ie. Bundle-ClassPath: .,lib/xpp3_min-1.1.4c.jar,lib/xstream-1.3.1.jar) - added javax.xml.datatype javax.security.auth to system exported package list (org.osgi.framework.system.packages.extra=javax.xml.datatype,javax.security.auth) - imported javax.xml.datatype javax.security.auth in the bundle that used xstream Not really a great solution but it worked for us. As in all such cases though if we had more time we'd try to find a library that just worked with OSGi. Cheers..Steve - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: XStream and OSGi
I am also using XStream successfully in OSGi. The problem is the
classic deserialization issue.
Since there is not yet any standardized solution to this (what seems
to me to be a) common problem, I just made my own temporary solution.
For any bundle that needs to provide class information (especially
when private), I register it as a service provider with my
serialization helper. Any bundle that consumes a service of this type
of provider can thus gain access even to private classes. A bundle
that does both can fulfill both roles.
So, for example, if in my UI I need to consume a service that uses
another service that contains the classes that need to be deserialized:
UiBundle
(registers itself as consumer of Service A)
ServiceA [uses ServiceB]
(registers itself as provider of Service A)
(registers itself as consumer of Service B)
Service B [contains classes that are serialized]
(registers itself as provider of Service B
An example of actual code looks something like this:
private BundleClassLoaderRegistrar registrar;
private void registerBundleClassLoader()
{
registrar = new
BundleClassLoaderRegistrar( context.getBundle() );
registrar.addConsumedService( MailProvider.class );
registrar.addConsumedService( UserProvider.class );
registrar.addProvidedService( NotificationProvider.class );
registrar.register();
}
The BundleClassLoader service is just something like this:
public interface BundleClassLoader
{
long getBundleId();
Bundle getBundle();
CollectionString getProvidedServices();
/**
* This may or may not be the same as the bundle's classloader.
* It could be overridden by a delegating class loader.
*/
ClassLoader getClassLoader();
}
When you register these classes to your serialization helper service,
you manage your own classloader as you can now gain access to all the
classes you need.
hth
=David
On Aug 18, 2009, at 8:14 AM, Steve Lindsay wrote:
On Mon, Aug 17, 2009 at 10:57 PM, Guido
Spadottogspado...@soluta.net wrote:
Question 1: Were any of you able to use XStream within an OSGi
container
successfully?
We have used xstream in an osgi app.
To make it work we:
- added the relevant jars to the bundle that was using xstream (we
only had the one bundle that used xstream, so we didn't consider this
an issue)
- modified the bundle classpath to include those jars (ie.
Bundle-ClassPath: .,lib/xpp3_min-1.1.4c.jar,lib/xstream-1.3.1.jar)
- added javax.xml.datatype javax.security.auth to system exported
package list
(org
.osgi
.framework
.system.packages.extra=javax.xml.datatype,javax.security.auth)
- imported javax.xml.datatype javax.security.auth in the bundle that
used xstream
Not really a great solution but it worked for us. As in all such cases
though if we had more time we'd try to find a library that just
worked with OSGi.
Cheers..Steve
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
