-
Feature Request
-
Resolution: Done
-
Major
-
1.0
-
None
- blocks
-
-
- Resolved
-
[CDI-99] Obtain Extension instances from BeanManager
Pete Muir (Inactive)
added a comment - Marking as done, as we don't know why it was reopened. 
Mark Struberg (Inactive)
added a comment - But it's not defined how many BeanManagers there are for a single (Web/Enterprise) Application...
Think about hierarchic BeanManagers and stuff...
Mark Struberg (Inactive)
added a comment - But it's not defined how many BeanManagers there are for a single (Web/Enterprise) Application...
Think about hierarchic BeanManagers and stuff... Pete Muir (Inactive)
added a comment - Jozef, how can this be ambiguous? There is one extension per extension class.
Pete Muir (Inactive)
added a comment - Jozef, how can this be ambiguous? There is one extension per extension class. Mark Struberg (Inactive)
added a comment - Yes, I like injection at boot time much better than adding methods to the BeanManager for each and everything. Also this is easily implementable for CDI-1.0 containers already.
Actually it's more a clarification, because Extensions are defined as @ApplicationScoped already. So I would not be surprised to see this running out-of-the-box with the current Weld and OWB versions...
Mark Struberg (Inactive)
added a comment - Yes, I like injection at boot time much better than adding methods to the BeanManager for each and everything. Also this is easily implementable for CDI-1 .0 containers already.
Actually it's more a clarification, because Extensions are defined as @ApplicationScoped already. So I would not be surprised to see this running out-of-the-box with the current Weld and OWB versions... Pete Muir (Inactive)
added a comment - It's currently possible to inject extensions at runtime, we can't remove that behavior without breaking backwards compat.
We could look at making them injectable into extensions at boot time if you think it's a better api?
Pete Muir (Inactive)
added a comment - It's currently possible to inject extensions at runtime, we can't remove that behavior without breaking backwards compat.
We could look at making them injectable into extensions at boot time if you think it's a better api? Mark Struberg (Inactive)
added a comment - I'm a bit reluctant to giving end users full access to container Extensions. That might well cause security issues maybe (we have to think about that).
So I got made aware that Extensions are already defined as being @ApplictionScoped. Thus everyone can inject and use them already. The only reason which speaks against doing this so atm is because the application context is only guaranteed to exist once the container is fully started.
But we provide this already for injecting BeanManager, etc. We really should enumerate which things can get injected while booting.
Maybe those Extension beans shall get remove after the container has been started?
Mark Struberg (Inactive)
added a comment - I'm a bit reluctant to giving end users full access to container Extensions. That might well cause security issues maybe (we have to think about that).
So I got made aware that Extensions are already defined as being @ApplictionScoped. Thus everyone can inject and use them already. The only reason which speaks against doing this so atm is because the application context is only guaranteed to exist once the container is fully started.
But we provide this already for injecting BeanManager, etc. We really should enumerate which things can get injected while booting.
Maybe those Extension beans shall get remove after the container has been started? Pete Muir (Inactive)
added a comment - Mark, good idea, but I'm not sure how it addresses your previous comments...
Pete Muir (Inactive)
added a comment - Mark, good idea, but I'm not sure how it addresses your previous comments... Mark Struberg (Inactive)
added a comment - while chatting with jozef and ales, we had the following idea:
What about just allowing to inject Extensions at bootup (as we already do with BeanManager)?
public doThaTrick(@Observes BeforeBeanDiscovery bbd, MyOtherExtension otherExtension)
{...};or even:
public doThaTrick(@Observes BeforeBeanDiscovery bbd, Instance<Extension> allExtensions) {...}
;
We would need to clarify 6.7.3 that Extensions, BeanManager, Event, ...(what else being @ApplicationScoped and available at bootup?) must be available for injection into SystemEvent methods.
Mark Struberg (Inactive)
added a comment - while chatting with jozef and ales, we had the following idea:
What about just allowing to inject Extensions at bootup (as we already do with BeanManager)?
public doThaTrick(@Observes BeforeBeanDiscovery bbd, MyOtherExtension otherExtension)
{...};
or even:
public doThaTrick(@Observes BeforeBeanDiscovery bbd, Instance<Extension> allExtensions) {...}
;
We would need to clarify 6.7.3 that Extensions, BeanManager, Event, ...(what else being @ApplicationScoped and available at bootup?) must be available for injection into SystemEvent methods. Mark Struberg (Inactive)
added a comment - Don't we fear about security issues? Giving an end-user access to all runtime Extensions might be a bit too much...
Mark Struberg (Inactive)
added a comment - Don't we fear about security issues? Giving an end-user access to all runtime Extensions might be a bit too much... The spec covers what happens if there is no instance for a given class but the result may as well be ambiguous. Should we specify what happens in that case?
Pete Muir (Inactive)
added a comment - Gavin already added this, added to API. 
Closing all resolved issues in CDI 1.x