[JBoss JIRA] (CDI-615) provide API to register new beans to the context after deployment (at runtime)
by Samba Siva Rao Kolusu (JIRA)
[ https://issues.jboss.org/browse/CDI-615?page=com.atlassian.jira.plugin.sy... ]
Samba Siva Rao Kolusu updated CDI-615:
--------------------------------------
Description:
# CDI provides API to listen/observe for various stages of bean discovery and deployment, during which we can add additional types to be registered as managed CDI beans/interceptors/etc. however, there is no way to do the same (i.e.) register new types as CDI managed beans/interceptors/etc once the application is deployed (i.e. during runtime).
it would be very useful if the spec is enhanced to also provide a runtime API to register new types as Beans or Interceptors.
this is what we do currently:
{code:java}
public void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event, BeanManager beanManager) {
this.bm=beanManager;
Set<Class<?>> klasses=get classes from from some non-jee-classpath
AnnotatedType<?> annotatedType;
for(Class<?> klass : klasses ) {
annotatedType = bm.createAnnotatedType(klass);
_*event.addAnnotatedType(annotatedType,klass.getName());*_
}
}
{code}
something like the following will be of great use:
{code:java}
@Inject BeanManager bm;
AnnotatedType<?> annotatedType = bm.createAnnotatedType(klass);
_*bm.addAnnotatedType(annotatedType,klass.getName());*_
{code}
this simple API will help discover beans after deployment or from non-jee classpaths.
was:
CDI provides API to listen/observe for various stages of bean discovery and deployment, during which we can add additional types to be registered as managed CDI beans/interceptors/etc. however, there is no way to do the same (i.e.) register new types as CDI managed beans/interceptors/etc once the application is deployed (i.e. during runtime).
it would be very useful if the spec is enhanced to also provide a runtime API to register new types as Beans or Interceptors.
this is what we do currently:
{code:java}
public void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event, BeanManager beanManager) {
this.bm=beanManager;
Set<Class<?>> klasses=get classes from from some non-jee-classpath
AnnotatedType<?> annotatedType;
for(Class<?> klass : klasses ) {
annotatedType = bm.createAnnotatedType(klass);
_*event.addAnnotatedType(annotatedType,klass.getName());*_
}
}
{code}
something like the following will be of great use:
{code:java}
@Inject BeanManager bm;
AnnotatedType<?> annotatedType = bm.createAnnotatedType(klass);
_*bm.addAnnotatedType(annotatedType,klass.getName());*_
{code}
this simple API will help discover beans after deployment or from non-jee classpaths.
> provide API to register new beans to the context after deployment (at runtime)
> ------------------------------------------------------------------------------
>
> Key: CDI-615
> URL: https://issues.jboss.org/browse/CDI-615
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Environment: N/A
> Reporter: Samba Siva Rao Kolusu
>
> # CDI provides API to listen/observe for various stages of bean discovery and deployment, during which we can add additional types to be registered as managed CDI beans/interceptors/etc. however, there is no way to do the same (i.e.) register new types as CDI managed beans/interceptors/etc once the application is deployed (i.e. during runtime).
> it would be very useful if the spec is enhanced to also provide a runtime API to register new types as Beans or Interceptors.
> this is what we do currently:
> {code:java}
> public void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event, BeanManager beanManager) {
> this.bm=beanManager;
> Set<Class<?>> klasses=get classes from from some non-jee-classpath
> AnnotatedType<?> annotatedType;
> for(Class<?> klass : klasses ) {
> annotatedType = bm.createAnnotatedType(klass);
> _*event.addAnnotatedType(annotatedType,klass.getName());*_
> }
> }
> {code}
> something like the following will be of great use:
> {code:java}
> @Inject BeanManager bm;
> AnnotatedType<?> annotatedType = bm.createAnnotatedType(klass);
> _*bm.addAnnotatedType(annotatedType,klass.getName());*_
> {code}
> this simple API will help discover beans after deployment or from non-jee classpaths.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-615) provide API to register new beans to the context after deployment (at runtime)
by Samba Siva Rao Kolusu (JIRA)
Samba Siva Rao Kolusu created CDI-615:
-----------------------------------------
Summary: provide API to register new beans to the context after deployment (at runtime)
Key: CDI-615
URL: https://issues.jboss.org/browse/CDI-615
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Beans
Affects Versions: 1.2.Final
Environment: N/A
Reporter: Samba Siva Rao Kolusu
CDI provides API to listen/observe for various stages of bean discovery and deployment, during which we can add additional types to be registered as managed CDI beans/interceptors/etc. however, there is no way to do the same (i.e.) register new types as CDI managed beans/interceptors/etc once the application is deployed (i.e. during runtime).
it would be very useful if the spec is enhanced to also provide a runtime API to register new types as Beans or Interceptors.
this is what we do currently:
{code:java}
public void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event, BeanManager beanManager) {
this.bm=beanManager;
Set<Class<?>> klasses=get classes from from some non-jee-classpath
AnnotatedType<?> annotatedType;
for(Class<?> klass : klasses ) {
annotatedType = bm.createAnnotatedType(klass);
_*event.addAnnotatedType(annotatedType,klass.getName());*_
}
}
{code}
something like the following will be of great use:
{code:java}
@Inject BeanManager bm;
AnnotatedType<?> annotatedType = bm.createAnnotatedType(klass);
_*bm.addAnnotatedType(annotatedType,klass.getName());*_
{code}
this simple API will help discover beans after deployment or from non-jee classpaths.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-420 at 6/7/16 8:34 AM:
----------------------------------------------------------
Hm, what about making it more generic? E.g. something like introducing "exclude filters" for Bean discovery:
{code:xml}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<!-- These filters are applied before type discovery -->
<scan>
<exclude name="com.acme.rest.*" />
</scan>
<!-- These filters are applied before bean discovery -->
<process>
<!-- Name is matched against javax.enterprise.inject.spi.AnnotatedType.getJavaClass().getName() -->
<!-- "*" means any AnnotatedType -->
<exclude name="*">
<if-no-bean-defining-annotation />
</exclude>
</process>
</beans>
{code}
was (Author: mkouba):
Hm, what about making it more generic? E.g. something like introducing "exclude filters" for Bean discovery:
{code:xml}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<!-- These filters are applied before type discovery -->
<scan>
<exclude name="com.acme.rest.*" />
</scan>
<!-- These filters are applied before bean discovery -->
<process>
<exclude name="*">
<if-no-bean-defining-annotation />
</exclude>
</process>
</beans>
{code}
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-420:
------------------------------------------
+1 for Martin approach.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-420 at 6/7/16 8:24 AM:
----------------------------------------------------------
Hm, what about making it more generic? E.g. something like introducing "exclude filters" for Bean discovery:
{code:xml}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<!-- These filters are applied before type discovery -->
<scan>
<exclude name="com.acme.rest.*" />
</scan>
<!-- These filters are applied before bean discovery -->
<process>
<exclude name="*">
<if-no-bean-defining-annotation />
</exclude>
</process>
</beans>
{code}
was (Author: mkouba):
Hm, what about making it more generic? E.g. something like introducing "exclude filters" for Bean discovery:
{code:xml}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<!-- These filters are applied during type discovery -->
<scan>
<exclude name="com.acme.rest.*" />
</scan>
<!-- These filters are applied during bean discovery -->
<process>
<exclude name="*">
<if-no-bean-defining-annotation />
</exclude>
</process>
</beans>
{code}
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-420:
-----------------------------------
While I still feel that addressing this with an Extension would be sufficient, I have to say that Martin's solution is pretty elegant.
I doesn't add any new complexity to bean discovery modes as you keep using current ones and it works on a familiar exclusion basis.
Plus, as was pointed out to me, it can be done on a per-archive basis compared to extension which would be global.
To sum it up - +1 for this solution.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-614) Review all read methods at configurators
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-614?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-614:
-----------------------------------
bq. all those injection point-related methods on {{BeanConfigurator}} are disputable as well
+1 for that. I mentioned it somewhere already; you can set an injection point with {{BeanConfigurator}} but you cannot achieve the injection itself.
And to share my opinion on read methods:
As for {{read}} methods on {{BeanConfigurator}}, I would say those are fine. Are won't bounce into ClassCastException there and it might prove handy to read a bean you already have and with that basis you build a new one.
Furthermore, amongst {{ObserverMethodConfigurator#read*}} I really dislike {{read(javax.enterprise.inject.spi.ObserverMethod<T>)}}. +1 for removing this. Others can still be used IMHO as they are not susceptible to ClassCastExceptions and easy to use.
Last but not least {{InjectionPointConfigurator#read}}. Those seems pretty useless. I understand read methods when you need to create something from the scratch, but when you are simply adjusting it, it doesn't make much sense.
> Review all read methods at configurators
> ----------------------------------------
>
> Key: CDI-614
> URL: https://issues.jboss.org/browse/CDI-614
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
>
> Currently there are several read methods used to initialize given configurator. These methods are at:
> * {{BeanConfigurator}}
> * {{InjectionPointConfigurator}}
> * {{ObserverMethodConfigurator}}
> I think we should review all of them. I don't understand to usage or let say additional value of the following ones:
> * {{ObserverMethodConfigurator#read(javax.enterprise.inject.spi.ObserverMethod<T>)}}
> This allows you to add new observer method based on exsiting one. Although when you want to define some observed type (of this new method) you need to specify subtype of the original type or you will end up with ClassCastException.
> Then there are those at {{InjectionPointConfigurator}} which appears to me completely useless:
> * {{InjectionPointConfigurator#read(java.lang.reflect.Field)}}
> * {{InjectionPointConfigurator#read(java.lang.reflect.Parameter)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedField<?>)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedParameter<?>)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.InjectionPoint)}}
> AFAIK the {{InjectionPointConfigurator}} is available only during {{ProcessInjectionPoint}} lifecycle event. My question is why should I use any of these during this lifecycle event since I can easily call {{event.configureInjectionPoint()}}? Do we want to allow to configure different injection point in non corresponding {{ProcessInjectionPoint}} lifecycle event?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (CDI-614) Review all read methods at configurators
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-614?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-614:
----------------------------------
bq. AFAIK the InjectionPointConfigurator is available only during ProcessInjectionPoint lifecycle event.
Yes, it is. We've discussed the possibilities to use the {{InjectionPointConfigurator}} within {{BeanConfigurator}}, but in fact, all those injection point-related methods on {{BeanConfigurator}} are disputable as well (note that {{Bean.getInjectionPoints()}} is only used for validation, not for injection).
> Review all read methods at configurators
> ----------------------------------------
>
> Key: CDI-614
> URL: https://issues.jboss.org/browse/CDI-614
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
>
> Currently there are several read methods used to initialize given configurator. These methods are at:
> * {{BeanConfigurator}}
> * {{InjectionPointConfigurator}}
> * {{ObserverMethodConfigurator}}
> I think we should review all of them. I don't understand to usage or let say additional value of the following ones:
> * {{ObserverMethodConfigurator#read(javax.enterprise.inject.spi.ObserverMethod<T>)}}
> This allows you to add new observer method based on exsiting one. Although when you want to define some observed type (of this new method) you need to specify subtype of the original type or you will end up with ClassCastException.
> Then there are those at {{InjectionPointConfigurator}} which appears to me completely useless:
> * {{InjectionPointConfigurator#read(java.lang.reflect.Field)}}
> * {{InjectionPointConfigurator#read(java.lang.reflect.Parameter)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedField<?>)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedParameter<?>)}}
> * {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.InjectionPoint)}}
> AFAIK the {{InjectionPointConfigurator}} is available only during {{ProcessInjectionPoint}} lifecycle event. My question is why should I use any of these during this lifecycle event since I can easily call {{event.configureInjectionPoint()}}? Do we want to allow to configure different injection point in non corresponding {{ProcessInjectionPoint}} lifecycle event?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
configurators and read methods
by Tomas Remes
Hi EG!
Recently I created https://issues.jboss.org/browse/CDI-614 and would like to ask you to review and share your opinion on this. I wanted to finish TCK tests for InjectionPointConfigurator but I realized that I don't understand the purpose of its read methods at all.:-) There are few other read methods on different configurators and I think we should think about them whether they are really useful or not. I personally don't like this approach as I stated in comment in related CDI-609.
Thank's a lot
--
Tomas Remes
8 years, 9 months
[JBoss JIRA] (CDI-614) Review all read methods at configurators
by Tomas Remes (JIRA)
Tomas Remes created CDI-614:
-------------------------------
Summary: Review all read methods at configurators
Key: CDI-614
URL: https://issues.jboss.org/browse/CDI-614
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 2.0-EDR2
Reporter: Tomas Remes
Currently there are several read methods used to initialize given configurator. These methods are at:
* {{BeanConfigurator}}
* {{InjectionPointConfigurator}}
* {{ObserverMethodConfigurator}}
I think we should review all of them. I don't understand to usage or let say additional value of the following ones:
* {{ObserverMethodConfigurator#read(javax.enterprise.inject.spi.ObserverMethod<T>)}}
This allows you to add new observer method based on exsiting one. Although when you want to define some observed type (of this new method) you need to specify subtype of the original type or you will end up with ClassCastException.
Then there are those at {{InjectionPointConfigurator}} which appears to me completely useless:
* {{InjectionPointConfigurator#read(java.lang.reflect.Field)}}
* {{InjectionPointConfigurator#read(java.lang.reflect.Parameter)}}
* {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedField<?>)}}
* {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.AnnotatedParameter<?>)}}
* {{InjectionPointConfigurator#read(javax.enterprise.inject.spi.InjectionPoint)}}
AFAIK the {{InjectionPointConfigurator}} is available only during {{ProcessInjectionPoint}} lifecycle event. My question is why should I use any of these during this lifecycle event since I can easily call {{event.configureInjectionPoint()}}? Do we want to allow to configure different injection point in non corresponding {{ProcessInjectionPoint}} lifecycle event?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
