Hah.
Ok, I'm an idiot. The problem, once I started doing enough e.initCause(ex)'es, was that the name wasn't actually correct, nor was the type - I was configured for a UserTransaction, not a TransactionManager; the fact that it can *cast* to a TM wasn't helping the fact that it couldn't get loaded.
What I thought was creepy is that it went on anyways; even though I'd specified a TransactionManager, and it never got one, it went on acting as if it had one.
So, 2 things I guess:
- Have it fail permanently if it can't get one and it's configured for one. Not having one there is too dangerous to allow it to live.
- Within JNDIENCTransactionManagerFactory.java, have it log the complete exception thrown by the method, rather than eating it, unless you're willing to initCause() your way up the tree.
I wonder if a general HierarchicalException class would be useful; I think I've still got one lying around that does things like serialize itself properly into flattened representations suitable for RMI. Any value in adding this to castor in order to get similar functionality? Do people care about the 'caused by' stuff, or is it just me who gets infuriated by not seeing the real cause of exceptions? :)
On 12 Jul 2004, at 15:30, Gregory Block wrote:
On 12 Jul 2004, at 08:46, Gregory Block wrote:I'll patch immediately, and tell you the results. :)
Result: No change to behavior. Same problem. Something very, very strange is happening; I'll do some digging this afternoon.
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
smime.p7s
Description: S/MIME cryptographic signature
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
