[seam-issues] [JBoss JIRA] Commented: (SEAMCATCH-26) Make caught exception available as named bean

[Dan Allen (JIRA)]

    [ https://issues.jboss.org/browse/SEAMCATCH-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572585#comment-12572585 ] 

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