In my case there is no need to distinguish them. I just want to look up for all components of a specific type and call a method on each found component, e.g. the type is a listener interface and I want to notify all registered listeners that sth. has happened (see whiteboard patter in OSGi).
For the listener example the precedence rule is the classpath.. Actually, I'm not sure what's the best way to establish precedence for components that relies on a specific invocation order. Currently I think the best and clearest way is to express that via the components interface, e.g. a priority method or via a specific annotation (is there a priority annotation in JSR330?). And the caller is responsible to call the components in the appropriate order. For example, I use that approach to establish the invocation order of generator participants that can be contributed as JSR330 components and will be invoked during the generation process of a management component that looks up all participants, orders them by priority and invokes them. > -----Ursprüngliche Nachricht----- > Von: Mark Struberg [mailto:strub...@yahoo.de] > Gesendet: Mittwoch, 3. August 2011 10:56 > An: Maven Developers List > Betreff: Re: AW: AW: PlexusContainer#lookupList(role) returns only one > component > > If you like to distinguish them, what JSR-330 mechanism do you use? > Qualifiers? There must be a > precedence rule somehow... > > LieGrue, > strub > > --- On Wed, 8/3/11, bernd.v...@bosch-si.com <bernd.v...@bosch-si.com> wrote: > > > From: bernd.v...@bosch-si.com <bernd.v...@bosch-si.com> > > Subject: AW: AW: PlexusContainer#lookupList(role) returns only one component > > To: dev@maven.apache.org > > Date: Wednesday, August 3, 2011, 6:22 AM > > Sadly, this doesn't work for my case. > > I have several components with exactly the same role and > > hint, e.g. role=IFooListener.class, hint="default". > > > > Using lookupMap returns a map which maps hint to role... > > so, I get a map that contains only the first component > > plexus finds. > > > > Currently, I'm looking for some kind of > > GuiceToPlexus-Bridge. I want to create a guice injector that > > is able to delegate "JSR330 lookups" to a plexus container. > > With this approach I could use simple JSR330 API without > > losing the plexus components. > > > > > -----Ursprüngliche Nachricht----- > > > Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] > > > Gesendet: Dienstag, 2. August 2011 19:44 > > > An: Maven Developers List > > > Betreff: Re: AW: PlexusContainer#lookupList(role) > > returns only one component > > > > > > I recently used lookupMap API [1] to detect which > > wagon providers was > > > available in m-site-p 3.0 > > > It worked like a charm > > > > > > Regards, > > > > > > Hervé > > > > > > [1] http://plexus.codehaus.org/plexus-containers/plexus-container- > > > > > > default/apidocs/org/codehaus/plexus/PlexusContainer.html#lookupMap(java.lang.Class) > > > > > > Le mardi 2 août 2011, bernd.v...@bosch-si.com > > a écrit : > > > > I'm using the SISU-plexus-shim > > (sisu-inject-plexus-2.1.1). > > > > > > > > > In plexus role+hint forms a "composite key". > > In your case, you had a > > > > > component conflict, and Plexus stashed one > > component over another > > > > > (it's undefined which "wins", but probably > > depends on classpath > > > > > ordering or so). > > > > > > > > Sure, I expected this behavior for the "simple" > > lookup methods which only > > > > returns one component but not for the lookupList > > methods... I hoped I > > > > could use this to get all registered components > > (as I'm used to from other > > > > IoCs). > > > > > > > > Is it possible to use guice directly in a > > "SISU-plexus-shim" environment? > > > > > > > > Thanks, > > > > Bernd > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
