seam-issues January 2011

seam-issues@lists.jboss.org

1 participants
464 discussions

[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

13 years, 12 months

3
13
0 / 0

[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

13 years, 12 months

2
3
0 / 0

[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

13 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (SEAMJMS-13) JMS Test Destinations don't play nice with HornetQ on JBoss AS 6 Final

by Jordan Ganoff (JIRA)

JMS Test Destinations don't play nice with HornetQ on JBoss AS 6 Final ---------------------------------------------------------------------- Key: SEAMJMS-13 URL: https://issues.jboss.org/browse/SEAMJMS-13 Project: Seam JMS Issue Type: Bug Reporter: Jordan Ganoff Any time we try to create a QueueReceiver we see the same root cause in the test stacktraces: javax.jms.JMSSecurityException: Unable to validate user: null for check type CONSUME for address jms.queue.Q at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:287) at org.hornetq.core.client.impl.ClientSessionImpl.internalCreateConsumer(ClientSessionImpl.java:1556) at org.hornetq.core.client.impl.ClientSessionImpl.createConsumer(ClientSessionImpl.java:447) at org.hornetq.core.client.impl.ClientSessionImpl.createConsumer(ClientSessionImpl.java:413) at org.hornetq.core.client.impl.DelegatingSession.createConsumer(DelegatingSession.java:187) at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:531) at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:375) at org.hornetq.jms.client.HornetQSession.createConsumer(HornetQSession.java:345) at org.jboss.seam.jms.impl.inject.MessagePubSubProducer.createQueueReceiver(MessagePubSubProducer.java:87) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

← Newer
1
...
44
45
46
47
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues January 2011