On 06/15/2013 09:59 PM, Nick Williams wrote:
And about adding a way to store the class in the StackTraceElement, one issue
is that stack trace element are Serializable, so if an error occurs on a
server, the exception can be serialized to the client which is a really nice
feature, but if a stack trace element embed the class object, then it means
that all the class that are available at server side should also be available
at client side.
>I have no idea how Microsoft solve this issue.
Classes are Serializable in Java, so it shouldn't cause a problem with
serialization. The elementClass property will be properly serialized and
deserialized. If I understand you correctly, you're expressing concern that
this could actually be a problem; that we don't want Classes transferred to the
client and deserialized. The Class class has a special serialized form that is
unlike other classes and is very efficient. Only a descriptor for the class
(including its serialVersionUID value) is transmitted, just enough to give the
endpoint enough information to locate the class.
That's true when Class objects are serialized with a purpose and intent
that they will be deserialized in an environment where correct versions
of those classes are visible by class initiating deserialization. Stack
trace can contain references to classes that are not visible even by the
class that constructed the Throwable. By exposing Class objects that
would otherwise not be obtainable, there could be security issues.
There won't be a performance issue here, as far as I can tell. However, I can
foresee one potential problem when deserializing the StackTraceElement: if the
Class isn't on the class path on the deserializing JVM. This could be handled
two possible ways:
1) Mark the elementClass property on StackTraceElement transient so that it
isn't serialized.
2) Add a special deserialization rule (not unprecedented by any means) for
StackTraceElement that says that StackTraceElement will not fail to deserialize
if the elementClass property can't be deserialized because it couldn't be
loaded. (This would be my suggestion.)
I'm not sure how .NET handles it either, but it clearly does, as its StackFrame
class is the equivalent of Serializable.
I think that option #1 is the only realistic option. Who cares about
classes in the de-serialized stack-trace. The only thing needed is their
names so that the stack-trace can be printed.
Regards, Peter
