Community
Participate
Working Groups
Especially during tests, it is often problematic if (already active) persistence bundles are restarted because of a refresh. The refresh is triggered by the Gemini JPA Extender to ensure byte code weaving of the persistence classes. Gemini JPA already requires OSGi 4.3 (weaving hooks), so one could as well make use of the Generic Capabilities/Requirements feature introduced in 4.3. By introducing a Generic Capability we could avoid the restart: Provide-Capability: osgi.jpa.weaving Persistence bundles could simply express their dependency: Require-Capability: osgi.jpa.weaving Introducing the Provide-Capability would not break existing applications. Using a capability in the name space osgi.* might presumably require the agreement of the OSGi Alliance first. What do think? - Juergen
Yep, definitely. This was one of the reasons why I pushed for generic capabilities to begin with :-) Will provide a org.eclipse.gemini.jpa capability that bundles can require.
Generic capability affect the resolver, so it would ensure that before a bundle to be weaved is resolved, the weaver will be resolved. But is this sufficient? Will resolving the Gemini bundle immediately hook it into the Equinox weaving extension, before any dependent bundle is resolved?
Right. It won't guarantee that no refreshes happen at all, since there is still an activation race, but it will hopefully reduce the number that does get refreshed. Either way, I have always wanted this capability to be there since there really is a dependency that was not able to be expressed before capabilities came along.
Doesn't a Require-Bundle dependency guarantee that the required bundle is started before the bundle defining the Require-Bundle dependency? It's ugly to define a Require-Bundle for org.eclipse.gemini.jpa but might be a suitable workaround for test bundles.
(In reply to comment #4) > Doesn't a Require-Bundle dependency guarantee that the required bundle is > started before the bundle defining the Require-Bundle dependency? Not as far as I know - but this was one of my misconceptions as well. I was surprised to see how little coupling there is between the lifecycle and modules concepts. A bundle doesn't even have to be started before classes are loaded from it.
Correct. The import/export/capability constraints are for the resolver but play no role in lifecycle event ordering. I know, it's kind of annoying...
Provide-Capability added. Used "osgi.extender" namespace suggested by OSGi Alliance for OSGi standard services, with osgi.extender="osgi.jpa" attribute.
