The thing that we discussed (and I have just not yet had time to implement) is actually converting QueryExceptions that contain antlr stuff during serialization by either writeReplace() or writeObject(). Initially we had discussed just stripping the cause in the case of antrl exception, but perhaps another option is to simply write a replacement for the antlr exception during writeObject() on the QueryException.
Yet another option would be to handle this as we recognize antrl exceptions in the translator/parser and "decompose" that information. I don't think the stack trace of the antlr exceptions themselves are really that vital to users anyway so we could just log the antlr exceptions for debug purposes. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max Rydahl Andersen Sent: Tuesday, February 07, 2006 2:02 PM To: Scott M Stark; jboss-development@lists.sourceforge.net; Hibernate development Subject: Re: [Hibernate] Do antlr exception leak to users? On Tue, 07 Feb 2006 20:55:52 +0100, Scott M Stark <[EMAIL PROTECTED]> wrote: >> fixing the antlr exception svuid won't help us if the client >> is using an older version, right ? >> > It will if the serialVersionUID is set to the implicit value from the > previous version. This can be done if the version is still serializable > compatible. which it isn't afaik. the antlr version started to include more data in the exception over time. >> calling printStackTrace() on every exception sounds overkill >> for me...and will turn basic logging into something very verbose. >> > Should be no different from now as logging generally includes the cause. well, for me that is showing the exception message in a dialog in the ui I would be very disappointed to have a full stack trace in the message output. >> I understand the issue, but don't find the suggested >> solutions any good ;( >> >> Would be nice to have an option to have any exposed remote >> exception do the serialization of the "cause". >> Would make it a non-issue where it actually matters. >> > This can't be done without modifying the exception either via source or > bytecode manipulation. And bytecode manipulation or simple modification of the exception in the jboss serialization/remoting layer have that option, correct ? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
