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