9:16 a.m.
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or listener
is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:23 p.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-206:
-------------------------------
Lincoln says
{quote}
It sounds like you have two options
1. Let the exceptions go un-handleable.
2. Defer the exception to some other point in the lifecycle (either a Filter or a Servlet)
that would allow users to catch them more easily.
{quote}
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:25 p.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Lincoln Baxter III commented on CDI-206:
----------------------------------------
It sounds like this issue needs to be raised with the Servlet 3.1 Spec - to extend the
Exception handling functionality to the entire container, not just for Servlets, Filters,
and certain Listeners.
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:05 p.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-206:
-------------------------------
I've asked the Servlet spec leads to review it and provide their comments.
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:04 a.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-206:
----------------------------------
Alternatively we could use servlet filter to associate/dissociate contexts (like Seam2
did). Or is there any architectural/performance/etc. rationale behind using listeners?
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
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
8:42 a.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-206:
-------------------------------
It would be nice to allow people to access the conversation in the filter. This means that
filters need ordering, which is hard to specify, as servlet doesn't have relative
ordering.
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
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
8:50 a.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Stuart Douglas commented on CDI-206:
------------------------------------
Servlet does specify an ordering for filters, based on the location of
<filter-mappings> in web.xml (with various other rules based on building the
effective web.xml from fragments) (Servlet 6.2.4).
We could potentially add a filter with a well defined name ("CDI Conversation
Filter"), which would give the user the opportunity to add a filter mapping anywhere
they want in web.xml.
If they did not add a mapping we could specify that it executes first (i.e. around every
filter). We would probably also have to disallow mappings for anything other than
"/*".
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
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
8:55 a.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-206:
-------------------------------
That is a major mess :-p
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
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:34 a.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-206:
-------------------------------
We'll go with Stuart's proposal unless anyone objects.
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
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
11:13 a.m.
[
https://issues.jboss.org/browse/CDI-206?page=com.atlassian.jira.plugin.sy...
]
Lincoln Baxter III commented on CDI-206:
----------------------------------------
Perfect. I think that's the best solution. I assume this filter would also handle
conversation context functionality as well as exceptions?
Conversation related exceptions cannot be handled
-------------------------------------------------
Key: CDI-206
URL: https://issues.jboss.org/browse/CDI-206
Project: CDI Specification Issues
Issue Type: Bug
Components: Contexts
Affects Versions: 1.1.EDR
Reporter: Jozef Hartinger
Fix For: 1.1 (Proposed)
This issue emerged after adding support for conversations as part of CDI-80
The spec says:
{quote}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}
If the propagated conversation cannot be restored, the container must associate the
request with a new transient conversation and throw an exception of type
javax.enterprise.context.NonexistentConversationException.
The container ensures that a long-running conversation may be associated with at most one
request at a time, by blocking
or rejecting concurrent requests. If the container rejects a request, it must associate
the request with a new transient conversation and throw an exception of type
javax.enterprise.context.BusyConversationException.
{quote}
The conversation association is supposed to be done before any servlet, filter or
listener is invoked. If the association fails (due to NonexistentConversationException or
BusyConversationException), the application has no way of handling this failure
gracefully. The Servlet error-page mechanism cannot be used portably because it is only
handling uncaught exceptions thrown from a servlet / filter. Similarly, a commonly used
exception handling mechanism - an outer filter that catches every uncaught exception,
cannot be used since the association failure does not occur within the filter invocation.
--
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
4427
days inactive
4745
days old
9 comments
5 participants
participants (5)
-
Jozef Hartinger (Created) (JIRA) -
Lincoln Baxter III (JIRA)
-
Martin Kouba (JIRA)
-
Pete Muir (JIRA)
-
Stuart Douglas (JIRA)