Issue Details (XML | Word | Printable)

Key: GLASSFISH-18921
Type: Improvement Improvement
Status: Open Open
Priority: Critical Critical
Assignee: mtaube
Reporter: Sanjeeb Sahoo
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Allow configuration of Service Registry, e.g., dropping/replacing services

Created: 19/Jul/12 11:21 AM   Updated: 11/Feb/13 09:46 PM
Component/s: hk2
Affects Version/s: None
Fix Version/s: 4.0.1

Time Tracking:
Not Specified

Tags:
Participants: mtaube and Sanjeeb Sahoo


 Description  « Hide

We need a better way to configure the service registry without entering too far into the territory of "config driven services" model. I have not looked at the code post HK2 2.x integration, but earlier HK2 API exposed methods in InhabitantParser to customize the service registry. The customization supported replacing/removing of services. I don't think they are written carefully enough to take care of timing issues, but I would expect them to work if those methods are called before any service is actually active. As part of HK2 2.x effort, they may have been improved as well. We do have some code (which I don't actually like) that actually uses those methods to drop/replace services at system bootstrapping time. This is mostly done in the embedded code path. By now you must have come across those files as part of HK2 2.x integration. e.g., nucleus/core/kernel/src/main/java/org/glassfish/kernel/embedded/EmbeddedInhabitantsParser.java. There has to be a better way to do this. I don't like the system property based check that's going on in this file or the getName() based matching. What I am hoping for is a way to provide some service customization information as part of domain.xml so that we can get rid of InhabitantParserDecorators. We could have an entry like:

<hk2-service-registry-customization>
<dropped-service>
</dropped-service>
<replace-service></replace-service>
</hk2-service-registry-customization>

This can even be used to add ranks to services to control service selection when multiple ones are present.

Don't read too much into these XML descriptor, they are just a discussion starter. We could read this from a different file, but why invent another configuration source instead of using domain.xml?

Thanks,
Sahoo



There are no comments yet on this issue.