HK2 Feature Enablement and Addition Not Flexible or Scalable

[glassfishrobot]

Currently enabling or adding new features to HK2 is not flexible or dynamic. HK2 should emulate Jersey which seems to have the right idea with their Feature and AutoDiscoverable functionality.

Ideally I would love to be able to:

1. Register existing feature``` //no more ServiceLocatorUtilities.enableTopicDistribution(locator); locator.register(TopicDistribution.class);

2. Register a custom feature``` //enable feature class locator.register(SomeFeature.class); //enable an instance of a feature class locator.register(new SomeFeature());

3. Dynamically register features via ServiceLoader spi``` //discovered and called by service locator during locator creation process public class MyFeatures implements ServiceLocatorAutoDiscovery { public boolean configure(ServiceLocatorContext context) { //context allows for the ability to register a feature, get the //underlying service locator, add/build new descriptor/services, //register binders, etc. //i.e. if(context.isRegistered(SomeFeature.class) { context.register(SomeFeature.class); } } }

   
   #### Affected Versions
   [2.3.0]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/hk2/issues/283
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @jwells131313

[glassfishrobot]

@glassfishrobot Commented Reported by @saden1

[glassfishrobot]

@glassfishrobot Commented @jwells131313 said: I guess I don't understand this request. Most features (such as topic distribution, or new contexts) are already just HK2 services, and so are able to be added dynamically like anything else. Most of those "enableTopicDistribution" type things are just there to add the default HK2 versions of those services.

So... seems like hk2 already does this? Am I missing something? The only other thing that you mention here which is about a way to only register something if not already registered is already covered in #273 I think

[glassfishrobot]

@glassfishrobot Commented @saden1 said: Sorry I wasn't clear, I probably should have formulated my thoughts better before creating the issue.

What I am really getting at is a formalized and documented move towards modularity and extensibility by HK2. While everything is just a service that can be added dynamically features are intrinsically different from just a collection of services in that they facilitate extension of HK2. Today, if you wanted to add a new feature to HK2 it would requires the addition of yet another ServiceLocatorUtilities.enableAwesomeFeature(locator) method. In addition these features are inseparable from the other features and even though one doesn't have to enable them they are there nonetheless. As HK2 grows this way of doing things is probably not scalable. Then there are HK2 features like AOP which are features that don't require enablement but are there.

Right now HK2 has all the fundamental building blocks necessary to get the ball rolling on implementing the feature concept.

1. There's the Binder API which can be used to programmatically create a feature.
2. There's the DescriptorFileFinder and Populator API which can be used to discover special feature descriptor files. Conceptually a feature can be thought of as system feature, fundamental feature such as Events or Immediate, that is provided by the HK2 team, or a user feature developed by a third party.

Internally HK2 will need to take a few steps but after that adding and "enabling" a feature will be a matter of adding a jar file to your classpath or implementing a feature and making it available for population via a Binder or classpath discriptors:

1. Separate its system features (Events, Immediate, etc) into separate projects/modules.
2. Each of these modules will contain a Binder implementation that facilitates programmatic feature registration.
3. Introduce new ServiceLocatorUtilities or ServiceLocator methods for registering a feature and ascertaining whether it is already registered. For binding one could re-purpose the "ServiceLocatorUtilities.bind" method but it's probably better to be semantically be clear.
4. Add two DescriptorFileFinder implementations one for discovering system features ("META-INF/hk2-locator/system") and another for user features ("META-INF/hk2-locator/feature").
5. During ServiceLocator creation process system and user feature should be discovered and the locator should be populated with these discovered services (system features before user features).

p.s Out of curiosity why isn't there a bind method in the ServiceLocator contract/impl?

[glassfishrobot]

@glassfishrobot Commented @jwells131313 said: I'll answer that last question first: There is no bind method in ServiceLocator because ServiceLocator is supposed to be about finding services and/or descriptors. In fact, the ONLY true way to add and remove descriptors from a Locator is with the DynamicConfiguration.commit method (DynamicConfiguration objects coming from the DynamicConfigurationService service). ALL other ways of adding/removing descriptors to a ServiceLocator are completely built on the DynamicConfiguration.commit method. This includes both types of EDSL binders, as well as all the ServiceLocatorUtilities methods such as "addClasses" and the like, and even the populate methods that read the service-locator files from jars eventually just boil down to the DynamicConfiguration.commit method.

That being said, I like your idea of a grouping of services that can be considered a feature. Then features can depend on other features etc. We have the start of that (such as the EDSL binder methods, which can group services). However, I do think some more infrastructure is needed to truly support them, and things like dependencies between them, and even things like being able to remove them cogently from a running ServiceLocator. Those last few things we certainly do not have right now.

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA HK2-239