glassfish
  1. glassfish
  2. GLASSFISH-18921

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

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.1
    • Component/s: hk2
    • Labels:
      None

      Description

      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

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            mtaube
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: