cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [DISCUSS]make useFQCNForFaultSerialVersionUID as default behavior for generated exception class
Date Thu, 02 Jun 2011 02:09:48 GMT


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.


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 -

View raw message