| Re: [virgo-dev] Sad tale of JavaAPIforKML... |
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: JavaAPIforKml-osgi
Bundle-SymbolicName: JavaAPIforKml-osgi
Bundle-Vendor: Micromata GmbH
Bundle-Version: 2.2.0
Excluded-Exports:
de.micromata.jak*,
exampledata,
schema*
Excluded-Imports:
junit.framework,
org.apache.log4j,
org.junit
I created a test bundle that runs the example1 test from JAK and it seems to have worked. So far so good. We have some more testing to do, but thanks for the assistance!
Hi Tim
I hope Dmitry's suggestions have helped, but let me also unpack this further just in case.
It seems that the Virgo Java 6 profile is offering both boot delegation of javax.xml.* packages and a system bundle export of 5 specific javax.xml packages at version 0 (the default). So you have the following options if you want to load javax.xml.transform classes from the framework class loader:
1. Delete the import of javax.xml.transform from your bundle. The classes will be loaded by boot delegation.
2. Delete the version range on the import of javax.xml.transform from your bundle. Your bundle will then be wired to the system bundle for javax.xml.transform, but I *think* class loads will still be boot delegated (which should be harmless) unless you also delete javax.xml.* from the boot delegation property.
3. Keep the version range on the import of javax.xml.transform in your bundle and add an export of javax.xml.transform at e.g. version 1.3.3 to the system packages property. Your bundle will then be wired to the system bundle for javax.xml.transform, but I *think* class loads will still be boot delegated (which should be harmless) unless you also delete javax.xml.* from the boot delegation property.
Also please note that if you use bundlor to calculate the manifest of your bundle, it can take the OSGi profile into account in its calculations and avoid generating imports for boot delegated packages (although I'm not absolutely certain what it does when there is an overlap between boot delegated packages and system packages as is the case here, but *if* there's a bug we can fix it). See [1].
Regards,
Glyn
[1] http://static.springsource.org/s2-bundlor/1.0.x/user-guide/htmlsingle/user-guide.html#osgi.profile
On Nov 23, 2010, at 2:14 AM, Dmitry Sklyut wrote:
Tim,
There is some more to this :) I missed it initially.
There is this:
org.osgi.framework.bootdelegation = \
org.eclipse.virgo.osgi.extensions.*,\
org.eclipse.virgo.osgi.launcher.*,\
org.eclipse.virgo.kernel.authentication,\
com.sun.*,\
javax.xml.*,\
org.apache.xerces.jaxp.*,\
org.w3c.*,\
org.xml.*,\
sun.*
So any javax.xml.* packages will be delegated for resolution to vm boot classloader.
I think this is a best explanation of bootdelegation and system.packages that I have seen so far: http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/
Maybe in your environment it makes sense to customize those values and see if Virgo still comes up.
For example you might try to take out javax.xml.* from list of org.osgi.framework.bootdelegation packages and just rely on org.osgi.framework.system.packages. I can't compute the impact that it might have. But I think you have choices here.
You can try dropping all of the xml libraries that you need into $VIRGO_HOME/lib and those jars will be on the server classpath (look in bin/setupClasspath.sh/bat) and will be available for resolution with bootdelegation. No changes needed to the java6-server.profile.
Regards,
Dmitry
On Mon, Nov 22, 2010 at 7:41 PM, Dmitry Sklyut <dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx>> wrote:
Tim,
Following packages are exported by means of org.osgi.framework.system.packages (look in lib/java6-server.profile). Remove version range or set it to version="0" and you should be in business.
javax.xml.transform,\
javax.xml.transform.dom,\
javax.xml.transform.sax,\
javax.xml.transform.stax,\
javax.xml.transform.stream,
Regards,
Dmitry
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>On Mon, Nov 22, 2010 at 4:58 PM, Tim Goeke <tim.goeke@xxxxxxxxx<mailto:tim.goeke@xxxxxxxxx>> wrote:
We are trying to bundlize JavaAPIforKML so that it is deployable on Virgo.
Despite all our efforts, we are getting the following when we deploy to Virgo. The issue seems to be that JAK relies on JAXB. We changed the pom to reference the Spring bundles and added the Spring maven repos to the project, and added the dep jar download so we could see all the required jars. The result is that we have spent quite a bit of time on this issue and the bundle won't deploy. The only conclusion is that the bundles we have in the user repo claim to export javax.xml.transform but something has gone wrong. In days past, we have just punted and put the jars in the bundle, but we are trying to do this as cleanly as possible.
[2010-11-22 15:49:16.745] TCP Connection(19)-127.0.0.1 <DE0000I> Installing bundle 'JavaAPIforKml-osgi' version '2.2.0'.
[2010-11-22 15:49:18.512] TCP Connection(19)-127.0.0.1 <ME0003I> Dump 'serviceability/dump/2010-11-22-15-49-838' generated
[2010-11-22 15:49:18.517] TCP Connection(19)-127.0.0.1 <DE0002E> Installation of bundle 'JavaAPIforKml-osgi' version '2.2.0' failed. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'JavaAPIforKml-osgi' at version '2.2.0': Cannot resolve: JavaAPIforKml-osgi
Resolver report:
An Import-Package could not be resolved. Caused by missing constraint in bundle <JavaAPIforKml-osgi_2.2.0>
constraint: <Import-Package: javax.xml.transform; version="[1.3.3,1.3.5)">
at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:45)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessTree(CompensatingPipeline.java:72)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:271)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:151)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:123)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:190)
at org.eclipse.virgo.kernel.deployer.management.StandardDeployer.deploy(StandardDeployer.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:167)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:96)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:33)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
[2010-11-22 15:49:18.526] TCP Connection(19)-127.0.0.1 <DE0003E> Install failed for bundle 'JavaAPIforKml-osgi' version '2.2.0'.
[2010-11-22 15:49:18.538] TCP Connection(19)-127.0.0.1 <DE0500E> Unable to install application from URI 'file:/opt/tools/java/virgo/virgo-web-server-2.1.0.RELEASE/stage/JavaAPIforKml-osgi.jar'. Cannot satisfy constraints for bundle 'JavaAPIforKml-osgi' version '2.2.0'. Cannot resolve: JavaAPIforKml-osgi
Resolver report:
An Import-Package could not be resolved. Caused by missing constraint in bundle <JavaAPIforKml-osgi_2.2.0>
constraint: <Import-Package: javax.xml.transform; version="[1.3.3,1.3.5)">
. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'JavaAPIforKml-osgi' at version '2.2.0': Cannot resolve: JavaAPIforKml-osgi
Resolver report:
An Import-Package could not be resolved. Caused by missing constraint in bundle <JavaAPIforKml-osgi_2.2.0>
constraint: <Import-Package: javax.xml.transform; version="[1.3.3,1.3.5)">
at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:45)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessTree(CompensatingPipeline.java:72)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:271)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:151)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:123)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:190)
at org.eclipse.virgo.kernel.deployer.management.StandardDeployer.deploy(StandardDeployer.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:167)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:96)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:33)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
And the relevant contents of our usr repo:
-rw-r--r-- 1 tgoeke staff 12983 Nov 17 09:55 com.springsource.org.relaxng.datatype-1.0.0.jar
-rw-r--r-- 1 tgoeke staff 13429 Nov 17 09:55 com.springsource.org.jvnet.staxex-1.0.0.jar
-rw-r--r-- 1 tgoeke staff 77249 Nov 17 09:55 com.springsource.org.iso_relax.verifier-0.0.0.20041111.jar
-rw-r--r-- 1 tgoeke staff 314490 Nov 17 09:55 com.springsource.org.dom4j-1.6.1.jar
-rw-r--r-- 1 tgoeke staff 200053 Nov 17 09:55 com.springsource.org.apache.xmlcommons-1.3.3.jar
-rw-r--r-- 1 tgoeke staff 84866 Nov 17 09:55 com.springsource.org.apache.xml.resolver-1.2.0.jar
-rw-r--r-- 1 tgoeke staff 1228007 Nov 17 09:55 com.springsource.org.apache.xerces-2.8.1.jar
-rw-r--r-- 1 tgoeke staff 91992 Nov 17 09:55 com.springsource.javax.xml.bind-2.1.7.jar
-rw-r--r-- 1 tgoeke staff 294741 Nov 17 09:55 com.springsource.com.sun.xml.fastinfoset-1.2.2.jar
-rw-r--r-- 1 tgoeke staff 994769 Nov 17 09:55 com.springsource.com.sun.xml.bind.jaxb1-2.1.7.jar
-rw-r--r-- 1 tgoeke staff 884854 Nov 17 09:55 com.springsource.com.sun.xml.bind-2.2.0.jar
-rw-r--r-- 1 tgoeke staff 3140984 Nov 17 09:55 com.springsource.com.sun.tools.xjc-2.2.0.jar
-rw-r--r-- 1 tgoeke staff 216736 Nov 17 09:55 com.springsource.com.sun.msv.datatype-0.0.0.20041122.jar
-rw-r--r--@ 1 tgoeke staff 106281 Nov 22 15:40 com.springsource.javax.xml.bind-2.2.0.jar
Anyone have suggestions about how to proceed? This is a killer issue for our project and even though this is not likely a Virgo issue, Virgo is going to take the blame.
_______________________________________________
virgo-dev mailing list
<ATT00001..txt>
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev