3:22 p.m.
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way all
the info is available, including the exception being handled, the original exception and
the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:27 p.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-26) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SEAMCATCH-26?page=com.atlassian.jira.plug...
]
Jason Porter commented on SEAMCATCH-26:
---------------------------------------
We're talking about the first CaughtException we create?
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:57 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-26) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SEAMCATCH-26?page=com.atlassian.jira.plug...
]
Dan Allen commented on SEAMCATCH-26:
------------------------------------
(17:26:38) Jason: If we put the producer on the dispatcher, it won't be there when we
need the exception, will it?
(17:27:48) Dan: it should be, because the producer will be read on demand
(17:27:57) Dan: also, you can add @Typed() just like that to the producer
(17:28:01) Dan: so it is only an EL producer
(17:28:06) Dan: it has no java types
(17:28:35) Jason: What happens if someone tries to use it once the dispatcher finishes?
(17:28:57) Jason: I'm thinking this would have to be used inside a handler
(17:29:06) Jason: But that wouldn't work for things like the seam debug page
(17:29:10) Dan: right, just within the context of the handling
(17:29:18) Jason: because the dispatcher is already going to be done.
(17:29:29) Dan: yep, since the debug page should be included while the exception handling
is being done
(17:29:58) Dan: hmm, we may want to let it linger (at least the final one)
(17:30:04) Dan: the final CaughtException
(17:30:07) Jason: Yeah
(17:30:23) Dan: it's around until catch runs again (or the state is just out of
scope)
(17:30:29) Dan: in Seam 2 it was conversation scoped
(17:30:34) Dan: I think that would be up to an extension
(17:30:56) Dan: to scope it longer
..
(17:35:26) Jason: Maybe I'm just not understanding how to do it with producers.
(17:35:36) Dan: how long do you want it to stick around (max)
(17:35:36) Dan: ?
(17:35:49) Jason: I guess that depends on what you're doing with it.
(17:36:00) Jason: In the seam debug page example it could be a while.
(17:36:05) Jason: As long as they're on that page.
(17:36:07) Dan: let's just say conversation scoped
(17:36:16) Dan: so this would be it
(17:36:54) Dan: @ConversationScoped public class CaughtExceptionHolder { private
CaughtException caughtException;
(17:37:03) Dan: // setter
(17:37:26) Dan: @Produces @Named CaughtException getCaughtException() { return
caughtException; }
(17:37:30) Dan: }
(17:37:40) Jason: CaughtExceptionHolder*
(17:37:41) Jason: ?
(17:37:53) Jason: Oh, this is the same class?
(17:37:58) Dan: can be a different class
(17:38:03) Dan: even a package-protected class
(17:38:14) Dan: you are slicing out a plot of context
(17:38:46) Dan: now, we stuff it in there
(17:38:50) Dan: done
(17:38:59) Dan: @Inject CaughtExceptionHolder holder;
(17:39:07) Dan: holder.setCaughtException(caughtException);
(17:39:22) Dan: we could even do
(17:39:30) Dan: public class CaughtExceptionHolder { private CaughtException
caughtException;
(17:39:31) Dan: // setter
(17:39:43) Dan: @Produces @ConversationScoped @Unwraps @Named CaughtException
getCaughtException() { return caughtException; }
(17:39:45) Dan: :)
(17:40:25) Jason: Okay, that's all fine. Looks like basic producer stuff
(17:41:30) Jason: I guess the problem I'm having is what happens if some one @Injects
something that's depend scoped, but only there part of the time (like our current
exception)? You have to have an exception first otherwise you get an exception thrown?
(17:42:57) Dan: ah, it can inject a null value if it's dependent-scoped
(17:43:09) Dan: proxies can't return null
(17:43:33) Dan: so you can't call it w/o a value or you get an exception
(17:43:37) Jason: Okay, so we make it @ConversationScoped then they're screwed?
(17:43:49) Dan: I think we should make the holder conversation scoped
(17:43:53) Dan: producer dependent-scoped
(17:43:55) Dan: then we are okay
(17:47:15) Jason: The holder @Injects the CaughtException ?
(17:47:46) Dan: no, the dispatcher sets the value into the holder
(17:48:03) Jason: Okay so the dispatcher @Injects the holder?
(17:48:09) Dan: correct
(17:48:20) Jason: Okay, starting to understand a little better
(17:48:36) Jason: You have to play games with the scopes a bit
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:44 p.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-26) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SEAMCATCH-26?page=com.atlassian.jira.plug...
]
Jason Porter commented on SEAMCATCH-26:
---------------------------------------
Wondering if we need to make the CaughtException available (and at what point we do that,
it will change for each stack iteration) or if we just make the ExceptionStack available.
It should have every thing we need for org.jboss.seam.caughtException. Handled exception
we'd need to use each CaughtException if it's handled, not exactly sure if
that's what we want to do.
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:03 a.m.
New subject: [JBoss JIRA] Updated: (SEAMCATCH-26) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SEAMCATCH-26?page=com.atlassian.jira.plug...
]
Jason Porter updated SEAMCATCH-26:
----------------------------------
Fix Version/s: 3.0.0.Beta2
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:53 p.m.
New subject: [JBoss JIRA] Resolved: (SEAMCATCH-26) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SEAMCATCH-26?page=com.atlassian.jira.plug...
]
Jason Porter resolved SEAMCATCH-26.
-----------------------------------
Resolution: Done
Fixed in 6bad0a0
Make caught exception available as named bean
---------------------------------------------
Key: SEAMCATCH-26
URL: https://issues.jboss.org/browse/SEAMCATCH-26
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 a.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Bernard Labno commented on SOLDER-153:
--------------------------------------
My "/error" is a facelet showing #{handledException}. If I hit
"/error" page directly I get
org.jboss.weld.exceptions.IllegalProductException: WELD-000052 Cannot return null from a
non-dependent producer method: [method] @Produces @ConversationScoped @Named public
org.jboss.solder.exception.control.ExceptionHandlerDispatch.getExceptionToCatch()
at
org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:217)
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:300)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107)
at
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
at
org.jboss.solder.exception.control.ExceptionToCatch$Proxy$_$$_WeldClientProxy.toString(ExceptionToCatch$Proxy$_$$_WeldClientProxy.java)
at org.apache.el.lang.ELSupport.coerceToString(ELSupport.java:413)
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:443)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:224)
at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:148)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at
com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at
com.ocpsoft.pretty.faces.application.PrettyViewHandler.renderView(PrettyViewHandler.java:163)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:118)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:734)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:541)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:479)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:407)
at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:110)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:397)
at
org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
at java.lang.Thread.run(Thread.java:662)
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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
8:19 a.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Jason Porter commented on SOLDER-153:
-------------------------------------
For as long as it's been in there, you seem to be the first person who has used this.
Got a patch / pull request?
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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:21 p.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Bernard Labno commented on SOLDER-153:
--------------------------------------
Pull request: https://github.com/seam/solder/pull/74
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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
9:39 a.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Bernard Labno commented on SOLDER-153:
--------------------------------------
Jason, sorry, but this issue is not finished.
Take a look at Phase.java:
try {
handleAfterPhase(context, listeners, event);
} catch (Throwable e) {
queueException(context, e);
}
// stop timing
if (timer != null) {
timer.stopTiming();
timer.logResult(
"Execution time for phase (including any PhaseListeners) ->
"
+ this.getId().toString());
}
context.getExceptionHandler().handle();
Well, the conversation context will be ended on handleAfterPhase and
ExceptionHandlerDispatch.executeHandlers will be called on
context.getExceptionHandler().handle();
So I can't have the ExceptionHandlerDispatch moved to Conversation scope (even with
beans.xml modifications), cause the context won't be active.
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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:03 p.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Jason Porter commented on SOLDER-153:
-------------------------------------
Broken any way we try it huh? Okay, what about your first pull request, does that work?
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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
7:56 a.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Bernard Labno commented on SOLDER-153:
--------------------------------------
Jason, I think what we're hitting here is bug in WeldPhaseListener that destroys
conversation context before error JSF does exception handling.
My poor workaround is to put ExceptionHandlerDispatch into Session scope. Drawback is that
we see only most recent exception (if we were able to have handledException in
conversation then we could create separate conversation per exception).
BTW. I was trying (inside handler) to check if conversation scope is active and if not
then to activate it but the API overwhelmed me.
All in all I think that ExceptionHandlerDispatch is not a place for producing
"handledException" and that other one or it should turn conversation context on
if it's off.
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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
2:07 p.m.
New subject: [JBoss JIRA] (SOLDER-153) Make caught exception available as named bean
[
https://issues.jboss.org/browse/SOLDER-153?page=com.atlassian.jira.plugin...
]
Jason Porter commented on SOLDER-153:
-------------------------------------
That's probably an implementation detail. I don't recall reading anything stating
when the conversation should be destroyed. If that's the case then this may not
actually be possible without fixing the bug and possibly getting a spec clarification for
CDI 1.1
Make caught exception available as named bean
---------------------------------------------
Key: SOLDER-153
URL: https://issues.jboss.org/browse/SOLDER-153
Project: Solder
Issue Type: Feature Request
Components: Core
Reporter: Dan Allen
Assignee: Jason Porter
Priority: Minor
Fix For: 3.0.0.Beta2
As we get into error pages, it's going to be useful to have the caught exception
available via a named bean. I think this is just a matter of adding a dependent-scoped
producer that reads the value of the current CaughtException from a field in the exception
dispatcher.
In Seam 2, the following two variables were available:
org.jboss.seam.caughtException - the original exception that was caught
org.jboss.seam.handledException - the exception cause currently being handled
I think we could just map org.jboss.seam.caughtException to CaughtException...that way
all the info is available, including the exception being handled, the original exception
and the unwrapped stack.
--
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
4483
days inactive
4922
days old
12 comments
3 participants
participants (3)
-
Bernard Labno (JIRA) -
Dan Allen (JIRA)
-
Jason Porter (JIRA)