[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 commented on CDI-411:
------------------------------------------
Do you have a suggestion to were we could put this remark in the spec?
> 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
> 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, 9 months
[JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-411:
-------------------------------------
I think that we should not go into details in the spec and only say that the implementation must read the request parameter in a way that does not prevent filters/servlets from setting request encoding / parsing the body themselves.
> 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
> 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, 9 months
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Joe Bergmark (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Joe Bergmark commented on CDI-408:
----------------------------------
I also vote Option 3.
> 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
> Assignee: Antoine Sabot-Durand
> 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, 9 months
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Jason Greene commented on CDI-408:
----------------------------------
I should clarify that my preference for Option 1 was only because I didn't like the other two options. 2 logs a warning that should already be generally known (and could be too verbose). 3 encourages "all". To be clear, I would also go for a different option (4): Tell the user to put a defining annotation on the class if they want it picked up.
> 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
> Assignee: Antoine Sabot-Durand
> 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, 9 months
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Joseph Snyder (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Joseph Snyder commented on CDI-408:
-----------------------------------
Option 3 for me. Unless the likelihood of having an app with @Produces/@Observes but no other bean-defining annotationa is high. If that is the case then option 1 makes more sense to me.
> 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
> Assignee: Antoine Sabot-Durand
> 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, 9 months
[JBoss JIRA] (CDI-381) Additional implementations of Request Context
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-381?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-381:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Additional implementations of Request Context
> ---------------------------------------------
>
> Key: CDI-381
> URL: https://issues.jboss.org/browse/CDI-381
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_api_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that? The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes. It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.
--
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, 9 months
[JBoss JIRA] (CDI-380) Clarify SessionScoped
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-380?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-380:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Clarify SessionScoped
> ---------------------
>
> Key: CDI-380
> URL: https://issues.jboss.org/browse/CDI-380
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The javadocs say:
> The request context is destroyed:
> - at the end of the servlet request, after the service() method, all
> doFilter() methods, and all requestDestroyed() and onComplete()
> notifications return,
> ...
> The session context is destroyed when the HTTPSession times out, after all
> HttpSessionListeners have been called, and at the very end of any request in
> which invalidate() was called, after all filters and ServletRequestListeners
> have been called.
> Those definitions are different.
> The session context rule seems to be a combination of "or" items that
> include some "and" items. It's difficult to parse. It would be clearer
> if it was written as a list. And, like request scoped, it would be clearer
> if it described when the session scope/context is created.
--
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, 9 months
Tonight's meeting
by Antoine Sabot-Durand
Hi all,
The end of the MR is getting closer and we still have 12 tickets open (20 tickets resolved so far). You can still pick easy tickets in this list [1]
In today’s meeting I think we should talk about the list of « Not Ready to fix issues » [2] (issues that require discussion or analysis). More specifically
CDI-408 (@Observes and @Produces as bean defining annotation). The RTFM option is the chosen one, but do we had something to the spec ?
CDI-280 (Bean term clarification). To officially decide its removal from the MR like Jozef, Martin and I asked.
CDi-411 an important issue with no input since the beginning of the MR
I’d like also to come back on the inconsistency in Event behavior regarding @Any discovered during CDI-422. I really think we should at least add a mention and correct example in the spec.
If you have other tickets of importance please answer to this mail so everybody will be able to prepare the meeting.
Regards,
Antoine
[1] : https://issues.jboss.org/issues/?filter=12320805
[2] : https://issues.jboss.org/issues/?filter=12321017
10 years, 9 months
[JBoss JIRA] (CDI-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-331:
-------------------------------------
Labels: CDI_spec_chge CDI_tck_chge (was: )
> Instance.iterator() shouldn't include non-alternatives that haven't been replaced
> ---------------------------------------------------------------------------------
>
> Key: CDI-331
> URL: https://issues.jboss.org/browse/CDI-331
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.1.PRD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Labels: CDI_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> The specification currently says that:
> {quote}
> The iterator() method must:
> • Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into
> which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1.
> {quote}
> The ambiguity resolution algorithm as defined in 5.2.2 should be applied.
> This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency:
> Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative.
> Assume further the following
> {noformat}
> @Inject @Any Instance<Common> instance
> {noformat}
> injection point.
> It is clear that instance.get() returns Bar.
> It is however not clear whether instance.iterator() iterates over:
> a) Bar
> b) Foo, Bar
> and whether instance.isAmbiguous() returns:
> a) true
> b) false
--
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, 9 months