|
| Re: Install bundles located in the provisioning repositories programmatically [message #696525 is a reply to message #696272] |
Thu, 14 July 2011 08:03   |
 Glyn Normington
Messages: 1222
Registered: July 2009 |
Senior Member |
|
|
You can use a URL of the form "repository://type/name[/version]" to refer to an artifact in the provisioning repository. The square brackets indicate that the trailing "/version" is optional, in which case Virgo uses the highest version available, and are not part of the URL. In the case of a bundle, "type" is "bundle" and "name" is the bundle symbolic name (and if "version" is specified, it is the bundle version).
Please note that these installs will be done directly into the OSGi framework and will not benefit from any Virgo deployer support and that, in Virgo 3.0, bundles installed in this way will be installed in the same region as the BundleContext used to do the install.
Hope that helps!
[Updated on: Thu, 14 July 2011 08:05] Report message to a moderator |
|
|
| Re: Install bundles located in the provisioning repositories programmatically [message #696548 is a reply to message #696525] |
Thu, 14 July 2011 09:10 |
Marco Gerber
Messages: 10
Registered: May 2011 |
Junior Member |
|
|
Hi Glyn
Very cool, thanks!
Quote:
You can use a URL of the form "repository://type/name[/version]" to refer to an artifact in the provisioning repository
My problem with this approach is, that I don't have the symbolic names, but a pattern for all the bundles I'm interested in. Is there a way to get a list of symbolic names for all not yet installed bundles matching a pattern? It's not really a blocker, as I can use a config file to get the symbolic names from as a working alternative but the first would be the most beautiful way to go when using this approach 
Quote:
... in Virgo 3.0, bundles installed in this way will be installed in the same region as the BundleContext used to do the install.
This should be ok, as we manage such bundles from within a bundle installed and managed by virgo.
Quote:
Please note that these installs will be done directly into the OSGi framework and will not benefit from any Virgo deployer support...
Such as managing such bundles by a plan, right? However, the whole start/stop handling by using f.ex. the virgo web console still seems to be working. Or is there a way to let virgo install a bundle by using a virgo api in a way I don't have such limitations?
Thanks,
Marco
[Updated on: Thu, 14 July 2011 09:21] Report message to a moderator |
|
|
|
|
|
|
| Re: Install bundles located in the provisioning repositories programmatically [message #696642 is a reply to message #696598] |
Thu, 14 July 2011 13:25 |
Marco Gerber
Messages: 10
Registered: May 2011 |
Junior Member |
|
|
So, as a first try, I use the jconsole script provided with virgo 3.0.0.M05 to access the Deployer MXBean. Using install(p0) with:
repository:bundle/my.bundle.symbolic.name/0.0.1.BUILD-SNAPSHOT
the bundle passes over into state RESOLVED as expected. However, using start (p0) afterwards fails as it's deselected, and trying to use start(p0, p1, p2) with:
p0: bundle
p1: my.bundle.symbolic.name
p2: 0.0.1.BUILD-SNAPSHOT
fails with the following error:
Problem invoking start : java.lang.RuntimeException:java.lang.UnsupportedOperationException: Not yet implemented, use deploy instead of install and start.
Following the error message and using deploy(p0) with p0 set as follows instead of using install and start:
repository:bundle/my.bundle.symbolic.name/0.0.1.BUILD-SNAPSHOT
deploys the bundle where the resulting state is ACTIVE.
Same thing with stop/uninstall and undeploy.
The bad thing here is that I always have to use 'deploy' and 'undeploy' where I never reach RESOLVED -> ACTIVE in two single steps.
What's the reason for such limitations? It would be nice if I could manage the entire lifecycle over the deployer mxbean instead of getting and resolving the Bundle to do so; which, btw is a solution I can live with
Cheers,
Marco
|
|
|
|
| Re: Install bundles located in the provisioning repositories programmatically [message #1694200 is a reply to message #696525] |
Sat, 02 May 2015 00:52 |
Ellen Strnod
Messages: 17
Registered: October 2010 |
Junior Member |
|
|
Glyn Normington wrote on Thu, 14 July 2011 01:03You can use a URL of the form "repository://type/name[/version]" to refer to an artifact in the provisioning repository. The square brackets indicate that the trailing "/version" is optional, in which case Virgo uses the highest version available, and are not part of the URL. In the case of a bundle, "type" is "bundle" and "name" is the bundle symbolic name (and if "version" is specified, it is the bundle version).
Please note that these installs will be done directly into the OSGi framework and will not benefit from any Virgo deployer support and that, in Virgo 3.0, bundles installed in this way will be installed in the same region as the BundleContext used to do the install.
Hope that helps!
I have some bundles in the repository/usr directory which I would like to start conditionally. I have removed their plan files from pickup, but when I use the URL format described above with BundleContext.installBundle(), or with FrameworkMBean.installBundle(), I get an error that it is an invalid URL. Would this then be an example of correct usage (where the symbolic name for the bundle I wish to install and start is com.delphidisplay.insight.ocs-http) : "repository://bundle/com.delphidisplay.insight.ocs-http"?
Bundle-SymbolicName: com.delphidisplay.insight.ocs-http
2015-05-04 13:22:16.099 -0700|startup|ERROR|c.d.healthmonitor.BundleManager.installAndStart:111|Error installing, resolving, or starting bundle com.delphidisplay.insight.ocs-http: java.io.IOException: Unable to install bundle: org.osgi.framework.BundleException: "repository://bundle/com.delphidisplay.insight.ocs-http" is an invalid URL java.io.IOException: Unable to install bundle: org.osgi.framework.BundleException: "repository://bundle/com.delphidisplay.insight.ocs-http" is an invalid URL
at org.eclipse.gemini.management.framework.Framework.installBundle(Framework.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
...
My bundle is a war bundle.
BTW, I am using Virgo with kernel version # 3.6.2.RELEASE.
I have tried with the repository/usr directory as both a watched directory and as another external directory (which does not seem to matter in this case.) The org.eclipse.virgo.repository.management.ExternalStorageRepositoryInfo MBean attribute "AllArtifactDescriptorSummaries" includes the bundle I am trying to install, but the installBundle methods (and variations on URLs) seems unable to find it, and I cannot find documentation on programmatic installation (or deployment) of bundles already in the usr directory beyond what was discussed above. I have reviewed virgo & gemini source on github as well with no luck. Any direction on this from committers or others who have had success with this topic would be greatly appreciated!
UPDATE: For anyone out there attempting the same, I was not able to determine why my repository URL did not work with BundleContext.installBundle() or FrameworkMBean.installBundle(), but by including the necessary dependencies (and maven exclusions for artifacts in the "org.eclipse.virgo.mirrored" groupId since it is not in a public maven repository that I could find) into my build to use the org.eclipse.virgo.nano.deployer.api.Deployer MBean (unproxied) and use the signature as in the example by Marco Gerber on this thread (no "//" after repository, and include bundle version at end of URL), I was able to get the bundle started using Deployer.deploy("repository:bundle/com.delphidisplay.insight.ocs-http/2.1.0"). (I went with unproxied MBean because with the proxy, it was starting the bundle but then throwing a class cast exception for the return value , trying to cast javax.management.openmbean.CompositeDataSupport to org.eclipse.virgo.nano.deployer.api.core.DeploymentIdentity)
Thanks,
Ellen
[Updated on: Tue, 05 May 2015 19:38] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03883 seconds
] 
Search
Help
Register
Login
Home
