axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Venkat Reddy <vred...@gmail.com>
Subject Re: [jira] Commented: (AXIS-2025) Illegal XML characters in String arguments and return values cause XML exceptions in Axis calls
Date Wed, 29 Jun 2005 04:49:48 GMT
On 6/28/05, Shankar Unni (JIRA) <axis-dev@ws.apache.org> wrote:
>     [ http://issues.apache.org/jira/browse/AXIS-2025?page=comments#action_12314621 ]
> 
> Shankar Unni commented on AXIS-2025:
> ------------------------------------
> 
> > With less jumping up and down and more providing of a patch, I would think that
this
> > is a valid bug and be inclined to apply the patch.
> 
> I apologize. It's been a bit frustrating dealing with this bug.
> 
> Yes, Axis is a SOAP processor, and not an RPC mechanism. And Yes, SOAP lays out rules
for what is a valid message. The question is what happens when you try to implement an RPC
mechanism on top of SOAP - the bug is in *that* layer, which the Axis library also supports.

[venkat] So, is this a question for SOAP spec?

> So yes, it's a larger issue - *if* you're building an RPC layer on top of the SOAP infrastructure,
and given the restrictions in the SOAP layer's use of <xsd:string>, how do you safely
transport Strings in general.
> 
> This is definitely an interoperability issue. But in the meantime, is there some other
type that can be used to transport such strings? For instance, is it possible to use a custom
type to map Strings into SOAP (i.e. avoid <xsd:string>)? Would such a thing be portable?
I could see a custom mapping to some base64-type representation for the string body, but both
sides need to agree that it's a String, and have it be mapped back to a String upon decoding.
> 
> Even if ready-made solutions are not available, I would greatly appreciate some hints
or suggestions on how this can be *reasonably* handled - something that doesn't involve trying
to hunt down every string in every interface and possibly convert them to attachments, or
hand-encoding and decoding every string everywhere..  (I.e. reasonable workarounds / suggestions
would be a great help!)
> 

[venkat] How about making your service method and client code a bit
smarter, doing a scan of strings and escaping / unescaping the invalid
characters before pasing it onto Axis? Infact Axis does the same thing
- scanning each character in every string. For me, its the question of
who should handle the xml-invalid characters and I think the
application code is the right place to do it, until the
interoperability specs change their mind and put the onus onto the
SOAP processors.

Otherwise, can you suggest a reasonable patch for Axis code for
"safely transporting" the invalid characters?

-- venkat

Mime
View raw message