May 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-4: ----------------------------- This problem is very acute for a few people, but doesn't affect a majority. Jason's solution may well be the sweetspot as it allows custom solutions to be implemented. Mike, can you impl your solution on top of Jason's proposal? > 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

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-4: ----------------------------- "Let's 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. They don't. That's why I'm relying purely on qualifiers for ordering." A magic number based solution introduces tight coupling between observers and is non-type-safe. The approach proposed by Mike does introduce an (optional) level of coupling, but not as strong as magic numbers and is type safe. To interleave an observer in a magic number scheme I must know the magic number of *all* other observers I must come before. To interleave in Mike's scheme I simply need to know the qualifer they are using (which is itself reasonably decoupled from the observer method). In general this notion that a non-strongly-typed link between objects is gives looser coupling inherently is extremely flawed. > 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

1
0
0 / 0

[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: ----------------------------- Well it has to be one or the other. There is no basis for it being an exact match in the spec. Either the observer method must be a subset of event qualifiers or the event qualifiers must be a subset of the observer qualifiers. > 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

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-7) Section 10.2, bullet 3, first paragraph contradicts the rest of the section

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-7?page=com.atlassian.jira.plugin.syst... ] Mark Struberg commented on CDI-7: --------------------------------- huh, but I think John has a point. We also need to clarify the opposite situation: what if the sender has more qualifiers than the observers? Imagine what happens if the sender fires an MyEvent which has qualifiers @A @B @C imo void doSomeDing(@Observes @B MyEvent ev) {...} (only having a subset of the fired qualifires) should *not* get invoked, right? > 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

1
0
0 / 0

[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: ----------------------------- John, this means that you require an exact match of qualifiers. This is not even indicated as desired by the spec so would be a major change (not one we could easily make). We need to choose one of Mark's options. > 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

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-23) Allow BeanManager to be resolved as though you were in another bean archive

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-23?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-23: ------------------------------ Yes, I think it's fairly clear and obvious how you get Extension instances (this is wrong in Weld right now btw ;-). However given that the shared library cannot see the classes in the War, it should not be possible to resolve beans defined by classes in the war from the extension. However sometimes you do need to do this from an extension, hence this feature request. BTW I'm not really in love with this soln to the problem, need to think if there are any others. > Allow BeanManager to be resolved as though you were in another bean archive > --------------------------------------------------------------------------- > > Key: CDI-23 > URL: https://issues.jboss.org/browse/CDI-23 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Currently it's not possible to access beans as though you were in another bean manager, something that is useful for extensions to be able to do. For example, if I want to create a facade over the ELResolver, or access a particular configuration bean. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-14: ------------------------------ Note that I am not in love with the method name at all! If we can find a better name then that would be great :-) > 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

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-14: ------------------------------ Given we already have a method called getReference with somewhat different semantics I don't think we should overload it's meaning. Furthermore, Instance<> is the API for "dynamic" injection, and we should *not* introduce a new API for this. My proposal simply makes this API more accessible in non-managed component. > 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

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-23) Allow BeanManager to be resolved as though you were in another bean archive

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-23?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-23: ---------------------------------- > If an extension is provided in a shared library, then it would currently > see the BM which is applicable for the bean archive for that shared library humm, in OWB - even if the Extension is in the shared lib of an EAR - you will get 1 instance of this very Extension _per_ _war_. That's what I meant with 1 BeanManager per WAR in OWB in my explanation above. That's important because the extension might be configured completely different for each WAR. That's the same thing like saying your JSF container must be configured the same for each and every WAR deployed in an EAR. > Allow BeanManager to be resolved as though you were in another bean archive > --------------------------------------------------------------------------- > > Key: CDI-23 > URL: https://issues.jboss.org/browse/CDI-23 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Currently it's not possible to access beans as though you were in another bean manager, something that is useful for extensions to be able to do. For example, if I want to create a facade over the ELResolver, or access a particular configuration bean. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (CDI-23) Allow BeanManager to be resolved as though you were in another bean archive

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-23?page=com.atlassian.jira.plugin.sys... ] Mark Struberg edited comment on CDI-23 at 5/9/11 10:24 AM: ----------------------------------------------------------- > If an extension is provided in a shared library, then it would currently > see the BM which is applicable for the bean archive for that shared library humm, in OWB - even if the Extension is in the shared lib of an EAR - you will get 1 instance of this very Extension _per_ _war_. That's what I meant with 1 BeanManager per WAR in OWB in my explanation above. That's important because the extension might be configured completely different for each WAR. That's the same thing like saying your JSF container must be configured the same for each and every WAR deployed in an EAR. They really might be configured completely different depending on the WAR. was (Author: struberg): > If an extension is provided in a shared library, then it would currently > see the BM which is applicable for the bean archive for that shared library humm, in OWB - even if the Extension is in the shared lib of an EAR - you will get 1 instance of this very Extension _per_ _war_. That's what I meant with 1 BeanManager per WAR in OWB in my explanation above. That's important because the extension might be configured completely different for each WAR. That's the same thing like saying your JSF container must be configured the same for each and every WAR deployed in an EAR. > Allow BeanManager to be resolved as though you were in another bean archive > --------------------------------------------------------------------------- > > Key: CDI-23 > URL: https://issues.jboss.org/browse/CDI-23 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Currently it's not possible to access beans as though you were in another bean manager, something that is useful for extensions to be able to do. For example, if I want to create a facade over the ELResolver, or access a particular configuration bean. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2011