cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [DISCUSS]make useFQCNForFaultSerialVersionUID as default behavior for generated exception class
Date Thu, 02 Jun 2011 03:44:08 GMT

The more I think about it the more I disagree.

Fundamentally, we are a WEB SERVICES stack. In particular, a JAX-WS and JAX-RS 
implementation.   Part of that is being completely interopable and 
interchangable (when using defaults) with other JAX-WS implementations.    
Thus, if we're going to change this, we should go in the direction of the 
reference implementation.   Projects should be free to use the CXF wsdl2java 
tool or wsimport and end up with the same usable and interopable code.

If people are using the CXF (or wsimport) generated code outside of the normal 
web services cases, I'm certainly not going to stop them, but that's not what 
our target is so some caveats may exist and people need to think about it.

To expand it out even further, the JAXB generated code isn't serializable at 
all by default.   Thus, if they want to use the generated code in your use 
case, they already have to do some work to get there.   Not only that, but if 
you just use the plain JAXB serializable customization, it ALSO doesn't 
generate a serialVersionUID.   Thus, not generating one makes us completely 
consistent with the other tools we are tied with.

That said, I'd expand the flag to be:

-faultSerialVersionUID=[none|timestamp|qname|###] 

where the ### could be any integer/long....  to allow the user to completely 
manage it.  (like start with 1 and increment if something changes to cause an 
issue)

Dan



On Wednesday, June 01, 2011 10:46:25 PM Freeman Fang wrote:
> 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:ffang@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:ffang@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:ffang@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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message