cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: [DISCUSS]make useFQCNForFaultSerialVersionUID as default behavior for generated exception class
Date Thu, 02 Jun 2011 02:46:25 GMT
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.


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]
> 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
>>> Web:
>>> Twitter: freemanfang
>>> Blog:
>>> Connect at CamelOne May 24-26
>>> The Open Source Integration Conference
>> -- 
>> Daniel Kulp
>> Talend -
> ---------------------------------------------
> Freeman Fang
> FuseSource
> Web:
> Twitter: freemanfang
> Blog:
> Connect at CamelOne May 24-26
> The Open Source Integration Conference

Freeman Fang

Twitter: freemanfang
Connect at CamelOne May 24-26
The Open Source Integration Conference

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message