Kohsuke Kawaguchi wrote:
>> I suppose having such a method is mildly more efficient since an
>> XMLStreamReader instance does not need to be retained. e.g. this:
>
>
> Yeah, but this is only added for the security pipe and if they aren't
> going to use it, I think it might be better not to have it. For many
> message implementations (like JAXB), this isn't very cheap. Besides, for
> the security component, once it finds an ID, it will want to play the
> infoset, so they might want to access XMLStreamReader anyway.
>
The most likely scenario is that a writeTo method will be used to
canonicalize the output using a canonical XMLStreamWriter
implementation. But the instantiation of an XMLStreamReader
implementation wrapping a stream buffer should be very light weight.
>
>
>> We also need similar functionality on Message. The security pipe needs
>> to:
>>
>> - get the attributes on the SOAP body; and
>>
>> - serialize out the SOAP body and payload canonically.
>>
>>
>> So we would need:
>>
>> String getAttributeValue(String nsUri, String localName);
>>
>> or:
>>
>> XMLStreamReader readSoapBodyAndPayload();
>>
>> In addition to:
>>
>> void writeSoapBodyPayloadTo(XMLStreamWriter sw)
>
>
> Right. That's another reason I didn't feel very comfortable adding the
> Header.getAttributeValue method, as we'll also need to have those
> methods added on Message, which makes a Message implementation more
> tedious.
>
> But I'm confused. Do you think we should have all those, or do you think
> we should get rid of Header.getAttributeValue?
>
Sorry i forgot to strongly expression my opinion!!
I do not think we need a getAttributeValue method on Header or Message.
The XMLStreamReader interface can be used instead to get an attribute on
a header or SOAP body, and this will support the "simple" optimized
security solution. Also such a getAttributeValue method will become
redundant if we move to a move general ID processing solution.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109