Wouldn't it be easier to use fully qualified implementation class name
as component hint? This will even allow stable invocation order if
components are ordered by hint. Maybe not the cleanest approach from
design pureness point of view, should work for "listener" usecase well
enough.
--
Regards,
Igor
On 11-08-03 1:27 PM, [email protected] wrote:
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:[email protected]]
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, [email protected]<[email protected]> wrote:
From: [email protected]<[email protected]>
Subject: AW: AW: PlexusContainer#lookupList(role) returns only one component
To: [email protected]
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:[email protected]]
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, [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
