[JBoss JIRA] Created: (SEAMCATCH-32) untangle processing of exceptions in stack
by Dan Allen (JIRA)
untangle processing of exceptions in stack
------------------------------------------
Key: SEAMCATCH-32
URL: https://issues.jboss.org/browse/SEAMCATCH-32
Project: Seam Catch
Issue Type: Task
Components: Core Implementation
Affects Versions: Alpha2
Reporter: Dan Allen
Assignee: Jason Porter
Fix For: Alpha3
Currently, the exceptions in the stack are being handled in tandem. All the breadth-first type visiting is happening for each exception in the stack, then all the depth-first type visiting is happening. Each exception should be processed in turn.
Consider this case:
The following exception chain is thrown: E1 -> E2 -> E3 (where "X -> Y" means X is caused by Y). Also, E3S is a superclass of E3. Let's assume there are handlers for all four exception types for both traversal modes (breadth-first and depth-first).
The expected order of execution is as follows:
E3S handler in the breadth-first traversal mode
E3 handler in the breadth-first traversal mode
E3 handler in the depth-first traversal mode
E3S handler in the depth-first traversal mode
E2 handler in the breadth-first traversal mode
E2 handler in the depth-first traversal mode
E1 handler in the breadth-first traversal mode
E1 handler in the depth-first traversal mode
We process the exceptions in the stack in the order E3, E2, E1 because we assume the cause, E3 is the most important exception.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
by Dan Allen (JIRA)
change terminology for exception type hierarchy traversal
---------------------------------------------------------
Key: SEAMCATCH-31
URL: https://issues.jboss.org/browse/SEAMCATCH-31
Project: Seam Catch
Issue Type: Feature Request
Reporter: Dan Allen
Assignee: Jason Porter
There appears to be some confusion about what the traversal path means. We've come up with some better terms that should help users understand how to use it.
When one of the exceptions in the stack trace is being handled, the handlers for that exception are notified in a particular order. That order is based on the type hierarchy of the exception. The traversal seeks to address this scenario:
Assume that a group of exceptions have a common super class. You may choose to write a handler that catches all of those exceptions by handling that super type. We'll call that a category handler, where the super class represents a category (i.e., SQLException) So the question you have to ask yourself, then, is:
Do you want your category handler to be notified before or after the handler for the subtype gets notified?
You specify you want the category handler to be notified before by adding the attribute during = TraversalPath.DESCENDING to the @Handles exception.
However, this descending/ascending isn't catching on. Tree traversal is more commonly referred to using the terms breadth-first or depth-first. Catch notifies breadth-first handlers before depth-first handlers, in the order of the tree traversal (walking the exception type hierarchy).
Therefore, these attribute values would make more sense:
during = TraversalMode.BREADTH_FIRST
during = TraversalMode.DEPTH_FIRST (default)
If you write a SQLException handler with during = TraversalMode.BREADTH_FIRST, then it will be notified before a handler for BatchUpdateException.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (SEAMCATCH-27) The Catch observer should have an @Any qualifier
by Brian Leathem (JIRA)
The Catch observer should have an @Any qualifier
------------------------------------------------
Key: SEAMCATCH-27
URL: https://issues.jboss.org/browse/SEAMCATCH-27
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Affects Versions: Alpha2
Reporter: Brian Leathem
Assignee: Jason Porter
Given that a developer may add a Qualifier to the event that fires the ExceptionToCatch, the Catch observer should have the @Any qualifier to make sure the the Exception is picked up by Catch.
For example, in the Faces integration, I was firing the event with "beanManager.fireEvent(catchEventm new FacesLiteral());". The presence of this qualifier caused Catch to overlook my Exception. Having the @Any qualifier on the Catch observer would have ensured that my Exception was still forwarded to Catch.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Created: (SEAMCATCH-29) Descending traversal path not working as expected
by Jozef Hartinger (JIRA)
Descending traversal path not working as expected
-------------------------------------------------
Key: SEAMCATCH-29
URL: https://issues.jboss.org/browse/SEAMCATCH-29
Project: Seam Catch
Issue Type: Bug
Components: Core Implementation
Affects Versions: Alpha2
Reporter: Jozef Hartinger
Assignee: Jason Porter
Priority: Blocker
Fix For: Alpha3
As far as I understand the docs, the descending traversal path does not seem to be implemented correctly. Having the following exception chain E1 -> E2 where E1 is caused by E2, the order of execution seems to be as follows:
1.) descending handler for E2
2.) descending handler for E1
3.) ascending handler for E2
4.) ascending handler for E1
which looks like as if the ascending traversal path has been executed twice instead of going to the root cause and back.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Commented: (SEAMCATCH-4) Include the ability to filter stack traces
by Dan Allen (JIRA)
[ 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
> Include the ability to filter stack traces
> ------------------------------------------
>
> Key: SEAMCATCH-4
> URL: https://issues.jboss.org/browse/SEAMCATCH-4
> Project: Seam Catch
> Issue Type: Feature Request
> Reporter: Jason Porter
> Assignee: Jason Porter
> Fix For: 3.0.0.Alpha4
>
>
> Catch should draw from ideas such as:
> - http://www.docjar.org/html/api/org/apache/commons/lang/exception/Nestable...
> - http://stackoverflow.com/questions/2504647/bash-how-to-filter-java-except...
> - http://squirrelsewer.blogspot.com/2010/03/filter-your-stack-traces.html
> - http://pastebin.com/p8aCSeuu
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[JBoss JIRA] Commented: (SOLDER-53) Seam Solder incontainer tests fail
by Rogerio Baldini (JIRA)
[ https://issues.jboss.org/browse/SOLDER-53?page=com.atlassian.jira.plugin.... ]
Rogerio Baldini commented on SOLDER-53:
---------------------------------------
Hi guys,
How can I solve this problem ?
java.lang.IllegalStateException: No CreationalContext registered for EL evaluation, it is likely that the the expression factory has not been wrapped by the CDI BeanManager, which must be done to use the ELResolver from CDI
at org.jboss.weld.el.AbstractWeldELResolver.getELCreationalContext(AbstractWeldELResolver.java:178)
at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:146)
at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:112)
at org.jboss.weld.environment.servlet.util.ForwardingELResolver.getValue(ForwardingELResolver.java:55)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68)
at org.apache.el.parser.AstValue.getTarget(AstValue.java:68)
at org.apache.el.parser.AstValue.isReadOnly(AstValue.java:135)
at org.apache.el.ValueExpressionImpl.isReadOnly(ValueExpressionImpl.java:224)
at org.jboss.weld.util.el.ForwardingValueExpression.isReadOnly(ForwardingValueExpression.java:56)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.EditableValueRenderer.getReadOnly(EditableValueRenderer.java:250)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.renderAsElement(FormElementRenderer.java:227)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAll(FormElementRenderer.java:108)
at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:501)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputLabelAndMessageRenderer.encodeAll(InputLabelAndMessageRenderer.java:122)
at com.powerlogic.jcompany.visao.jsf.renderer.PlcTextoRenderer.encodeAll(PlcTextoRenderer.java:110)
at com.powerlogic.jcompany.visao.jsf.renderer.PlcOidRenderer.encodeAll(PlcOidRenderer.java:92)
at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:364)
at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:782)
at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:337)
at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279)
at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:256)
at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425)
at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343)
at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:235)
at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:142)
at org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:93)
at org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:85)
at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.renderInternal(UIXComponentUINode.java:192)
at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:70)
Thanks,
Rogerio
> Seam Solder incontainer tests fail
> ----------------------------------
>
> Key: SOLDER-53
> URL: https://issues.jboss.org/browse/SOLDER-53
> Project: Seam Solder
> Issue Type: Bug
> Components: Test Suite
> Reporter: Stuart Douglas
> Assignee: Dan Allen
> Fix For: 3.0.0.Beta1
>
>
> CoreTest fails with:
> testFullyQualifiedBeanNames(org.jboss.seam.solder.test.core.CoreTest) Time elapsed: 0 sec <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> ServiceHandlerTest fails with:
> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [EchoDecorator] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.servicehandler.DecoratedEchoServiceHandler.decorator]
> DefaultBeanTest fails with:
> Deployment "vfs:///Users/stuart/nworkspace/solder-parent/impl/test.war_WeldBootstrapBean" is in error due to the following reason(s): org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [MagneticDrive] with qualifiers [@Default] at injection point [[field] @Inject org.jboss.seam.solder.test.defaultbean.DefaultBeanTest.magneticDrive], **ERROR**
> ElTest fails with:
> java.util.EmptyStackException
> at java.util.Stack.peek(Stack.java:85)
> at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:147)
> at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:113)
> at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:67)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:115)
> at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187)
> at org.jboss.seam.solder.el.Expressions.evaluateValueExpression(Expressions.java:143)
> at org.jboss.seam.solder.el.Expressions.evaluateValueExpression(Expressions.java:185)
> at org.jboss.seam.solder.test.el.ElTest.testElResolver(ElTest.java:46)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months