It's not so much a spec issue as it is a way to make sure the faults are
relatively unique. We don't really have a way to make sure the faults you
are generating are from the exact same wsdl as the ones your friend are
generating. Thus, we kind of put a unique id in there.
I'd be open to a patch to provide an option to change it, but I'm not sure
what it would be changed to. Maybe something simple like "-faultSUID=#####"
or something so all faults get the same ID or maybe "-faultSUID=hash" to use a
hashcode of the classname? No idea really.
Like I said, if you come up with a good patch, I'd definitely be open to
applying it.
Dan
On Tuesday 11 May 2010 12:09:02 pm Julien Jean Paul Sirocchi wrote:
> Hi everyone!
>
> I'm just facing a problem here as colleagues of mine are trying to use an
> exception generated by wsdl2java (through cxf codegen maven plugin) in an
> RMI call...
>
> The short story:
> I've an XSD separated from the WSDL; I am using the maven-jaxb2-plugin to
> generate all the schema types; cxf-codegen-plugin (2.2.7) is used only to
> produce the interfaces to the service (explicitly excluding the namespace
> of the types from the compilation unit). Also, that I have a custom JAXB
> bindings file through which I manage to set a specific serialVersionUID on
> all generated types.
> Everything's fine so far.
>
> Unfortunately, the serialVersionUID inside the generated faults (i.e.: the
> java exceptions created by the cxf-codegen-plugin) have a value which is
> equal to yyyyMMddHHmmss of the time when the artifact containing the WSDL
> is produced.
>
> Looking at the source of
> org.apache.cxf.tools.wsdlto.frontend.jaxws.generators.FaultGenerator, I see
> on line 84:
> setAttributes("suid", getSUID());
>
> where, getSUID() is defined as (96-98):
> private String getSUID() {
> return new SimpleDateFormat("yyyyMMddHHmmss").format(new Date());
> }
>
> This is then used inside the Velocity template, as far as I can tell (see
> "fault.vm", line 34):
> public static final long serialVersionUID = ${suid}L;
>
> Unfortunately, I have very little control over what objects/exceptions my
> colleagues are trying to pass around (or serialize/deserialize) and at the
> same time I was hoping to have an option in the cxf plugin to override this
> behaviour... but this is not the case, I guess...
>
> Is there a reason why this is so? Is it per spec by any chance? Any way of
> changing this?
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
