[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:
----------------------------------
agree
> So a BeanManager#getReference(T, Annotation...) or a BeanManager#instance() would be really desirable.
Imo getReference would be easier to type because getInstance().select(qualifiers).get() is more complex.
Otoh, there might be use cases where you like to get the power of Instance() without having to go through BeanManager#getBeans ?
> 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
13 years
[JBoss JIRA] Issue Comment Edited: (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 edited comment on CDI-23 at 5/9/11 10:11 AM:
-------------------------------------------------------
{quote}
Nor sure if this is really a problem of the spec. Actually I think this is only caused by Weld being organized hierarchically (Not that OWB is better, but you might get other problems). This makes it more flexible for different classloader configurations, but definitely restricts the use in such cases.
{quote}
Weld uses a peer based organisation not hierarchical, which allows it to be used both in hierarchical classloader configurations such as JBoss AS 6 or in peer based systems such as AS7 or OSGi. Often people encounter it hierarchical situation, but it's worth noting that both are supported.
{quote}
Please note that it's not defined from 'where' (in which jar) you get which BeanManager instance.
{quote}
Yes, this is exactly why I am proposing this feature ;-) As you note implementations vary a lot on class visibility (primarily as EE makes few guarantees here), so we need to provide the ability to query this information in the spec, so that extensions do not start using non-portable assumptions.
{quote}
In OWB we manage the different BeanManager instances on a ContextClassLoader base by default (can be changed via SPI) So all classes accessed in the same WebApp get the same ClassLoader.
{quote}
Remember that CDI must address many different deployment structures, of which a War with libraries is just one.
{quote}
Also: Extensions must not assume a certain classloader or BeanManager hierarchy for being portable - because there is no such thing defined in the spec (neither in CDI nor in EE umbrella).
{quote}
Exactly. However it is often useful to be able to query what beans are installed in another bean archive, for example in the issue I linked. Let's take another example. 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, however it might wish to query the beans installed into bean archive which is applicable for the WAR.
So in conclusion, it's not a "problem of the spec" but rather a problem that extensions encounter and therefore need the specification to provide some abstraction so that this information can be retrieved in a portable fashion.
was (Author: petemuir):
"Nor sure if this is really a problem of the spec. Actually I think this is only caused by Weld being organized hierarchically (Not that OWB is better, but you might get other problems). This makes it more flexible for different classloader configurations, but definitely restricts the use in such cases."
Weld uses a peer based organisation not hierarchical, which allows it to be used both in hierarchical classloader configurations such as JBoss AS 6 or in peer based systems such as AS7 or OSGi. Often people encounter it hierarchical situation, but it's worth noting that both are supported.
"Please note that it's not defined from 'where' (in which jar) you get which BeanManager instance."
Yes, this is exactly why I am proposing this feature ;-) As you note implementations vary a lot on class visibility (primarily as EE makes few guarantees here), so we need to provide the ability to query this information in the spec, so that extensions do not start using non-portable assumptions.
"In OWB we manage the different BeanManager instances on a ContextClassLoader base by default (can be changed via SPI) So all classes accessed in the same WebApp get the same ClassLoader."
Remember that CDI must address many different deployment structures, of which a War with libraries is just one.
"Also: Extensions must not assume a certain classloader or BeanManager hierarchy for being portable - because there is no such thing defined in the spec (neither in CDI nor in EE umbrella)."
Exactly. However it is often useful to be able to query what beans are installed in another bean archive, for example in the issue I linked. Let's take another example. 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, however it might wish to query the beans installed into bean archive which is applicable for the WAR.
So in conclusion, it's not a "problem of the spec" but rather a problem that extensions encounter and therefore need the specification to provide some abstraction so that this information can be retrieved in a portable fashion.
> 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
13 years
[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:
------------------------------
"Nor sure if this is really a problem of the spec. Actually I think this is only caused by Weld being organized hierarchically (Not that OWB is better, but you might get other problems). This makes it more flexible for different classloader configurations, but definitely restricts the use in such cases."
Weld uses a peer based organisation not hierarchical, which allows it to be used both in hierarchical classloader configurations such as JBoss AS 6 or in peer based systems such as AS7 or OSGi. Often people encounter it hierarchical situation, but it's worth noting that both are supported.
"Please note that it's not defined from 'where' (in which jar) you get which BeanManager instance."
Yes, this is exactly why I am proposing this feature ;-) As you note implementations vary a lot on class visibility (primarily as EE makes few guarantees here), so we need to provide the ability to query this information in the spec, so that extensions do not start using non-portable assumptions.
"In OWB we manage the different BeanManager instances on a ContextClassLoader base by default (can be changed via SPI) So all classes accessed in the same WebApp get the same ClassLoader."
Remember that CDI must address many different deployment structures, of which a War with libraries is just one.
"Also: Extensions must not assume a certain classloader or BeanManager hierarchy for being portable - because there is no such thing defined in the spec (neither in CDI nor in EE umbrella)."
Exactly. However it is often useful to be able to query what beans are installed in another bean archive, for example in the issue I linked. Let's take another example. 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, however it might wish to query the beans installed into bean archive which is applicable for the WAR.
So in conclusion, it's not a "problem of the spec" but rather a problem that extensions encounter and therefore need the specification to provide some abstraction so that this information can be retrieved in a portable fashion.
> 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
13 years
[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:
------------------------------
This has been one of the biggest complaints I have heard about the CDI spec so far (actually Mark, you're the only person I've heard so far say we shouldn't make this a single call).
A couple of specific comments:
* BM is primarily intended as an SPI for providing access to CDI in unmanaged instances, so if we need to add better support for providing injection in unmanaged instances (see above) then BM is the right place to do it.
* instance() is indeed sufficient as Instance() allows fluent selection anyway.
Anyone else have an opinion on this?
> 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
13 years
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Aslak Knutsen commented on CDI-4:
---------------------------------
In Arquillian Core we had the same issue.
Previously multiple Observers were observing the BeforeClass, and the ordered mattered:
- ContextCreator (sets up the context so the TestClass can be found)
-- Listen to BeforeClass
- DeploymentGenerator (use the TestClass to generate the Archive)
-- Listen to BeforeClass
- ArchiveExporter (Export the Archive)
-- Listen to BeforeClass
- Deployer (Deploy the Archive)
-- Listen to BeforeClass
>From my perspective, if Order matters, they have a coupling so why not show it directly.
Two features were added to help with this:
- Event interceptor
If you need to setup/process a event indirectly, e.g. setup some evn, then you can Intercept the event in a AroundInvoke style interceptor. You can then Observe EventContext<BeforeClass>, setup your 'stuff' and continue the chain with event.proceed() to invoke the next Interceptors or Observers.
- Nested Events
Instead of all coupled Observers, based on order, being registered on the same Event, use 'sub events' to limit the scope and show the coupling. DeploymentGenerator fires a DeploymentGenerated event, Deployer fires BeforeDeploy and AfterDeploy events etc.
The new observer chain then becomes:
- ContextCreator
-- Listen to EventContext<BeforeClass> - Around Invoke interceptor of the whole Event
- DeploymentGenerator
-- Listen to BeforeClass -> fire DeploymentGenerated
- Deployer
-- Listen to DeploymentGenerated -> fire BeforeDeploy & AfterDeploy
- ArchiveExporter
-- Listen to BeforeDeploy
This has the added bonus that 'others' can reuse some of the chains logic by firing more concrete events, e.g. Trigger only a deployment by firing a DeploymentGenerated event instead of having the other side effects of the more coarse grained BeforeClass event.
Just wanted to throw the idea of Intercepting a Event and not the Observer out there, just my 2 cents.
> 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
13 years
[JBoss JIRA] Issue Comment Edited: (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 edited comment on CDI-4 at 5/8/11 5:10 PM:
--------------------------------------------------------
bq. 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.
Yeah, that is one of the side effects of this idea.
Seems two issues we're be dealing with are
# adding to the signature of the observer, possibly making it harder to read with other annotations
# externalizing ordering and not having any idea about ordering simply by looking at an observer.
With a comparator, you could do what you wanted with the extra annotations, they simply wouldn't be qualifying annotations, you could do the ordering in the comparator based on those. Another option I just thought of (which is similar to the comparator idea) is to make handling observers pluggable. Call it an EventingBus or something, it would be another SPI that people could tie into and have (full ?) control over how eventing happens, ordering, injection points, etc. This idea would allow us to do what we wanted in Seam JMS (not sure if this has come up in CODI) where we need the metadata of the event that was fired. It would be more work for the end user should they decide to take it, but it really gives them control over the application, and the environment should they need it.
Sorry for the first post which wasn't complete, Save and preview were a little too close :)
was (Author: lightguard):
bq. 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.
Yeah, that is one of the side effects of this idea. Seems the two issues we'll be dealing with are
1. ao
> 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
13 years
[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:
--------------------------------
bq. 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.
Yeah, that is one of the side effects of this idea. Seems the two issues we'll be dealing with are
1. ao
> 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
13 years
[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:
------------------------------
_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.
> 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
13 years
[JBoss JIRA] Issue Comment Edited: (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 edited comment on CDI-4 at 5/8/11 4:05 PM:
---------------------------------------------------------
> 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...
*edit*: ah I see now, your @After and @Before references a qualifier and not the other obserer class. Well then there might be no direct coupling, but this most probably wont work with the currently defined qualifier pattern (depending how we fix CDI-7).
> 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?
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.
was (Author: struberg):
> 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
13 years