Gregory,

> On 19 Jul 2004, at 20:36, Werner Guttmann wrote:
> > WHat do you really want me to do here ? Be affirmative .. ;-) ?
> 
> Sure.  Nothing wrong with saying "Dolt.  RTFM" now and then in a 
> mailing list to a loser like me.  :)
> 
> > I was just about to ask you a question related to this ... you've 
> > simply beaten me.
> 
> What was terribly strange is that I just wasn't getting the error codes 
> to help me out with this.
> 
> > Well, it should fail on the first access of JDO.getDatabase(), as 
> > that's where the correct 
> > TransactionManagerFactory.getTransactionManager() will be
> > executed.
> 
> Fair, so long as JDO.getDatabase() will always return null, forever; 
> which, now from memory, I think it didn't always do.
Well, it should not, as an exception *should* be thrown to indicate that a
TransactionManager instance can not be found/instantiated. 

>(That could have 
> been my error logging, though - I don't handle db=null cases very 
> gracefully, as they're not a common occurrence here.  :)
Well, as said above, you should not have to.

> Also - if it's possible - please catch the ClassCastException 
> explicitly and report an explicit error message.  (Will add to bug; bug 
> is 1690, "JNDIEncTransactionManagerFactory exception logging is 
> sub-optimal"
I've seen the bug report already, but I won#t be able to get anything done
before August 4th, 2004 due to ... holidays ... ;-).
> 
> > Yes, indded. Please have a close look at some of the open bugs, and 
> > you'll find some references there to such a class. Look for all bugs 
> > assigned to me
> > or CCed to mem and you should see such a 'debate'.
> >
> 
> 1363 covers it nicely; if that were done across the whole of JDO, it 
> would really, really, REALLY improve things.  :)
> 
> Are you looking for a gift implementation that I've got lying around?  
> I've got one to hand as we speak that has the getCause() handling, 
> includes a bunch of printStackTrace implementations that walk the 
> causes and builds message output from the complete hierarchy.
Yes, please. But the real exercise is to integrate this with Castor's
exception classes, i.e. find the right Castor-specific Exception class that
needs to be modified (and here people like Keith will want to have an
opinion, I assume .. ;-)), deal with JDK 1.2 compliancy, etc.

>  If 
> you're looking for something that collapses over RMI, I can add that - 
> but that was pretty special purpose.
Somehow I think that the RMI stuff would not be required ... 
> 
> (Essentially, we didn't want to transfer a hierarchy over RMI, so we'd 
> 'flatten' the exception at the time of serialization, and on 
> reserialization, getCause() returns null, but the exception stack trace 
> is all there when you print it.)
> 
> We're using it everywhere here, so you're welcome to it.  If you're 
> looking for the flattening, I can probably chuck that in relatively 
> quickly - I try to stick to SOAP on this project, not RMI, so it makes 
> no difference to me one way or the other.
> 
> 
> 
> ----------------------------------------------------------- 
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
>         unsubscribe castor-dev
> 



----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to