[seam-issues] [JBoss JIRA] Commented: (SEAMCATCH-4) Include the ability to filter stack traces

[ https://issues.jboss.org/browse/SEAMCATCH-4?page=com.atlassian.jira.plugi... ] Dan Allen commented on SEAMCATCH-4: ----------------------------------- Some discussion that led to the proposed API: (11:42:06) Dan: I realized that if we had something like a PrepareCaughtException event (11:42:20) Dan: then in that event, it would be possible to apply filtering or mapping (11:42:25) Dan: and then do (11:42:33) Dan: PrepareCaughtException#setException() (11:42:43) Dan: just like ProcessAnnotatedType#setAnnotatedType() (11:43:12) Dan: so that's one place to do global filtering, and is interesting because then you actually pare down the exception that even needs to be handled (11:43:20) Dan: potentially, as an option (11:43:30) Jason: Cool idea (11:43:40) Dan: or you can replace causes w/ an app equivalent (11:43:55) Dan: for instance persistence can provide some mappings between a SQLExeption and something like InvalidTableException (11:44:00) Dan: and so forth (11:44:23) Jason: That would basically handle your mapping (11:44:28) Dan: then, you could always use the same api for filtering the exception at any time, since it's reusable (11:44:30) Dan: yep (11:44:32) Dan: exactly (11:44:53) Dan: I was thinking whether we needed a post-process (11:44:57) Jason: What would that event need on it? (11:44:59) Dan: maybe let's wait to see if there is some need (11:45:14) Dan: I'm thinking it just has the Exception (11:45:17) Jason: We fire it once? (11:45:23) Dan: and the unwrapped stack (11:45:26) Jason: At the start of catch process? (11:45:33) Dan: yes (11:45:35) Dan: yes (11:46:01) Dan: I thought about ProcessCaughtException, but I don't like how that implies handling (11:46:07) Dan: I like Prepare (11:46:10) Dan: or PreProcess (11:46:21) Dan: this is really interesting (11:46:30) Dan: it totally changes the game (11:46:36) Dan: because we are saying, not only do you have these handlers (11:46:51) Dan: and do they get to deal with the exception causes individually (like a handler for SQLException) (11:47:02) Dan: but you can tune the exception getting fed into the system (11:47:06) Dan: I'd even say (11:47:09) Dan: you could add qualifiers (11:47:32) Dan: btw, the qualifiers should be available to the CaughtExeption, I was thinking about that (11:47:34) Dan: if they aren't already (11:47:49) Dan: something imo missing from the eventing system in cdi (11:47:57) Jason: hm? (11:48:01) Jason: which qualifiers? (11:48:19) Dan: consider this...your observer is called (11:48:26) Dan: in our case handlers, but I'm going to talk in general (11:48:31) Dan: you don't really know why (11:48:47) Dan: you know because it at least had a subset of qualifiers, or matched any (11:49:00) Dan: but you don't know what qualifiers were actually on the original event (11:49:12) Dan: we can provide that info in CaughtException (11:49:30) Jason: Ah (11:49:42) Dan: just some info...why not share it (11:49:53) Dan: I think this is solved in CDI (11:50:00) Dan: by allowing you to inject the Event object (11:50:11) Dan: when you observe...so like this (11:50:40) Dan: @Observes(@Updated Document document, Event<Documentg firingEvent) (11:50:44) Dan: interesting for two reasons (11:51:00) Dan: one, you have access to information about the firing (11:51:08) Dan: you can turn around and fire the event again (11:51:47) Jason: true (11:51:49) Dan: rats, Event doesn't have getQualifiers() on it (11:51:51) Jason: But then you'll be called again (11:51:52) Dan: it probably should (11:51:56) Dan: well, likely (11:52:07) Dan: you would use it as a parent, add a qualifier and go again, something like that (11:52:14) Dan: kind of as a pass on (11:52:25) Dan: I don't know...you could also just have this (11:52:28) Dan: EventSource (11:52:37) Dan: EventSource { qualifiers, bean } (11:53:02) Dan: anyway, for us, we just expose it from CaughtException (11:53:28) Dan: but that's a side note (11:53:36) Dan: back to the pre-processor (11:53:49) Dan: ah, I had an idea about the statelessness of the filter (11:54:02) Dan: the key here is not providing the index or anything (11:54:15) Dan: but providing a state object (11:54:29) Dan: or, a status object, not sure the correct term (11:54:39) Dan: a visitlog (11:54:49) Dan: and it has like last frame (11:54:54) Dan: you can set a mark (11:54:59) Dan: maybe a fold marker (11:55:05) Dan: things like that (11:55:08) Dan: then you can say like (11:55:37) Dan: visitlog.isMarkSet() (11:55:46) Dan: or getMarkedFrame() (11:56:00) Dan: that way, the range information is provided to the method (11:56:24) Jason: Hm (11:56:35) Jason: We'd need a reset or something (11:56:41) Dan: so let me give you the api I'm thinking (11:56:45) Jason: And they could also give us the replace info (11:56:49) Dan: yeah ;) (11:56:51) Dan: exactly (11:56:53) Dan: like this (11:56:57) Dan: visitlog.replaceFrame() (11:57:07) Dan: and then you still return a result (11:57:27) Dan: like SKIP, CONTINUE, TERMINATE -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira