[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/17/14 11:18 AM:
--------------------------------------------------------------------
To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as beans. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any CDI Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
was (Author: antoinesabot-durand):
To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as beans. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
> 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, 10 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/17/14 11:17 AM:
--------------------------------------------------------------------
To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as beans. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
was (Author: antoinesabot-durand):
To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
> 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, 10 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/17/14 11:16 AM:
--------------------------------------------------------------------
To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
was (Author: antoinesabot-durand):
To sum up regarding {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
> 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, 10 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:
------------------------------------------
To sum up regarding {{@Singleton}} and other {{@Scope}} management, we have 3 options.
# *Stop supporting them in CDI*
Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}})
# *Remove them from the list of bean defining annotations list*
So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together.
# *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation*
In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them.
> 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, 10 months
[JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-421:
----------------------------------------
Summary: Organize the project as a Maven project with modules
Key: CDI-421
URL: https://issues.jboss.org/browse/CDI-421
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Packaging and Deployment
Reporter: Antoine Sabot-Durand
Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script.
With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module.
--
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, 10 months
[JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-382:
----------------------------------
[~struberg], [~pmuir], [~arnelim] my final suggestion: *"Interceptor bindings declared on a producer method are not used to associate interceptors with the return value of the producer method."*.
The Interceptors spec. says:
bq. Interceptor bindings are intermediate annotations that may be used to associate interceptors with any component that is not itself an interceptor.
So I believe we should only clarify the purpose of the interceptor bindings declared on a producer.
> Clarify interceptors are not associated with the result of a producer method/field
> ----------------------------------------------------------------------------------
>
> Key: CDI-382
> URL: https://issues.jboss.org/browse/CDI-382
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec.
> [1] https://github.com/cdi-spec/cdi/pull/110
> "Interceptors are not associated with the return value of a producer method or the current value of a producer field."
--
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, 10 months