Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Problems with singleton bundles
Problems with singleton bundles [message #647660] Fri, 07 January 2011 16:30 Go to next message
Martin Schmied is currently offline 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
Re: Problems with singleton bundles [message #647870 is a reply to message #647660] Mon, 10 January 2011 09:10 Go to previous messageGo to next message
Glyn Normington is currently offline 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 Go to previous messageGo to next message
Martin Schmied is currently offline 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
Re: Problems with singleton bundles [message #647889 is a reply to message #647888] Mon, 10 January 2011 10:54 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: Problems with singleton bundles [message #648687 is a reply to message #647660] Fri, 14 January 2011 03:06 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1340
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

Re: Problems with singleton bundles [message #648742 is a reply to message #648687] Fri, 14 January 2011 11:33 Go to previous message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
I've raised bug 334370 to document this. Please see the bug for details.
Previous Topic:Using unjarred bundles
Next Topic:Virgo over-constraing version numbers?
Goto Forum:
  


Current Time: Sat Oct 25 00:39:29 GMT 2014

Powered by FUDForum. Page generated in 0.02152 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software