| Fragment fails to resolve if listed after host - Virgo Tools on Linux [message #1053549] |
Mon, 06 May 2013 09:24  |
Eclipse User |
|
|
|
Hello,
I am experiencing a strange issue with fragments. Originally I thought it was due to my complex application, but eventually I was able to reproduce the problem with the simplest possible use case: an application made of a single bundle and a single fragment.
I am using Eclipse 4.2.2, Virgo Tools 1.0.1, Virgo Server for Apache Tomcat 3.6.1, Oracle Java 7 (1.7.0_21-b11) on Ubuntu Linux (Both 12.04 and 13.04).
I created two empty bundle projects using virgo tools. One is a bundle (SampleBundle), the other is a fragment (SampleFragment).
The two projects are empty, they only contain the default project structure, files and MANIFEST.MF generated by the Virgo Tools wizard. I only changed the SampleFragment MANIFEST.MF to add the Fragment-Host header.
I then created a server instance using Virgo Tools and added the two bundles to the server. If the fragment is listed before the host, both bundles resolve successfully, but if the fragment is listed after the host, an exception is raised by the quasi resolver, but no reason is given, and a dump is generated.
Started bundle 'SampleHost' version '1.0.0'.
[2013-05-06 15:10:18.830] TCP Connection(2)-127.0.0.1 <DE0000I> Installing bundle 'SampleFragment' version '1.0.0'.
[2013-05-06 15:10:24.230] TCP Connection(2)-127.0.0.1 <ME0003I> Dump 'serviceability/dump/2013-05-06-15-10-946' generated
[2013-05-06 15:10:24.238] TCP Connection(2)-127.0.0.1 <DE0002E> Installation of bundle 'SampleFragment' version '1.0.0' failed. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'SampleFragment' at version '1.0.0': Cannot resolve: SampleFragment
at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:46)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessGraph(CompensatingPipeline.java:73)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(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:359)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:185)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:140)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:253)
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:662)
Interesting enough, despite the error, if I log into the OSGi user region console the fragment appears as resolved:
osgi> ss Sample
"Framework is launched."
id State Bundle
151 ACTIVE SampleHost_1.0.0
Fragments=152
152 RESOLVED SampleFragment_1.0.0
Master=151
So the problem is not blocking, but quite annoying because it slows down the server boot and creates a useless dump and a scary stack trace. Even more interesting, if the projects are built and deployed as binaries in Virgo using a plan, the error does not appear, regardless of the order in which they are listed in the plan.
Any suggestion? Should I file a bug?
GianMaria.
|
|
|
| Re: Fragment fails to resolve if listed after host - Virgo Tools on Linux [message #1053553 is a reply to message #1053549] |
Mon, 06 May 2013 09:36  |
| Eclipse User |
|
|
|
I debugged a bit into the resolver code, in class org.eclipse.virgo.kernel.userregion.internal.quasi.DependencyCalculator
The different behaviour is in statement "StateDelta delta = state.resolve(bundles);"
- If the fragment is listed before the host, the statebits of the BundleDescription are set to 0x201.
- If the fragment is listed after the host the statebits are set to 0x200.
public BundleDescription[] calculateDependencies(State state, Region coregion, BundleDescription[] bundles,
BundleDescription[] disabledProvisioningBundles) throws BundleException, UnableToSatisfyDependenciesException {
this.logger.info("Calculating missing dependencies of bundle(s) '{}'", bundles);
synchronized (this.monitor) {
this.coregion = coregion;
try {
doSatisfyConstraints(bundles, state, disabledProvisioningBundles);
StateDelta delta = state.resolve(bundles);
for (BundleDescription description : bundles) {
|
|
|
Powered by
FUDForum. Page generated in 0.24261 seconds
Home