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:23:01 GMT
Thanks Dan.
This also works for me, create CXF-3566[1] to track it.

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

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

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