| Problems with singleton bundles [message #647660] |
Fri, 07 January 2011 11:30  |
 Martin Schmied
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
Hi all,
we're trying to use Virgo as back-end for an Eclipse RCP app. For this we need to deploy many Eclipse bundles server-side. Some of these bundles are singletons (i.e. Bundle-SymbolicName: org.example.bundle;singleton:=true) which can be deployed only once in an OSGi environment. Virgo however sometimes tries to deploy (or at least resolve) a singleton bundle that is already installed.
It seems to happen for example in cases when a singleton bundle in stage directory (or listed in a plan in pickup dir) is pulled in as a dependency of some ohter bundle prior to the attempt to deploy or resolve it (possibly because it's listed in a plan that is being installed). This results in the following error:
<DE0002E> Installation of bundle 'com.alvila.dataflyer.query' version '1.0.0.qualifier' failed. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundl eDependenciesException: Unable to satisfy dependencies of bundle 'com.alvila.dataflyer.query' at version '1.0.0.qualifier': Cannot resolve: com.alvila.dataflyer.query
Resolver report:
The bundle could not be resolved because another singleton bundle was selected. In bundle <com.alvila.dataflyer.query_1.0.0.qualifier>
at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.inte rnal.QuasiResolveStage.process(QuasiResolveStage.java:45)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardP ipeline.doProcessTree(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.internal.Compensat ingPipeline.doProcessTree(CompensatingPipeline.java:72)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipe lineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.install.pipeline.internal.StandardP ipeline.doProcessTree(StandardPipeline.java:62)
at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipe lineStage.process(AbstractPipelineStage.java:41)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApp licationDeployer.driveInstallPipeline(PipelinedApplicationDe ployer.java:271)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApp licationDeployer.doInstall(PipelinedApplicationDeployer.java :151)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApp licationDeployer.install(PipelinedApplicationDeployer.java:1 23)
at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApp licationDeployer.deploy(PipelinedApplicationDeployer.java:19 0)
at org.eclipse.virgo.kernel.deployer.management.StandardDeploye r.deploy(StandardDeployer.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenRetur n(ConvertingMethod.java:167)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIn trospector.java:96)
at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIn trospector.java:33)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntro spector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.jav a:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.jav a: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(RM IConnectionImpl.java:1427)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMI ConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOper ation.run(RMIConnectionImpl.java:1265)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOp eration(RMIConnectionImpl.java:1360)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConn ectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.ja va: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(TCPTranspo rt.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TC PTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCP Transport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
It isn't always a real problem - if it was attempt to deploy just this singleton bundle, it's already there and failure to resolve it for the second time doesn't make a difference. It is however an issue when singleton bundle resolution failed during plan installation - this ultimately prevents the plan from being correctly installed.
One possible workaround for this problem might be careful ordering of bundles, which would be only practically possible (due to big number of artifacts) if we had most of the workspace bundles in a plan (or a couple of plans) that would be deployed to the server only after the 3rdparty infrastructure deployed by a plan in pickup folder is successfully installed. My brief experimentation with plans deployed from workspace shows that it's not possible to redeploy a single bundle within a plan (even though the plan is not atomic) without redeploying the whole plan, which is not very practical for development. Please correct me if I'm wrong.
Please share any experience with singleton (Eclipse) bundles under Virgo.
Thanks,
Martin
|
|
|
] 
Search
Help
Register
Login
Home
