[JBoss JIRA] Issue Comment Edited: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Lincoln Baxter III edited comment on CDI-4 at 5/10/11 1:14 PM:
---------------------------------------------------------------
If we add this API, I'd also like to see an SPI that can be used in tandem, so that Event firing may additionally be controlled using custom annotations and an Event firing controller.
For instance:
{code}@EventBinding
public annotation Controlled { ... values ...}{code}
{code}(a)Controlled(Type.DELTA)
public class EventInstance {...}{code}
Where the annotation is bound to the controller just like we do for Interceptors and Decorators (which also need an ordering solution if I am not mistaken.)
{code}
@Controlled
public class CustomController implements EventController
{
@Override
public void performEvent(EventInstance<?> event, Controlled anno, Set<ObserverInstance> observers) {
// this method can sort through the list of observers and fire the event for each observer in order as it sees fit.
for( ObserverInstance o : observers )
{
if(Type.DELTA.equals(anno.type()))
o.fire(event.getEvent())
else
o.fire(new EventInstance("foo"));
}
}
}
{code}
This would effectively enable custom ordering and fire-control, without additional coupling or implementation specific details. However, I don't believe that @Before and @After could be implemented using this SPI; this would be an additional feature that could take advantage of the @Before or @After hints if desired.
was (Author: lincolnthree):
If we add this API, I'd also like to see an SPI that can be used in tandem, so that Event firing may additionally be controlled using custom annotations and an Event firing controller.
For instance:
{code}@EventController
public annotation Custom { ... values ...}{code}
{code}(a)EventController(Type.DELTA)
public class EventInstance {...}{code}
Where the annotation is bound to the controller just like we do for Interceptors and Decorators (which also need an ordering solution if I am not mistaken.)
{code}
@Custom
public class CustomController implements EventController
{
@Override
public void performEvent(EventInstance<?> event, Annotation anno, Set<ObserverInstance> observers) {
// this method can sort through the list of observers and fire the event for each observer in order as it sees fit.
for( ObserverInstance o : observers )
{
if(Type.DELTA.equals(anno.type()))
o.fire(event.getEvent())
else
o.fire(new EventInstance("foo"));
}
}
}
{code}
This would effectively enable custom ordering and fire-control, without additional coupling or implementation specific details. However, I don't believe that @Before and @After could be implemented using this SPI; this would be an additional feature that could take advantage of the @Before or @After hints if desired.
> 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 Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Lincoln Baxter III edited comment on CDI-4 at 5/10/11 1:15 PM:
---------------------------------------------------------------
If we add this API, I'd also like to see an SPI that can be used in tandem, so that Event firing may additionally be controlled using custom annotations and an Event firing controller.
For instance:
{code}@EventBinding
public annotation Controlled { ... values ...}{code}
{code}(a)Controlled(Type.DELTA)
public class EventInstance {...}{code}
Where the annotation is bound to the controller just like we do for Interceptors and Decorators (which also need an ordering solution if I am not mistaken.)
{code}
@EventBinding
@Controlled
public class CustomController implements EventController
{
@Override
public void performEvent(EventInstance<?> event, Controlled anno, Set<ObserverInstance> observers) {
// this method can sort through the list of observers and fire the event for each observer in order as it sees fit.
for( ObserverInstance o : observers )
{
if(Type.DELTA.equals(anno.type()))
o.fire(event.getEvent())
else
o.fire(new EventInstance("foo"));
}
}
}
{code}
This would effectively enable custom ordering and fire-control, without additional coupling or implementation specific details. However, I don't believe that @Before and @After could be implemented using this SPI; this would be an additional feature that could take advantage of the @Before or @After hints if desired.
was (Author: lincolnthree):
If we add this API, I'd also like to see an SPI that can be used in tandem, so that Event firing may additionally be controlled using custom annotations and an Event firing controller.
For instance:
{code}@EventBinding
public annotation Controlled { ... values ...}{code}
{code}(a)Controlled(Type.DELTA)
public class EventInstance {...}{code}
Where the annotation is bound to the controller just like we do for Interceptors and Decorators (which also need an ordering solution if I am not mistaken.)
{code}
@Controlled
public class CustomController implements EventController
{
@Override
public void performEvent(EventInstance<?> event, Controlled anno, Set<ObserverInstance> observers) {
// this method can sort through the list of observers and fire the event for each observer in order as it sees fit.
for( ObserverInstance o : observers )
{
if(Type.DELTA.equals(anno.type()))
o.fire(event.getEvent())
else
o.fire(new EventInstance("foo"));
}
}
}
{code}
This would effectively enable custom ordering and fire-control, without additional coupling or implementation specific details. However, I don't believe that @Before and @After could be implemented using this SPI; this would be an additional feature that could take advantage of the @Before or @After hints if desired.
> 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 Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Lincoln Baxter III commented on CDI-4:
--------------------------------------
If we add this API, I'd also like to see an SPI that can be used in tandem, so that Event firing may additionally be controlled using custom annotations and an Event firing controller.
For instance:
{code}@EventController
public annotation Custom { ... values ...}{code}
{code}(a)EventController(Type.DELTA)
public class EventInstance {...}{code}
Where the annotation is bound to the controller just like we do for Interceptors and Decorators (which also need an ordering solution if I am not mistaken.)
{code}
@Custom
public class CustomController implements EventController
{
@Override
public void performEvent(EventInstance<?> event, Annotation anno, Set<ObserverInstance> observers) {
// this method can sort through the list of observers and fire the event for each observer in order as it sees fit.
for( ObserverInstance o : observers )
{
if(Type.DELTA.equals(anno.type()))
o.fire(event.getEvent())
else
o.fire(new EventInstance("foo"));
}
}
}
{code}
This would effectively enable custom ordering and fire-control, without additional coupling or implementation specific details. However, I don't believe that @Before and @After could be implemented using this SPI; this would be an additional feature that could take advantage of the @Before or @After hints if desired.
> 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 Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-7:
-----------------------------
I tend to agree, and this is what the spec said until close to the FD, at the last minute this was revised. This is also what the examples show.
Christian, this remains an issue, nevermind an issue in the past ;-)
> 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-30) An API for managing built in contexts
by Shane Bryzak (JIRA)
[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ]
Shane Bryzak commented on CDI-30:
---------------------------------
There is no @ConversationScoped annotation in Seam 3 that I'm aware of. We need the management API to be able to support conversation management within view technologies other than JSF. Currently, we need to use a non-portable solution to achieve this, however it should have really been part of the CDI 1.0 specification and in my opinion it was an oversight that it was not included.
> An API for managing built in contexts
> -------------------------------------
>
> Key: CDI-30
> URL: https://issues.jboss.org/browse/CDI-30
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Fix For: 1.1 (Proposed)
>
>
> Add management API for built in contexts allowing them to be reused as needed.
--
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 Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ]
Marius Bogoevici commented on CDI-7:
------------------------------------
I think that we should go with "observer qualifiers must be a subset of event qualifiers". We follow the same logic on injection (a bean that has a superset of injection point's qualifiers is a match) and interceptor bindings (an interceptor that has a superset of the interceptor bindings qualifiers is a match), and cannot see why we cannot go with the same logic here.
I tend to think of events being "injected" into observer methods so I find it very easy to reason that a @Red @Plastic Foobar is at the same time a @Red Foobar and a @Plastic Foobar so I can observe both:
void doWith(@Red Foobar) "handle all foobars which are red"
void doWith(@Plastic Foobar), "handle all foobars which are made of plastic"
Incidentally, I believe that this promotes better separation of concerns, as each qualifier may presumably express a different quality of the event being observed (so what I do because the event is @Red may be completely orthogonal to what I do because the event is @Plastic), much better than:
void doWith(@Red @Plastic Foobar) observing both @Red Foobar and @Plastic Foobar
Also, we need to consider what happens when the model gets extended. Suppose that someone adds an additional qualifier to the event model - for example @Price(EXPENSIVE) as opposed to @Price(CHEAP) and adds that to the fired events. If we followed the "observer qualifiers must be a superset of event qualifiers" then all the current observers would have to be changed to adapt to this, and I can't see a reason why they should.
In a nutshell, I believe that "observer qualifiers must be a subset of event qualifiers" is more intuitive and promotes better separation of concerns.
> 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] 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/9/11 3:43 PM:
------------------------------------------------------
_Mike, can you impl your solution on top of Jason's proposal?_
Most likely. However, it's probably not something we could target in our own client CDI stuff. So if the {{@Before}} {{@After}} stuff was not standardized, we'd be forced to couple our stuff to a specific extension. That's the only downside for us.
It seems to me that, while not necessarily a problem for the majority, we should strongly consider if this is a minority we should ignore. My opinion is that, while at any given time this is a minority problem, the majority will probably run into it at some point or another.
My personal preference would be for _both_ an SPI and an standard for ordering in the programming model.
was (Author: cbrock):
_Mike, can you impl your solution on top of Jason's proposal?_
Most likely. However, it's probably not something we could target in our own client CDI stuff. So if the {{@Before}} {{@After}} stuff was not standardized, we'd be forced to couple our stuff to a specific extension. That's the only downside for us.
It seems to me that, while not necessarily a problem for the majority, we should strongly consider if this is a minority we should ignore. My opinion is that, while at any given time this is a minority problem, the majority will probably run into it at some point or another.
> 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/9/11 3:41 PM:
------------------------------------------------------
_Mike, can you impl your solution on top of Jason's proposal?_
Most likely. However, it's probably not something we could target in our own client CDI stuff. So if the {{@Before}} {{@After}} stuff was not standardized, we'd be forced to couple our stuff to a specific extension. That's the only downside for us.
It seems to me that, while not necessarily a problem for the majority, we should strongly consider if this is a minority we should ignore. My opinion is that, while at any given time this is a minority problem, the majority will probably run into it at some point or another.
was (Author: cbrock):
_Mike, can you impl your solution on top of Jason's proposal?_
Most likely.
> 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