Details
-
Type:
Feature Request
-
Status: Resolved (View Workflow)
-
Priority:
Minor
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 3.0.0.Beta2
-
Component/s: Core
-
Labels:None
-
Affects:Documentation (Ref Guide, User Guide, etc.)
-
Estimated Difficulty:Low
Description
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.
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Pull request: https://github.com/seam/solder/pull/74
Bernard Labno
added a comment - Pull request: https://github.com/seam/solder/pull/74 Jason, sorry, but this issue is not finished.
Take a look at Phase.java:
try
catch (Throwable e)
{ queueException(context, e); } // stop timing
if (timer != null)
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.
Bernard Labno
added a comment - 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. Broken any way we try it huh? Okay, what about your first pull request, does that work?
Jason Porter
added a comment - Broken any way we try it huh? Okay, what about your first pull request, does that work? 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.
Bernard Labno
added a comment - 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. 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
Jason Porter
added a comment - 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 
We're talking about the first CaughtException we create?