axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "toby cabot (JIRA)" <>
Subject [jira] Commented: (AXIS-1589) SerializationContext.serialize(*,*,*,*,Boolean.FALSE) adds types
Date Fri, 12 Nov 2004 16:56:25 GMT
     [ ]
toby cabot commented on AXIS-1589:

Hi Tom,  thanks for looking into this!  It looks as if "dims" applied the patch a few days
ago so I think that you can close this issue.
Regards, Toby
PS.  it would be cool if the person that attached a file could delete it.  I like to update
the patches so they apply cleanly but it gets confusing to have a stack of them attached to
the bug.

> SerializationContext.serialize(*,*,*,*,Boolean.FALSE) adds types
> ----------------------------------------------------------------
>          Key: AXIS-1589
>          URL:
>      Project: Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2RC1
>  Environment: fedora core 2
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
> cvs HEAD as of 2004-10-04
>     Reporter: toby cabot
>  Attachments: axis-no-types-patch.txt
> Hi.
> I'm working on an application that needs to xml-serialize trees of wsdl2java-generated
objects to an XML document so it can e.g. save them to a file.  I'm using the 1-argument constructor
and the 5-argument SerializationContext.serialize() method but it seems to ignore the Boolean
sendType argument; it adds types to the output whether the value is Boolean.TRUE or Boolean.FALSE.
> The problem seems to be that SerializationContext has a flag (sendXSIType) to indicate
whether the types should be sent, but serialize() never sets that variable so when it calls
specific type serializers (e.g. BeanSerializer) and then they call back to StartElement the
caller's argument has been "forgotten" and it adds the type to the output anyway.
> So I've added a patch that seems to fix the problem.  It caches the value of sendXSIType,
sets it based on the user's preference, and then sets it back before exiting serialize().
 It seems to pass all-tests and it respects the value of the caller's sendType argument.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message