Eclipse Community Forums: Virgo » Problems with singleton bundles

Help

Home

Home » Eclipse Projects » Virgo » Problems with singleton bundles

Show: Today's Messages :: Show Polls :: Message Navigator

Problems with singleton bundles [message #647660]

Fri, 07 January 2011 16: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

Report message to a moderator

Re: Problems with singleton bundles [message #647870 is a reply to message #647660]

Mon, 10 January 2011 09:10

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

I am not aware of anyone running singleton bundles in Virgo and the issues you point out are unfortunately what I'd expect.

I suggest you install the singleton bundle early from repository/usr using the initialArtifacts property as described in the user guide and avoid putting singleton bundles in plans.

Please note that we hope to improve the refreshing of bundles in plans in due course, e.g. by supporting plans that refer to bundles by URI so the tooling can update the bundles more easily.

[Updated on: Mon, 10 January 2011 09:11]

Report message to a moderator

Re: Problems with singleton bundles [message #647888 is a reply to message #647870]

Mon, 10 January 2011 10:37

Martin Schmied

Messages: 7
Registered: July 2009

Junior Member

Thanks for pointing me to the initialArtifacts configuration property, Glyn. I'll try to work around these problems with singletons.

It sure would be great if you found a way to make Virgo work with singleton bundles as it's by far the most advanced OSGi server environment under Eclipse and it seems only natural to use bundles from other Eclipse projects in combination with Virgo. Unfortunately all the eclipse bundles declaring extensions or extension points (the "Eclipse way" to achieve modularity) are required to be singletons Sad

Report message to a moderator

Re: Problems with singleton bundles [message #647889 is a reply to message #647888]

Mon, 10 January 2011 10:54

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

You're welcome. Please feel free to raise an enhancement bug to capture the use case and/or requirement for singleton bundles in Virgo plus any thoughts you might have on the solution you'd like to see.

Report message to a moderator

Re: Problems with singleton bundles [message #648687 is a reply to message #647660]

Fri, 14 January 2011 03:06

Miles Parker

Messages: 1341
Registered: July 2009

Senior Member

I'm running into this issue as well. As Martin notes, many of the things that make the Eclipse environment useful are only available as singletons. This is especially important for RAP applications. Thanks for the tip re: initialArtifacts, that will make things a bit easier than simply playing with artifact reordering.

Could you say a bit more about "suggest you install the singleton bundle early from repository/usr using the initialArtifacts property as described in the user guide and avoid putting singleton bundles in plans."? I'm not sure from the documentation how we specify individual bundles here.

cheers,

Miles

[Updated on: Fri, 14 January 2011 03:19]

Report message to a moderator