[cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec
Jozef Hartinger (JIRA)
issues at jboss.org
Tue Mar 18 05:10:10 EDT 2014
[ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12953733#comment-12953733 ]
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:
> 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.
> The CDI specification says:
> 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.
> 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.
> 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
More information about the cdi-dev