[
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