| 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
|
|
|
| Re: Problems with singleton bundles [message #647870 is a reply to message #647660] |
Mon, 10 January 2011 04:10  |
Glyn Normington
Messages: 1186
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 04:11] Report message to a moderator |
|
|
|
|
| Re: Problems with singleton bundles [message #648687 is a reply to message #647660] |
Thu, 13 January 2011 22:06 |
Miles Parker
Messages: 1266
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: Thu, 13 January 2011 22:19] Report message to a moderator |
|
|
|
Powered by
FUDForum. Page generated in 0.01887 seconds
] 
Search
Help
Register
Login
Home
