[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-14:
----------------------------------
Fab, yes we should realy make it clear that those new and all the other BeanManager stuff is only intended for hardcore use (e.g. in parts where you dont have injection available) and should normally not be needed.
regarding getReference(): this returns you a proxy ("Contextual Reference") for the internal contextual instances. So this stuff will give you lifecycle managed instances only.
> 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] Issue Comment Edited: (CDI-14) Add instance() method to BeanManager
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
Fab Mars edited comment on CDI-14 at 5/11/11 3:12 AM:
------------------------------------------------------
At first I roared on the fact a convenience method wasn't available. As everyone else, I wrote a utility class with the 3 lines needed (resolve/createCreationalContext/getReference). It was actually longer to understand the difference between these and InjectionTarget#produce() because the documentation chapter 16.4 was confusing me.
Then I realized you can almost always find a way to work properly, so getting bean refs by hand becomes very, very rare (eg: phaselisteners, components you really have to new() yourself).
What bothered me much more was the lifecycle of such beans. I aksed myself questions like: "If the bean instance was actually instantiated via getReference, will its lifecycle be still respected?" Eventually, I thought the only thing needed would be extra documentation. I actually shared Mark's point sometimes.
Now I'd say it's useless to let every EE developper write the exact same 3 lines of code, so it's better to have a couple of convenience methods (Rick's proposal sounds neat)...BUT I already see deviant behaviors coming amongst the developpers, so I'd be extremely clear on the spec, in the javadoc and in the reference doc about what getting bean refs by hand implies.
was (Author: fabmars):
At first I roared on the fact a convenience method wasn't available. As everyone else, I wrote a utility class with the 3 lines needed (resolve/createCreationalContext/getReference). It was actually longer to understand the difference between these and InjectionTarget#produce() because the documentation chapter 16.4 was confusing me.
Then I realized you can almost always find a way to work properly, so getting bean refs by hand becomes very, very rare (eg: phaselisteners, components you really have to new() yourself).
What bothered me much more was the lifecycle of such beans. I aksed myself questions like: "If the bean instance was actually instantiated via getReference, will its lifecycle be still respected?"
Eventually, I thought the only thing needed would be extra documentation. I actually shared Mark's point sometimes.
Now I'd say it's useless to let every EE developper write the exact same 3 lines of code, so it's better to have a couple of convenience methods (Rick's proposal sounds neat)...BUT I already see deviant behaviors coming amongst the developpers, so I'd be extremely clear on the spec, in the javadoc and in the reference doc about what getting bean refs by hand implies.
> 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-14) Add instance() method to BeanManager
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
Fab Mars commented on CDI-14:
-----------------------------
At first I roared on the fact a convenience method wasn't available. As everyone else, I wrote a utility class with the 3 lines needed (resolve/createCreationalContext/getReference). It was actually longer to understand the difference between these and InjectionTarget#produce() because the documentation chapter 16.4 was confusing me.
Then I realized you can almost always find a way to work properly, so getting bean refs by hand becomes very, very rare (eg: phaselisteners, components you really have to new() yourself).
What bothered me much more was the lifecycle of such beans. I aksed myself questions like: "If the bean instance was actually instantiated via getReference, will its lifecycle be still respected?"
Eventually, I thought the only thing needed would be extra documentation. I actually shared Mark's point sometimes.
Now I'd say it's useless to let every EE developper write the exact same 3 lines of code, so it's better to have a couple of convenience methods (Rick's proposal sounds neat)...BUT I already see deviant behaviors coming amongst the developpers, so I'd be extremely clear on the spec, in the javadoc and in the reference doc about what getting bean refs by hand implies.
> 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] Issue Comment Edited: (CDI-14) Add instance() method to BeanManager
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
George Gastaldi edited comment on CDI-14 at 5/10/11 8:15 PM:
-------------------------------------------------------------
The proposal on Richard is great, as it resembles Component class from Seam 2. This is a very useful feature that IMHO should not be left behind on this spec.
was (Author: gastaldi):
The proposal on Richard is great, as it remembers Component class from Seam 2. This is a very useful feature that IMHO should not be left behind on this spec.
> 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-14) Add instance() method to BeanManager
by Richard Hightower (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
Richard Hightower commented on CDI-14:
--------------------------------------
Some utility methods on the BeanManager for making common operations equate to oneliners would be nice....
public Object getBeanByName(String name);
public <T> T getBeanByName(Class<T> type, String name);
public <T> T getBeanByType(Class<T> type, Annotation... qualifiers);
Or perhaps just add a utility class that takes a BeanManager and provides these if we don't want to clutter up BeanManager.
This would be for cases when a developer can't use injection.
> 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 Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Marius Bogoevici commented on CDI-4:
------------------------------------
I have a comment about the syntax.I quite like the idea of using @Before and @After coupled with qualifiers for ordering event handlers and IMO partial ordering can go a pretty long way in solving the issues that we have.
But, rather than using @Before and @After with the event qualifiers, I think that qualifiers should be placed on event handlers themselves.
So, this may work:
{code}
public void myFirstObserver(@Observes @After(Initialization.class) MyEvent event) {
...
}
public void mySecondObserver(@Observes @Initialization MyEvent event) {
...
}
{code}
but what if I want to order two observers for @Initialization MyEvent ? I can do:
{code}
public void myFirstObserver(@Observes @Initialization @After(Initialization.class) MyEvent event) {
...
}
public void mySecondObserver(@Observes @Initialization MyEvent event) {
...
}
{code}
but that does not do a great favour to readability. On the other hand, what do we do with observers that do not have any qualifier at all? Mike suggested an @OrderingQualifier, but mixing it up with the rest of the qualifiers does not improve readability. On the other hand, ordering is relative to the method not to the event being observed, so why not qualify observer methods themselves (note how I stole the idea of placing the @Before annotation from Christian)?
{code}
@Initialization
public void myFirstObserver(@Observes MyEvent event) {
...
}
@Before(Initialization.class)
public void mySecondObserver(@Observes MyEvent event) {
...
}
{code}
@Initialization can be a special type of annotation, or can be a simple @Qualifer. I also think that the idea can be reused in scenarios such as interceptor/decorator ordering, if we ever consider automatic interceptor/decorator enablement.
> 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:34 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}public class Bean {
@Inject BeanManager manager;
public void fireEvent()
{
manager.fire(new EventInstance());
}
}{code}
The controller is then passed control of the event firing:
{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}
@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.
> 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