Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Sad tale of JavaAPIforKML...
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> 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> 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>> 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>>> 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

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>>> 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
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

<ATT00001..txt>

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


Back to the top