[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-377:
------------------------------------------
Good point Martin. I guess we need to also exclude all scopes annotated with {{(a)javax.inject.scope}} except {{@Dependent}} and keep all scopes annotated with {{@NormalScope}} in bean defining annotations list.
Again that doesn't mean we exclude these scope that means they cannot triggers implicit CDI for archive alone.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-377:
----------------------------------
What about other scope annotations annotated with {{javax.inject.Scope}}?
bq. Any scope type is a bean defining annotation.
E.g. if any DI framework built upon JSR 330 defines its own scope type it's a bean defining annotation according to CDI 1.1. Am I right?
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-377:
----------------------------------------
@Antoine: if we can't manage to exclude modules skipping @Singleton would be ok for me too (short term, it would handle majority of cases) but we need to handle it next time for sure
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-377:
------------------------------------------
[~petemuir] ok. I will investigate to make sure there are no side effect. Apparently some of us (like [~rmannibucau]) have warnings about it. We'll continue to discuss about this lead in the coming weeks before taking a final decision.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-377:
-------------------------------
If it is just @Singleton that causes the problem, then we should definitely exclude it. We really recommend people NOT to use it in CDI apps anyway...
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-408:
-----------------------------------
Please note that the following things also do not get discovered right now:
* Interfaces - this is often used by Extensions
* static Producer methods. Usually the Classes containing these producer methods do not have a CDI Scope...
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
> Key: CDI-408
> URL: https://issues.jboss.org/browse/CDI-408
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Reporter: Jens Schumann
> Labels: CDI_spec_chge
> Fix For: 1.2 Proposed
>
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>
> Btw: Which JIRA version is CDI 1.1 Final?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-377 at 2/14/14 3:40 AM:
-------------------------------------------------------------------
{quote}
You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it.
{quote}
I agree [~jharting]. We have to support all JSR-330 (including {{@singleton}}) but specify that {{@singleton}} *alone* cannot trigger implicit CDI discovery for the including archive.
{quote}
# Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is:
#* similar to your recent proposal
#* probably trickier to define nicely
#* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes)
{quote}
And saying that you forgot all CDI apps that are using {{@Singleton}} only but have explicit CDI activation thru {{beans.xml}} file. It makes the number of impacted apps very small.
was (Author: antoinesabot-durand):
{quote}
You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it.
{quote}
I agree [~jharting]. We have to support all JSR-330 (including {{@singleton}}) but specify that {{@singleton}} *alone* cannot trigger implicit CDI discovery for the present jars.
{quote}
# Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is:
#* similar to your recent proposal
#* probably trickier to define nicely
#* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes)
{quote}
And saying that you forgot all CDI apps that are using {{@Singleton}} only but have explicit CDI activation thru {{beans.xml}} file. It makes the number of impacted apps very small.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-377:
------------------------------------------
{quote}
You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it.
{quote}
I agree [~jharting]. We have to support all JSR-330 (including {{@singleton}}) but specify that {{@singleton}} *alone* cannot trigger implicit CDI discovery for the present jars.
{quote}
# Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is:
#* similar to your recent proposal
#* probably trickier to define nicely
#* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes)
{quote}
And saying that you forgot all CDI apps that are using {{@Singleton}} only but have explicit CDI activation thru {{beans.xml}} file. It makes the number of impacted apps very small.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-377:
-------------------------------------
{quote}1. no-beans.xml wouldn't work since when you dev for a servlet container you don't care then when you are deployd in a EE containet you don't want to repackage.{quote}
Right, this would be helpful only if the library authors care. This may not be the entire solution of the problem but may be part of it. The important point here is that even if we get rid of @Singleton support, there would still be no portable way (across CDI 1.0, 1.1 and 1.2) of saying that this archive with CDI scopes is not intended to be a bean archive (i.e. bean-discovery-mode="none").
{quote}2. would mean you can't write cdi code with @Singleton (so excluding it would be better) and makes understanding of issues harder{quote}
You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it.
{quote}Maybe we could veto a module (abstraction for jar, classes dir ...) before scanning it?{quote}
To me this sounds way out of scope for a maintenance release.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-377:
----------------------------------------
1. no-beans.xml wouldn't work since when you dev for a servlet container you don't care then when you are deployd in a EE containet you don't want to repackage.
2. would mean you can't write cdi code with @Singleton (so excluding it would be better) and makes understanding of issues harder
Maybe we could veto a module (abstraction for jar, classes dir ...) before scanning it?
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months