Implementation of "160. Feature Launcher Service Specification" ( issues 8, 9, 10, 11, 12, 18 )

[ideas-into-software]

• Set up for integration testing to work with OSGi environment

• Temporary fix for issues with 'Apache Maven' / 'Apache Maven Resolver', where many dependencies lack OSGi headers

• Implementation of 'The Feature Runtime Service', including:

  • Install a feature into the running OSGi framework instance based on the supplied feature JSON
  • Update a feature in the runtime based on the supplied feature JSON
  • Remove an installed feature
  • Introspecting the installed Features

• Refactoring / fixes / improvements

[ideas-into-software]

#8
#9
#10
#11
#12
#18

[ideas-into-software]

Issues

Most important issues encountered:

• issues with numerous "Apache Maven", "Apache Maven Resolver" and "Apache HttpComponents" JARs which lack OSGi headers, observed both during resolve and runtime; temporary fix applied in bnd-maven-plugin configuration, using conditionalpackage and includeresource where classes would not be pulled otherwise because they're used indirectly;

• issues with dependencies whose requirements could not be satisfied - e.g. had to replace org.apache.johnzon:johnzon-core:jakarta ( pulled in by org.apache.felix.feature ) with org.glassfish:jakarta.json, etc., because it required osgi.contract=JavaJSONP which could not be satisfied by none of the dependencies I checked;

Questions

1. should FeatureRuntime remove all installed features when deactivated ? a la org.eclipse.sensinact.gateway.launcher.FeatureLauncher; BTW: I discovered org.eclipse.sensinact.gateway.launcher.FeatureLauncher when you pointed me to org.eclipse.sensinact.gateway/pom.xml on Monday - I figured this was a prototype of what now is called FeatureRuntime and some small parts of that logic were re-used in com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl;

2. should different versions of same bundle be supported ? see com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl.AbstractOperationBuilderImpl.duplicatesExistingBundle(ID), which I had to implement because of conflicts between what framework was already launched with ( as defined in runbundles of integration-test.bndrun ) and what feature being installed contains;

3. how should isInitialLaunch be determined if running framework contains only bundles which have no metadata about how they were installed into framework (e.g. if they were installed by "Feature Launcher" not "Feature Runtime" ) ?

4. how should "aliases for installed bundle" ( org.osgi.service.featurelauncher.runtime.InstalledBundle.getAliases() ) be determined ?

5. why is feature ID part of 'update' methods' signature if it is already present in Feature passed to those methods ? i.e. com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl.update(ID, Feature), com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl.update(ID, Reader);

6. should required OSGi headers be added to relevant "Apache Maven", "Apache Maven Resolver" and "Apache HttpComponents" projects and PRs submitted to their repositories or is temporary fix applied in bnd-maven-plugin configuration ( see above in issues list ) sufficient ? I called it temporary because in my opinion "Feature Launcher" should not contain all these extra classes, but this the quickest fix I came up with;

Next priorities

Please clarify regarding next priorities:

a) bundle revisions ? this is the only part missing from the outline you provided for the demo project several weeks ago (i.e. "show version changes in bundles installed" ? ) - i.e. introspecting installed bundles is implemented, but updates do not "bump" versions, so there is no "version changes" visible yet;

b) command line client ( #21 ) ?

c) other timeout values as defined in "160.8.4.3" ? currently only default ( 5000 ) is used ( com.kentyou.featurelauncher.impl.FeatureLauncherConfigurationManager.waitForService(long) );

d) "owning features" ( org.osgi.service.featurelauncher.runtime.InstalledBundle.getOwningFeatures() ) ? currently only feature to which installed bundle belongs is taken into account;

e) implementation for "160.4.3.2: #3" ( com.kentyou.featurelauncher.impl.FrameworkFactoryLocator.findFrameworkFactory() ) ? see com.kentyou.featurelauncher.impl.FrameworkFactoryLocator.locateFrameworkFactory(Feature, List<ArtifactRepository>) - currently "160.4.3.2: #2" and "160.4.3.2: #4" is implemented;

