| Re: [virgo-dev] Sad tale of JavaAPIforKML... |
Just to follow up on my old discussions, we were able to get past this issue. The JAK code worked best when we were using version "0" of the required packages. We went down the path of forcing the Apache commons versions of the packages but ran into uses violations, conflicting with org.springframework.oxm. Using the oxm bundle as an example, we were able to get JAK working as expected by changing our JAK bundle to better match the oxm bundle, via looking at the template.mf in the source code for oxm. (The various Spring projects are really good references.)
If the web module has a package import which matches an export of JAK, then when the web module is deployed and JAK is in repository/usr, then JAK should be brought in by Virgo's dependency satisfaction logic.
Please could you clarify the dependency of the web module on JAK?
Regards,
Glyn
On 24 Nov 2010, at 18:25, Tim Goeke wrote:
It seems that when JAK and our web module are both deployed via the admin console or the pickup folder things work fine, but when JAK is in the usr repo the web module can't resolve it's deps.
On Wed, Nov 24, 2010 at 12:20 PM, Dmitry Sklyut <dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx>> wrote:
Tim,
Have you tried dropping the jak bundle into pickup? Putting it into repository/usr WILL NOT deploy the bundle.
Deploying through web console, pickup will trigger deployment.
Deployment of bundles in /usr will be triggered if there is a plan that references that bundle or some other bundle has an import that is satisfied by bundle in the /usr.
Hope this helps.
Regards,
Dmitry
On Wed, Nov 24, 2010 at 12:19 PM, Tim Goeke <tim.goeke@xxxxxxxxx<mailto:tim.goeke@xxxxxxxxx>> wrote:
I'm out for Thanksgiving Holiday, but one of my colleges back at the office is testing today with the following results:
"OK, I have it loaded on [the R&D server], however there is no kml. It comes back empty, so I'll be looking at that. Here's what I had to do:
After changing template.mf, I loaded JAK through the console. Then I removed JAK from the console and added the jar to /usr. Then I tried to load dashboard.web, but it couldn't find JAK. I removed JAK jar from /usr, restarted Virgo, reloaded JAK through the console and loaded dashboard.web. This worked!!!
One other thing that I did to template.mf in dashboard.web. I had to remove the version range on JAK, otherwise Virgo couldn't find the dependency.
...
Sometimes when you restart Virgo it gets lost and doesn't load all of the bundles that you expect. I had to restart and everything locked up, so I found c:\vrt\work\org.eclipse.virgo.region.user_0.0.0\upload and deleted all of my bundles. Then I restarted again and it came up without my bundles showing in the console. Then I uploaded my bundles again."
On Tue, Nov 23, 2010 at 10:17 PM, Glyn Normington <gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>> wrote:
Thanks for feeding back and I hope the testing confirms this is a good fix.
Glyn
On Nov 23, 2010, at 10:28 PM, Tim Goeke wrote:
Thanks everyone, I believe it's working now. For the solution, I simplified the template.mf by removing the versions and that did the trick right away.
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!
Tim
On Tue, Nov 23, 2010 at 1:20 AM, Glyn Normington <gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx><mailto:gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>>> wrote:
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><mailto:dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx>><mailto:dmitry@xxxxxxxxxxx<mailto:dmitry@xxxxxxxxxxx><mailto: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><mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>><mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto: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><mailto:tim.goeke@xxxxxxxxx<mailto:tim.goeke@xxxxxxxxx>><mailto:tim.goeke@xxxxxxxxx<mailto:tim.goeke@xxxxxxxxx><mailto: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
https://dev.eclipse.org/mailman/listinfo/virgo-dev
<ATT00001..txt>
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx><mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/virgo-dev
<ATT00001..txt>
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev
<ATT00001..txt>
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev