What are the sources of the multiple beans that implement an interface like the TM? In general, there should only be one true implementation of an interface like the TM in a given server instance. If there is a legitimate reason for this, perhaps we need a mapping from interface to bean name for the resolving the ambiguity. We should have a plugin interface for this as well.

How is this suposed to work at the MC level?

All I can say atm is check my service-mix branch for more details,

as that's where this is properly implemented:

* http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/framework/branches/alesj_service-mix/

Looking at this, it seems that it is the responsiblility of the client to use a different API when there is a posibility multiple matching contexts. This does not seem right IMHO.

This is OK, and this is how it should be -- dumb as possible on server/registry side.

It's the clients that must know what to bind and what not.

Again, see my branch for custom OSGiMetaData; <osgi > bean element.

What are the sources of the multiple beans that implement an interface like the TM? In general, there should only be one true implementation of an interface like the TM in a given server instance. If there is a legitimate reason for this, perhaps we need a mapping from interface to bean name for the resolving the ambiguity. We should have a plugin interface for this as well.

Multiple matching refs come from duplicate MC ControllerContext registrations.

Once as MC bean, 2nd as OSGi service -- for same instance.

Plugin interface?

The OSGi semanic is that a client requesting a service reference will get at most one according to well defined ordering rules. It is actually very common that there is more than one service available that implements a given interface.

Sure, why is this then a problem?

We mock the OSGi ordering rules in MDRUtils for non-OSGi services/contexts.

A plugin interface that replaces the current more than 1 match loop to resolve the ambiguity from the context of the caller:

      if (numberOfMatchingBeans != 1)
      {
         if (numberOfMatchingBeans > 1)
         {
            log.warn("Multiple beans match class type [enable trace log for details]: " + clazz);
            if (log.isTraceEnabled())
            {
               log.trace("Matching contexts: " + contexts);
            }
         }
         return null;
      }

It seems like we should have more control over how this lookup behaves as if one can register multiple context matching a class, it is not very useful to not be able to have a method that returns a match.

There is no difference in type or behavior between the TM registered with the MC or OSGi service registry other than life cycle states or some such right?

A plugin interface that replaces the current more than 1 match loop to resolve the ambiguity from the context of the caller:

 

      if (numberOfMatchingBeans != 1)
      {
         if (numberOfMatchingBeans > 1)
         {
            log.warn("Multiple beans match class type [enable trace log for details]: " + clazz);
            if (log.isTraceEnabled())
            {
               log.trace("Matching contexts: " + contexts);
            }
         }
         return null;
      }
 
 

 

It seems like we should have more control over how this lookup behaves as if one can register multiple context matching a class, it is not very useful to not be able to have a method that returns a match.

I don't see a reason for a plugin.

Or how are you gonna apply every caller's context?

This is a straight fwd method, if you want more control - which is what you want -- you have this 2 methods:

/**
    * Get all instantiated contexts of a given type
    *
    * @param clazz the type
    * @return the contexts
    */
   Set<ControllerContext> getInstantiatedContexts(Class<?> clazz);

   /**
    * Get all contexts of a type which are in the given state or above.
    * Note: state must not be null
    *
    * @param clazz the type
    * @param state the required state
    * @return the contexts
    * @throws IllegalArgumentException for null state
    */
   Set<ControllerContext> getContexts(Class<?> clazz, ControllerState state);

Then you can freely apply caller's context.

There is no difference in type or behavior between the TM registered with the MC or OSGi service registry other than life cycle states or some such right?

This, plus type hiding -- OSGi doesn't expose much else than registered interfaces, where POJO reveals it all. :-)

OSGi also has a notion of filtering (LDAP query), which can be mocked in our MC beans as well (see tests in alesj_service-mix branch).

...

The reason for a plugin would be to address what seems to be an asymmetry and very limited applicability of the getContextByClass(Class<?> clazz) method. If I'm doing a type based lookup, I would think I would set my context filter policy plugin and then call getContextByClass(Class<?> clazz). As it is now, the javadoc for getContextByClass(Class<?> clazz) needs to say its useless if more than one context for a given type exists.

As it is now, the javadoc for getContextByClass(Class<?> clazz) needs to say its useless if more than one context for a given type exists.

I view this as a shortcut for autowiring by type.

Like I said, if you need more control, use different method.

Current registry is nothing more than a fancy Map.

Or what would you need / expect?

I guess we can re-write it to use sort of MapMaker::makeComputingMap?

* http://code.google.com/p/google-collections/source/browse/trunk/src/com/google/common/collect/MapMaker.java

Making it easier to apply your context / filtering.

The concern is that if it is common to have multiple contexts implementing the same interface, we should have an efficient mechanism for resovling the correct context. Having to reimplement querying all installed contexts and apply filtering rules is prone to error and inefficiency and we need to fight that tendency as performance of contextual injection is important.

If we can have more information available such that one can have a getContextByClass(Class<?> clazz, 

ControllerContext caller) and have this work in O(1).

I don't think there are many cases where you need typed injection, at least not in current AS/MC.

And even if you had multiple cases, you usually don't have a lot of matching beans; mostly a handful.

I don't see how your API would be any useful, as you have too dynamic system to somehow index that.

e.g. in OSGi case, any LDAP filter at the lookup, where matching properties can change on the fly on existing services

Or do you really want to cache any possible scenario and do updates/re-indexing on runtime changes?

Although for CDI kind of injection, afair, we currently don't index things,

but this idea - indexing - was part of discussion and actual lookup implementation; plugable - prepared but not yet implemented.

(this is easier, since it's statically typed - cannot change at runtime)