f) merging bundles ? ( #19 )

g) merging configurations ? ( #20 )

h) additional extension handlers ( #16 ) ? i.e. in addition to com.kentyou.featurelauncher.impl.decorator.LaunchFrameworkFeatureExtensionHandlerImpl;

i) feature decorators ( #15 ) ?

j) feature variables ( #13 ) ?

k) bundle start levels ( #14 ) ?

[timothyjward]

This all looks fine.

[timothyjward]

Issues

Most important issues encountered:

• issues with numerous "Apache Maven", "Apache Maven Resolver" and "Apache HttpComponents" JARs which lack OSGi headers, observed both during resolve and runtime; temporary fix applied in bnd-maven-plugin configuration, using conditionalpackage and includeresource where classes would not be pulled otherwise because they're used indirectly;
• issues with dependencies whose requirements could not be satisfied - e.g. had to replace org.apache.johnzon:johnzon-core:jakarta ( pulled in by org.apache.felix.feature ) with org.glassfish:jakarta.json, etc., because it required osgi.contract=JavaJSONP which could not be satisfied by none of the dependencies I checked;

The way that you've fixed these problems is fine. I think that in the long run we'll end up using the maven-shade-plugin to have our own private copy of all the dependencies in an uber-jar. That will be less good from a release perspective (we'll need regular releases for bug/security fixes) but it will make the whole thing much simpler for users to consume. There's no need for you to look at fixing this any more that you already have.

Questions

1. should FeatureRuntime remove all installed features when deactivated ? a la org.eclipse.sensinact.gateway.launcher.FeatureLauncher; BTW: I discovered org.eclipse.sensinact.gateway.launcher.FeatureLauncher when you pointed me to org.eclipse.sensinact.gateway/pom.xml on Monday - I figured this was a prototype of what now is called FeatureRuntime and some small parts of that logic were re-used in com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl;

In the long run I see three options (set in configuration) either:

• the installed features are all removed
• the installation state is persisted and "inherited" on restart
• the installation state is lost, but the bundles and configurations are left as is

The specification is silent on this issue, so whatever is being done now (leaving things as is I think) is fine.

2. should different versions of same bundle be supported ? see com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl.AbstractOperationBuilderImpl.duplicatesExistingBundle(ID), which I had to implement because of conflicts between what framework was already launched with ( as defined in runbundles of integration-test.bndrun ) and what feature being installed contains;

Yes. This is important. Exact collisions (i.e. the same ID) should result in the installed bundle being owned by more than one feature.

3. how should isInitialLaunch be determined if running framework contains only bundles which have no metadata about how they were installed into framework (e.g. if they were installed by "Feature Launcher" not "Feature Runtime" ) ?

isInitialLaunch exists on InstalledFeature and is set to true if and only if the Feature was launched by the Feature Launcher. If we don't have information then there will be no InstalledFeature with isInitialLaunch returning true. Any other bundles in the runtime don't appear in an InstalledFeature so you don't need to worry about them.

4. how should "aliases for installed bundle" ( org.osgi.service.featurelauncher.runtime.InstalledBundle.getAliases() ) be determined ?

If you try to install a bundle based on ID and you get a "clash" with an existing bundle (same symbolic name and version) then this means that there's an alias in play. The new InstalledFeature should use the new ID in the InstalledBundle setting the old ID as an alias. The existing InstalledFeature should keep using the existing ID in the InstalledBundle with the new ID as an alias.

5. why is feature ID part of 'update' methods' signature if it is already present in Feature passed to those methods ? i.e. com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl.update(ID, Feature), com.kentyou.featurelauncher.impl.runtime.FeatureRuntimeImpl.update(ID, Reader);

The ID being passed is the ID of the feature to update, the Feature/Reader is the new version to update to which will, in general, have a different ID

6. should required OSGi headers be added to relevant "Apache Maven", "Apache Maven Resolver" and "Apache HttpComponents" projects and PRs submitted to their repositories or is temporary fix applied in bnd-maven-plugin configuration ( see above in issues list ) sufficient ? I called it temporary because in my opinion "Feature Launcher" should not contain all these extra classes, but this the quickest fix I came up with;

As mentioned above, I think these will end up being shaded into the implementation jar. What you've done is fine and doesn't need to be changed.

Next priorities

Please clarify regarding next priorities:

a) bundle revisions ? this is the only part missing from the outline you provided for the demo project several weeks ago (i.e. "show version changes in bundles installed" ? ) - i.e. introspecting installed bundles is implemented, but updates do not "bump" versions, so there is no "version changes" visible yet;

b) command line client ( #21 ) ?

c) other timeout values as defined in "160.8.4.3" ? currently only default ( 5000 ) is used ( com.kentyou.featurelauncher.impl.FeatureLauncherConfigurationManager.waitForService(long) );

d) "owning features" ( org.osgi.service.featurelauncher.runtime.InstalledBundle.getOwningFeatures() ) ? currently only feature to which installed bundle belongs is taken into account;

e) implementation for "160.4.3.2: #3" ( com.kentyou.featurelauncher.impl.FrameworkFactoryLocator.findFrameworkFactory() ) ? see com.kentyou.featurelauncher.impl.FrameworkFactoryLocator.locateFrameworkFactory(Feature, List<ArtifactRepository>) - currently "160.4.3.2: #2" and "160.4.3.2: #4" is implemented;

f) merging bundles ? ( #19 )

g) merging configurations ? ( #20 )

h) additional extension handlers ( #16 ) ? i.e. in addition to com.kentyou.featurelauncher.impl.decorator.LaunchFrameworkFeatureExtensionHandlerImpl;

i) feature decorators ( #15 ) ?

j) feature variables ( #13 ) ?

k) bundle start levels ( #14 ) ?

I would suggest the following priority order:

1. b) command line client ( Add the Command line client #21 )
2. d) "owning features" ( org.osgi.service.featurelauncher.runtime.InstalledBundle.getOwningFeatures() ) ? currently only feature to which installed bundle belongs is taken into account;
3. i) feature decorators ( [ Feature Decoration ] Feature Decorators #15 )
4. new enforce extension handling (i.e. fail launch if there is no handler for a mandatory extension)
5. h) additional extension handlers ( [ Feature Decoration ] Feature Extension Handlers #16 ) ? i.e. in addition to com.kentyou.featurelauncher.impl.decorator.LaunchFrameworkFeatureExtensionHandlerImpl;
6. a) bundle revisions ? this is the only part missing from the outline you provided for the demo project several weeks ago (i.e. "show version changes in bundles installed" ? ) - i.e. introspecting installed bundles is implemented, but updates do not "bump" versions, so there is no "version changes" visible yet;
7. k) bundle start levels ( Setting the bundle start levels #14 )

If you get further than this, then pick any order you like for the rest.