[JBoss JIRA] (CDI-427) Review all annotations for inclusion to bean defining annotations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-427?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-427:
------------------------------------------
To be consistent with the decision that's been chosen in CDI-408, I think we should stick to what was decided in CDI-377, CDI-404 and 406 (Normal Scope type, Interceptor, Decorator and Stereotype). Anyway, here's my POV on class level annotation not in Bean defining annotation set.
* Qualifiers (built-in or user defined). As @Qualifier are defined in JSR 330, we shouldn't take them to avoid the same issue than in CDI-377
* @Alternative : could bring a lot of issue regarding if the bean this alternative replace has been detected as a bean. And since activating an alternative requiers using beans.xml, it's not very far to switch the bean-discovery-mode to all
* @Specialize : same remark about the specialized bean being considered as a bean
* @Typed : the only class level annotation that would be easily added to the set. But is it necessary ?
> Review all annotations for inclusion to bean defining annotations
> -----------------------------------------------------------------
>
> Key: CDI-427
> URL: https://issues.jboss.org/browse/CDI-427
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The CDI spec change, which adds @Interceptor, @Decorator and stereotypes to the set of bean defining annotations, was merged. This made me think whether this approach where we add annotations based on demand is the right one. Instead, I think we should review all the annotations defined in the CDI API and evaluate if it makes to have them as bean defining annotations. I think that this would yield more consistent and less ad-hoc result.
> Two candidates that come to mind are @Alternative and @Specializes.
> This issue depends on the resolution of CDI-408
--
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, 1 month
[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-411 started by Antoine Sabot-Durand.
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
> Key: CDI-411
> URL: https://issues.jboss.org/browse/CDI-411
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.
--
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, 1 month
[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-411:
-------------------------------------
Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix (was: CDI_spec_chge CDI_tck_chge)
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
> Key: CDI-411
> URL: https://issues.jboss.org/browse/CDI-411
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.
--
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, 1 month
[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-411:
----------------------------------------
Assignee: Antoine Sabot-Durand
> CDI conversation activation conflicts with the Servlet spec
> -----------------------------------------------------------
>
> Key: CDI-411
> URL: https://issues.jboss.org/browse/CDI-411
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.FD
> Reporter: Jozef Hartinger
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The Servlet specification says:
> {quote}
> If the client hasn't set character encoding and the request data is encoded with a
> different encoding than the default as described above, breakage can occur. To
> remedy this situation, a new method setCharacterEncoding(String enc) has been
> added to the ServletRequest interface. Developers can override the character
> encoding supplied by the container by calling this method. It must be called prior to
> parsing any post data or reading any input from the request. Calling this method
> once data has been read will not affect the encoding.
> {quote}
> The CDI specification says:
> {quote}
> The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the
> user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the
> application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any
> service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web
> application and before the container calls any ServletRequestListener or AsyncListener in the web application.
> {quote}
> and
> {quote}
> The long-running conversation associated with a request may be propagated to any Servlet request via use of a request
> parameter named cid containing the unique identifier of the conversation.
> {quote}
> This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding.
> This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion.
--
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, 1 month
[JBoss JIRA] (CDI-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-398:
------------------------------------------
https://github.com/cdi-spec/cdi/pull/223
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-398
> URL: https://issues.jboss.org/browse/CDI-398
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> • A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
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, 1 month
[JBoss JIRA] (CDI-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-398 started by Antoine Sabot-Durand.
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-398
> URL: https://issues.jboss.org/browse/CDI-398
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> • A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
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, 1 month
[JBoss JIRA] (CDI-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-398:
-------------------------------------
Assignee: Antoine Sabot-Durand
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-398
> URL: https://issues.jboss.org/browse/CDI-398
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> • A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
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, 1 month
[JBoss JIRA] (CDI-429) Consistency of all built-in normal scopes
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-429?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-429:
-------------------------------------
Labels: CDI_api_chge CDI_spec_chge Ready_to_fix (was: CDI_api_chge CDI_spec_chge reasd)
> Consistency of all built-in normal scopes
> -----------------------------------------
>
> Key: CDI-429
> URL: https://issues.jboss.org/browse/CDI-429
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Contexts
> Affects Versions: 1.1.Final
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> In CDI-381, we added comment to indicate that third party can use @Requestscoped to bind their own context.
> For consistency we should do the same for all Normal Scopes. And also check spec as well.
--
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, 1 month