Related thoughts and issues: That means the proxy cannot be final and that the event needs to track both the proxy AND the throwable...
Note that there are cases where events are non-local, that is, when they are deserialized from another class loader or another JVM (from a Serialized object , XML or JSON; or whatever Jackson can handle, BSON for example?). I think what we want is what we have now: to have the event built from a local throwable or from a remote throwable proxy. Then all internal use of the event should with the get proxy API because the throwable may be null. So that's another thing to check. What even APIs do we use internally... Currently not implemented (but possible I think) is rebuilding somekind of Throwable from a proxy. Even if we do that, it is still possible for the Throwable to be null because the class does not exist in the class loader. A hack would be to then create a special Log4J exception (RemoteThrowable? How does RMI handle this?) to hold the values from the proxy... seems pretty odd. Gary On Mon, May 19, 2014 at 10:14 AM, Remko Popma <remko.po...@gmail.com> wrote: > Currently Log4jLogEvent creates a ThrowableProxy in the constructor (if > Throwable is non-null). I would like to construct > the ThrowableProxy lazily: only if the Log4jLogEvent is serialized or if > its getThrowableProxy method is called. (Already did this for > RingBufferLogEvent.) > > Does anyone have any concerns against doing this? > > Details: https://issues.apache.org/jira/browse/LOG4J2-250 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
