> which it isn't afaik. the antlr version started to include > more data in the exception over time. > Including additional data is not an incompatible serialzable change generally. Its optional data that will be ignored and cannot affect the legacy implementation.
> >> 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. > True, but this can be handled by wrapping the stacktrace in a generic exception whose msg is the cause stacktrace. > > And bytecode manipulation or simple modification of the > exception in the jboss serialization/remoting layer have that > option, correct ? Dealing with incorrect serialization implementation via hacks at the serialization layer is not a scalable solution. ------------------------------------------------------- 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 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
