Community
Participate
Working Groups
If I have a plan which includes a bundle (org.eclipse.gemini.jpa-1.0.0.M4-incubator), and that bundle needs a package org.eclipse.gemini.jpa.weaving, I'd expect that Virgo could satisfy that demand by installing a bundle out of the region/usr automatically. If the package dependency is provided by a system bundle fragment, this does not appear to happen. I have installed the weaving bundle into repository/usr (and bounced Virgo a couple of times, so it's not a cache issue). The weaving bundle's manifest looks like: Bundle-Name: Gemini JPA Dynamic Weaving Fragment (Incubation) Bundle-SymbolicName: org.eclipse.gemini.jpa.weaving Bundle-Version: 1.0.0.M4-incubation Export-Package: org.eclipse.gemini.jpa.weaving,org.eclipse.gemini.jpa. weaving.equinox Fragment-Host: system.bundle;extension:=framework Because it's not a bundle, this isn't getting picked up. If I put it in the plan, then a virgo redploy will wipe out system.bundle as it tries to uninstall the host fragment. And because the dependency is mandatory, this means org.eclipse.gemini.jpa is effectively uninstallable in Virgo through a plan or making available via the repository/usr. If I drop the weaving bundle into 'pickup' the fragment gets installed osgi> packages org.eclipse.gemini.jpa.weaving org.eclipse.gemini.jpa.weaving; version="0.0.0"<org.eclipse.osgi_3.7.0.v20110124 -0830 [0]> However, the (kernel region) plan still fails to be executed: URI 'file://the.plan'. Cannot satisfy constraints for bundle 'org.eclipse.gemini.jpa' version '1.0.0.M4-incubation'. Cannot resolve: org.eclipse.gemini.jpa Resolver report: An Import-Package could not be resolved. Caused by missing constraint in bundle <org.eclipse.gemini.jpa_1.0.0.M4-incubation> constraint: <Import-Package: org.eclipse.gemini.jpa.weaving; version="0.0.0"> So, even though the package is available (and via the system fragment) the import-package doesn't get resolved. This effectively prevents Gemini JPA from being usable in Virgo.
(Note; after deleting the fragment from the fs, Virgo executed the 'uninstall' which promptly shut the system down. I know there is another bug on this but filing this one as there is a Gemini JPA/Virgo combined issue here which those searching for bugs may want to find.)
Note that I edited the JAR locally to add the 'resolution:=optional' and avoid the weaving - but I have yet to test whether this will be a workable solution.
The Gemini weaving bundle is also a framework extension. As such it needs to be located in the same folder as the framework JAR org.eclipse.osgi. Although I managed to have my setup running by adding weaving bundle to the kernel region I guess it works by chance.
As for the part where weaving is fragment on system bundle - deployment of such artifacts is not allowed. I was surprised that you managed to do it and after looking deeper i found a little bug there. So in future that deployment won't be possible. Here is an excerpt of Virgo's user guide "Typically, fragment bundles should be placed in $SERVER_HOME/repository/ext or $SERVER_HOME/repository/usr so that they will be installed automatically with their host bundles.". But that contradicts with Hristo's observation about the framework extensions and where they should be placed(in the same location as the framework bundle). We'll have to dive deeper here. From my perspective that bundle should be only a fragment, without the extension definition, i can't see the use case and benefits behind it...
The weaving bundle is installed and started when present in pickup directory in M04.
This bug has an assignee, so changing status to ASSIGNED.
As stated above the deployment of this jar won't be allowed in future milestones as it will endanger the stability of the system. For example uninstalling this artifact, refreshing it, referencing it in a plan(causes refresh later) will crash the system because this leads to refresh of the system bundle. This is a common inconvenience of OSGi frameworks. That is why usage of fragments should be avoided. But still many use that approach, so if you want to use such bundles your only option is to configure Virgo and include them in the kernel.launch.properties and copy the fragment bundles in lib/kernel. Then you have to import the fragment bundle in the userregion.properties file located in the config dir in order to obtain its exported packages. This way the fragments will run fine without endangering the server. I'll submit this shortly in Virgo's documentation.
Virgo documentation updated. Section 11.7 in the User-Guide that will be released in the next milestone covers configuring framework extensions and fragments on the system bundle. Deployment of such bundles won't be allowed from the next milestone as it endangers the stability of the server. Closing this bug as fixed since general solution and guideline for such bundles is provided.
I was wondering if the provided text for bundle fragments listed as solution below is still valid. I am trying to add a system.bundle fragment to the virgo-jetty-server 3.6.3.RELEASE, and it strikes me that there are no lib/kernel and launcher configuration files. I've been performing different tests to see if I could find a workaround, but as yet without much success. It seems to me that this issue may have to be reopened.
