[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
Arne Limburg commented on CDI-14:
---------------------------------
In the CDI-project I currently work on, this three calls (BeanManager#getBeans, BeanManager#resolve and BeanManager#getReference) where the first thing a developer wrote a BeanManagerUtil#getReference(BeanManager, T, Annotation...) for. So I think, it are just three lines, but it are three lines that really should be doable in one line. So a BeanManager#getReference(T, Annotation...) or a BeanManager#instance() would be really desirable.
BTW: instance() is enough since one could call instance().select(...), which would be a one-liner, too.
> Add instance() method to BeanManager
> ------------------------------------
>
> Key: CDI-14
> URL: https://issues.jboss.org/browse/CDI-14
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> Currently obtaining a contextual reference is quite a complex operation, adding a method like:
> Instance<Object> instance();
> would make it much easier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg commented on CDI-4:
---------------------------------
> I'm struggling to see how my proposal introduces coupling.
If I understood correctly, then your proposal relies that you have to know the other/all the other observer(s) in your 'before' Observers. If you don't call this coupling, well...
> If I add a jar in the future which
and what if you add another jar with another bean having another @Observes BusEvent? How to make sure your beforeInit also runs _before_ this new observer?
Really, go back to the Portland Pattern Repository or the GoF Design Patterns book and check the Observer/Observable pattern. The whole idea/mechanism is built based on the paradigma that all the involved parties know NOTHNING about each other.
Having some hardcoded before/after stuff is imo really just an obfuscated method call without any further aid.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mike Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mike Brock edited comment on CDI-4 at 5/8/11 3:45 PM:
------------------------------------------------------
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
I'm struggling to see how my proposal introduces coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I add a jar in the future which contains a bean which has say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to. There'd be no guarantee of ordering for all the @Before(Initialize.class) events, but I somehow doubt that would be any trouble in such a use case.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
was (Author: cbrock):
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
I'm struggling to see how my proposal introduces coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I add a jar in the future which contains a bean which has say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mike Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mike Brock edited comment on CDI-4 at 5/8/11 3:42 PM:
------------------------------------------------------
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
I'm struggling to see how my proposal introduces coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I have I add a jar in the future which contains, say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
was (Author: cbrock):
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing, which is to using a sort of "marathon pattern" seems to suffer much more greatly from a coupling problem than what I'm proposing. Because you're relying there being a discretely defined event for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
So I'm struggling to see how my proposal introduces more coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I have I add a jar in the future which contains, say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mike Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mike Brock edited comment on CDI-4 at 5/8/11 3:43 PM:
------------------------------------------------------
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
I'm struggling to see how my proposal introduces coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I add a jar in the future which contains a bean which has say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
was (Author: cbrock):
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing -- which is to use a sort of "marathon pattern" -- seems to suffer greatly from a coupling problem, because you're relying there being a discretely defined event type for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
I'm struggling to see how my proposal introduces coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I have I add a jar in the future which contains, say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mike Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mike Brock edited comment on CDI-4 at 5/8/11 3:41 PM:
------------------------------------------------------
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
The solution that you're proposing, which is to using a sort of "marathon pattern" seems to suffer much more greatly from a coupling problem than what I'm proposing. Because you're relying there being a discretely defined event for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
So I'm struggling to see how my proposal introduces more coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I have I add a jar in the future which contains, say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
was (Author: cbrock):
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
Your solution that you're proposing, which is to using a sort of "marathon pattern" seems to suffer much more greatly from a coupling problem than what I'm proposing. Because you're relying there being a discretely defined event for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
So I'm struggling to see how my proposal introduces more coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I have I add a jar in the future which contains, say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mike Brock (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mike Brock commented on CDI-4:
------------------------------
A few points of contention here:
_"the @Before doesn't scale out in practice. You cannot always change your event if someone adds a jar into the classpath which needs that event"_
Can you give a solid example of this? I mean, one the reasons why I am proposing this, is that the sorting _can_ deal with the addition of new beans which have ordered observers.
Your solution that you're proposing, which is to using a sort of "marathon pattern" seems to suffer much more greatly from a coupling problem than what I'm proposing. Because you're relying there being a discretely defined event for each step. That, in itself, almost entirely precludes the adding of new beans to the container that change the ordering -- at all.
So I'm struggling to see how my proposal introduces more coupling.
Having both {{@Before}} and {{@After}} is, for the very reason of dealing with potentially unseen model, very necessary.
Say I have an event {{BusEvent}}. And it has qualifiers like {{@Initialize}} and {{@PostInitialize}}.
If I have I add a jar in the future which contains, say, something like this:
{code}
public void beforeInit(@Observes @Before(Initialize.class) BusEvent event) {
...
}
{code}
... I would get _exactly_ the kind of behavior I would expect. So I fail to see the problem you're referring to.
---
_"The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event."_
I think this is actually a really good idea. But it's really orthogonal to the problem I'm trying to solve. For the very example I point out above.
It seems to me that event ordering is not something which violates decoupling of events, and is a concept which is purely a component-container contract issue.
Simply having say, a framework like Forge implement comparators, doesn't help readability of the model at all. In fact, it sort of suffers from the same problem that putting the configuration in an XML file suffers from: you can't get any sense of the ordering just by looking at any given observer.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Commented: (CDI-7) Section 10.2, bullet 3, first paragraph contradicts the rest of the section
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ]
John Ament commented on CDI-7:
------------------------------
Also, I'm not saying that we shouldn't support abstract event observers. If we include a qualifier and @Any, then it should act like a partial match, and @Observes @Any Type t should handle any type fired. But we should also handle injecting the Event object that did the firing to do this, so we can find out all qualifiers on the event.
> Section 10.2, bullet 3, first paragraph contradicts the rest of the section
> ---------------------------------------------------------------------------
>
> Key: CDI-7
> URL: https://issues.jboss.org/browse/CDI-7
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 1.0
> Reporter: Pete Muir
> Priority: Blocker
> Fix For: 1.1 (Proposed)
>
>
> "The observer method has all the event qualifiers."
> This contradicts the examples (section 10.2.3) and the use of @Any, all of which indicate that less specific observer methods are also invoked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Commented: (CDI-7) Section 10.2, bullet 3, first paragraph contradicts the rest of the section
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ]
John Ament commented on CDI-7:
------------------------------
Mark,
To understand, you also have to consider the qualified event. Take these two events.
a: @Inject @QualA @QualB Event<MyEvent> evt;
b: @Inject @QualA Event<MyEvent> evtA;
and the following observers
c: void doManyDings(@Observes @QualA @QualB MyEvent ev) {...}
d: void doSomeDing(@Observes @QualA MyEvent ev) {...}
if b is fired, only d is observed.
if a is fired, both c and d are observed.
My preference would be that a firing, results in only c being observed. b firing and d observed only.
> Section 10.2, bullet 3, first paragraph contradicts the rest of the section
> ---------------------------------------------------------------------------
>
> Key: CDI-7
> URL: https://issues.jboss.org/browse/CDI-7
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 1.0
> Reporter: Pete Muir
> Priority: Blocker
> Fix For: 1.1 (Proposed)
>
>
> "The observer method has all the event qualifiers."
> This contradicts the examples (section 10.2.3) and the use of @Any, all of which indicate that less specific observer methods are also invoked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Jason Porter (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Jason Porter commented on CDI-4:
--------------------------------
I mentioned InjectionPoint because ObserverMethod doesn't give you metadata of the containing bean, but we could add that if feel we need it. Otherwise ObserverMethod has the payload type, qualifiers, transaction phase, reception, etc. Seems like everything one would need to make a decision about ordering observers.
I know the spec doesn't call this out explicitly, it's more of an implementation detail, but I'm pretty sure each implementation is going to store the ObeserverMethods in some sort of Iterable (it's actually somewhat implied via the JavaDocs for BeanManager it will be a Set). Adding additional metadata or global explicit ordering seems like overkill when we have easy solutions in the JDK, we just need to expose it.
The service could be something like javax.enterprise.inject.spi.ObserverComparator, applied after the ProcessObserverMethod event. We could actually apply this idea globally to all areas we need ordering (little late for Interceptors though, unless we define a comparator that orders via the XML as a default).
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Mike Brock
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months