[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
[~manovotn] sorry, we overlapped when editing.
Yes, "all" (or the implicit CDI-1.0 mode) was really intentional. When using "annotated" you don't even get that far. Interfaces and non-annotated classes will not even make it to ProcessAnnotatedType. Thus there is nothing to exclude - because they don't even get processed ;)
> 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, 6 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
I fear it's confusing for the user.
Please remember that the whole ticket is mostly for fixing a behaviour which is imo broken since the very early days: to prevent automatically pick up all classes as @Dependent scoped beans, even if they have no single CDI annotation at all.
Those are in 99.9999% cases just pure waste in our memory.
Otoh we cannot enable this for all classes as there might be some jars which depend on it. Thus we need to activate this per classpath entry.
There was a first attempt to fix this behaviour with the bean-discovery-mode="anotated". And it didn't work out because of the aforementioned problems.
I thought about Martins proposal for two days now. It is certainly interesting but I don't yet see any benefit in having a second configurable exclude mechanism which exceeds this basic rules.
Are there any other use cases you have in mind? Because if the above reason is the only one then I find it overreaching.
> 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, 6 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:
-----------------------------------
[~emilyj] Use bean discovery mode {{all}} and add the exclude filter.
That means it will pick up even classes without bean defining annotation and fire PAT for them, yet if they are in the exclusion filter it won't pick them up as Beans.
> 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, 6 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 edited comment on CDI-420 at 6/8/16 1:20 AM:
-----------------------------------------------------------
[~emilyj] Use bean discovery mode {{all}} and add the exclusion filter.
That means it will pick up even classes without bean defining annotation and fire PAT for them, yet if they are in the exclusion filter it won't pick them up as Beans.
was (Author: manovotn):
[~emilyj] Use bean discovery mode {{all}} and add the exclude filter.
That means it will pick up even classes without bean defining annotation and fire PAT for them, yet if they are in the exclusion filter it won't pick them up as Beans.
> 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, 6 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-420:
---------------------------------
Martin, can you elaborate a bit more on how to achieve the requirement of processing all classes with the exclude filter?
> 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, 6 months
Canceling today's meeting
by Antoine Sabot-Durand
Hi all,
Unfortunately I have a kid emergency and won't be available for the meeting.
Antoine
8 years, 6 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 commented on CDI-420:
----------------------------------
[~emilyj] Not really, the point is to fire {{ProcessAnnotatedType}} even for classes which are not annotated with a bean defining annotation but do not register these classes as beans.
> 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, 6 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-420:
---------------------------------
I am a bit confused. I thought this discussion is to include some classes that are not beans in the implicit bean archives. In Martin's suggestion, it is to exclude classes. Do you mean "include" or I might have missed something?
> 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, 6 months
[JBoss JIRA] (CDI-615) provide API to register new beans to the context after deployment (at runtime)
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-615?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba resolved CDI-615.
------------------------------
Resolution: Duplicate Issue
> 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, 6 months
[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, 6 months
