-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:[email protected] > Web: fusesource.com > Twitter: freemanfang > Blog: http://freemanfang.blogspot.com > Connect at CamelOne May 24-26 > The Open Source Integration Conference -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
