[rfc 243] identify a connect bundle

[bjhargrave]

Original bug ID: BZ#3133 From: @tjwatson Reported version: R8

[bjhargrave]

Comment author: @tjwatson

At the CPEG meeting today we decided it is necessary to have a way to detect if a bundle is a connect bundle. I proposed a namespace for connect could be used by the framework to generate a capability that would be implicitly added to a BundleRevision that is backed by a ConnectContent. This seems like a little much to solve the requirement.

Earlier discussions proposed to update the OSGi identity namespace "type" attribute to add a new type. This has wide spread implications to the rest of the specification that declare the behavior of the bundle based on if it is a type "osgi.bundle" or type "osgi.fragment" and a connect bundle can be either an "osgi.bundle" or "osgi.fragment". Therefore overloading the type attribute on identity is more complicated than simply adding another type value.

Instead, I propose we add a new attribute to OSGi identity namespace to declare a variant. This attribute would start out with two possible values: "osgi.default" or "osgi.connect". If no value is present it means "osgi.default". This way other variants can be defined in the future or by other specifications.

[bjhargrave]

Comment author: @tjwatson

Bug BZ#3135 has been marked as a duplicate of this bug.

[bjhargrave]

Comment author: Richard Hall <heavy@ungoverned.org>

Out of curiosity, what was the use case for this need?

[bjhargrave]

Comment author: @rotty3000

My own argument was that since there will be obvious change in behaviour w.r.t. connect bundles (classloading being the most significant) compared with real bundles deployed into the framework in the traditional fashion, anything like an extender will need to be able to identify where certain bundles have alternative behaviours. An example of this is where the classloader of a class coming from a connect bundle won't necessarily implement BundleReference as per 3.9.9 [1] of the core spec.

Another use case: management agents that want to introspect installed bundles and being able to identify which cannot be managed vs. those that can.

We need some kind of discriminator that will be consistent.

[1] https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#d0e5178

[bjhargrave]

Comment author: @rotty3000

IIRC during the CPEG call, Tom suggested a capability in a new namespace and I think we agreed this would be sufficient.

[bjhargrave]

Comment author: @rotty3000

@ Tom, is this:

Instead, I propose we add a new attribute to OSGi identity namespace to declare a variant. This attribute would start out with two possible values: "osgi.default" or "osgi.connect". If no value is present it means "osgi.default". This way other variants can be defined in the future or by other specifications.

a new proposal since the call?

[bjhargrave]

Comment author: @tjwatson

(In reply to Raymond Auge from comment BZ#5)

@ Tom, is this:

Instead, I propose we add a new attribute to OSGi identity namespace to declare a variant. This attribute would start out with two possible values: "osgi.default" or "osgi.connect". If no value is present it means "osgi.default". This way other variants can be defined in the future or by other specifications.

a new proposal since the call?

Yes, after some discussion with BJ we thought a variant attribute on the existing identity capability would sufficient and not require a completely new namespace just to identify a connect bundle.

[bjhargrave]

Comment author: Richard Hall <heavy@ungoverned.org>

Perhaps I'm missing something, but it doesn't really make sense to me that this would be a "per bundle" piece of metadata, does it? It seems more like a framework-wide piece of metadata. Either you are running in OSGi Connect or an OSGi Framework, you aren't running some bundles in one and some bundles in the other.

[bjhargrave]

Comment author: @tjwatson

(In reply to Richard Hall from comment BZ#7)

Perhaps I'm missing something, but it doesn't really make sense to me that this would be a "per bundle" piece of metadata, does it? It seems more like a framework-wide piece of metadata. Either you are running in OSGi Connect or an OSGi Framework, you aren't running some bundles in one and some bundles in the other.

With the Connect RFC a Framework can be launched with a ConnectFramework which allows support for connect bundles to be installed. But non-connect bundles can still be installed also where the access to the content of the bundle is managed by the framework itself. So this is not a framework wide thing.

[bjhargrave]

Comment author: Richard Hall <heavy@ungoverned.org>

Right, thanks. Makes sense. I forgot that OSGi Connect was moving toward virtual bundles. :-)

[bjhargrave]

Comment author: @tjwatson

(In reply to Thomas Watson from comment BZ#0)

Instead, I propose we add a new attribute to OSGi identity namespace to declare a variant. This attribute would start out with two possible values: "osgi.default" or "osgi.connect". If no value is present it means "osgi.default". This way other variants can be defined in the future or by other specifications.

After more thought, decided variant is not flexible enough. Now going with attribute 'tags':

To allow the discovery and detection of connect bundles the osgi.identity namespace has a new attribute defined named tags. The tags attribute provides a versatile way to identify some aspect of a resource for any reason. The value of this attribute must be List which is empty by default. For connect bundles installed in the framework the value osgi.connect is added to the list of tags.

[bjhargrave]

Comment author: @rinswind

Placing something in the identity namespace does not support the "RFC-245-Java Modules" use case whereby you should be able to use a vanilla ResolveContext to build a base JRE.

This requires that the identifier is on the Bundle wiring capability not the identity capability. The reasons are:

• The module-to-module dependency is modelled as Require-Bundle
• A module dependency must not be resolved to a real bundle.

A clean way to do this is to add a marker attribute on the Bundile Wiring capability:

osgi.wiring.bundle; osgi.wiring.bundle=; bundle-version=; bundle-type=”java.module|java.classpath|osgi”

and to limit the Bundle requirement to require that attribute:

osgi.wiring.bundle; filter:=”(& (osgi.wiring.bundle=) (bundle-version=) (connect=java.module))”; <--- wire only to other modules

[bjhargrave]

Comment author: @tjwatson

During the CPEG call we discussed the tags attribute some. It was agreed that the tags attribute should fan out to osgi.identity, osgi.wiring.bundle, and osgi.wiring.host like other attributes that can be specified on Bundle-SymbolicName.

For example:

Bundle-SymbolicName: com.acme.foo; tags:List=java.module

If a bundle is a connect bundle then the framework will add osgi.connect to the List<String tags attribute and that attribute list is propagated to osgi.identity, osgi.wiring.bundle, and osgi.wiring.host capabilities.

So the produced bundle meta-data for a JPMS module can use this BSN meta-data to get a tags attribute on the osgi.wiring.bundle that can be used in requirement filters from osgi.wiring.bundle requirements.

[bjhargrave]

Comment author: @tjwatson

This is addressed in the spec now.