Hi Dan,
Sorry, I was too eager to reply your thread.
Don't put serialVersionUID in faults class and let JDK to handle it
still can cause problems, as different JDK may generate
serialVersionUID during compile time even the source class is exactly
same, that's not we're expecting, correct?
It should be a good practice that we should always add
serialVersionUID for java serialization to avoid InvalidClassException.
And here is the doc[1] about how JDK generate default
serialVersionUID, more specifically, this part.
If a serializable class does not explicitly declare a
serialVersionUID, then the serialization runtime will calculate a
default serialVersionUID value for that class based on various aspects
of the class, as described in the Java(TM) Object Serialization
Specification. However, it is strongly recommended that all
serializable classes explicitly declare serialVersionUID values, since
the default serialVersionUID computation is highly sensitive to class
details that may vary depending on compiler implementations, and can
thus result in unexpected InvalidClassExceptions during
deserialization. Therefore, to guarantee a consistent serialVersionUID
value across different java compiler implementations, a serializable
class must declare an explicit serialVersionUID value. It is also
strongly advised that explicit serialVersionUID declarations use the
private modifier where possible, since such declarations apply only to
the immediately declaring class--serialVersionUID fields are not
useful as inherited members. Array classes cannot declare an explicit
serialVersionUID, so they always have the default computed value, but
the requirement for matching serialVersionUID values is waived for
array classes.
I still think the defaut way in generated fault class shouldn't cause
such InvalidClassException if the fault class is actaully same, I
think the hashcode of package name should be fine.
[1]http://download.oracle.com/javase/6/docs/api/java/io/Serializable.html
Freeman
On 2011-6-2, at 上午10:23, Freeman Fang wrote:
Thanks Dan.
This also works for me, create CXF-3566[1] to track it.
[1]https://issues.apache.org/jira/browse/CXF-3566
Freeman
On 2011-6-2, at äžå10:09, Daniel Kulp wrote:
-0
I'd actually go a separate direction with this. I would create a
new
useTimestampForFaultSerialVersionUID flag or similar, but make the
default to
NOT output a serialVersionUID at all in the faults. Let the JDK
handle that
based on the normal semantics of the object and such. I just tried
wsimport
and it doesn't generate a serialVersionUID at all so I'm going to
assume the
TCK won't complain about it.
I guess I would make the flag something like:
-faultSerialVersionUID=[none|timestamp|qname] to make it extensible
to other
options in the future.
Dan
On Wednesday, June 01, 2011 9:18:43 PM Freeman Fang wrote:
Hi,
Currently when use wsdl2java, by default the generated exception
class
has a serialVersionUID field which use the timestamp when generate
the code, also we have another flag useFQCNForFaultSerialVersionUID
which generate serialVersionUID based on hashcode of the fully
qualified class name of the Exception.
The serialVersionUID generally doesn't matter when we use typical
way
to do webservice invocation which use jaxb to do marshall/unmarsall,
however, for some scenario customer need use java serialization to
serialize/deserialize the auto-generated Exception object(like using
jms or rmi to pass object directly), and generally they won't
generate
the code once and use the same copy of generated code everywhere,
customer just have same copy of wsdl file and generate the code when
they need use it, this cause the problem that the serialVersionUID
is
different timestamp, so even though it's actually same exception
class, they can't use java serialization.
I know that customer may change the wsdl before generate code each
time, but IMHO java serialVersionUID to provide a chance that try it
best to match the serialize/deserialize even between different java
class version(a new filed added doesn't matter), so how about we
make
useFQCNForFaultSerialVersionUID as default behavior, if the
qualified
class name not change, then generate same serialVersionUID, it's
make
it easier to use generated exception with java serialization.
Best Regards
Freeman
---------------------------------------------
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
---------------------------------------------
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
---------------------------------------------
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
