Venu wrote:
> Hi Paul,
> Paul Sandoz wrote:
>
>> Hi Venu,
>>
>> So just to summarize you would prefer to use XMLStreamWriter and
>> extentions to it to write out pre-encoded UTF-8 infoset?
>>
>> I can modify/change the ifaces to specify that.
>>
> Yes I would prefer that , but I am curious to know if I missed on
> getting the benefit for InputStreamMessage if any. Kohsuke mentioned
> very briefly about it in
> his previous mail.
>
> I am inclined to a solution that is best for performance.
>
I do not think there would be any performance issues using
XMLStreamWriter/Ex and OutputStream. It is a better abstraction and may
make your job easier.
Paul.
> Regards,
> Venu
>
>> Paul.
>>
>> Venu wrote:
>>
>>> Kohsuke Kawaguchi wrote:
>>>
>>>>
>>>> I'm trying to pick up the discussion of the edge pipe designs.
>>>>
>>>> - StreamBasedMessage. Paul suggested that we should parameterize
>>>> Packet with the actual message type 'T' (where T could be things
>>>> like Message or StreamBasedMessage), but because Packet is highly
>>>> visible, I'd like to keep it as is.
>>>>
>>>> The current StreamBasedMessage.properties works (except that
>>>> it's ugly, since its message field will always be empty.)
>>>>
>>>>
>>>> - XMLStreamReaderMessage processStreamReader(Packet packet) makes
>>>> sense,
>>>> as a Message is an XML infoset anyway, but I'm not sure about the
>>>> versions that take InputStreamMessage.
>>>
>>>
>>> XMLStreamReaderMessage processStreamReader(InputStreamMessage msg);
>>>
>>> if you are talking about the above method then yes I would still
>>> prefer what is suggested at the end of this mail.
>>>
>>>
>>>>
>>>> The first concern is that this breaks the encoder pluggability. At
>>>> least we need some negotiation phase so that the security pipe (SP)
>>>> can check if the encoding in use is really what it supports.
>>>
>>>
>>>
>>>>
>>>> Also, I'm convinced enough that going down to the infoset level would
>>>> give a performance improvement to SP, but I'm not so convinced about
>>>> going down to the stream level. I mean, it seems like SP needs to be
>>>> fairly sophisticated to use this correctly. You'd have to produce the
>>>> UTF-8 encoded canonical text for the signed portion, keep it on the
>>>> side, compute the digest as a filter, then produce headers, then the
>>>> buffered body. Is the security team really committed to do this?
>>>
>>>
>>> Yes XWSS 2.0 EA2 already does this to a certain extent.But are you
>>> saying you are not convinced that this
>>> would improve the performance of the WS stack.
>>>
>>>>
>>>> If they aren't planning to do so right away, we can always defer this
>>>> until it's necessary.
>>>>
>>>> Lastly, using InputStreamMessage seems to imply that SP is going to
>>>> cache the whole message in memory
>>>
>>>
>>>
>>>
>>>> (unless SP is very smart and
>>>> implement the whole logic inside out in a InputStream class.) Is that
>>>> what's planned, or am I missing something?
>>>
>>>
>>> Can you be more specific on what you are suggesting.Just to ensure I
>>> understand you right.
>>>
>>>>
>>>> Instead, wouldn't it be better for the ClientEdgePipe to give SP
>>>> a XMLStreamWriter to write to (thus conceptually set the layer to
>>>> the infoset layer, not below)?
>>>>
>>>> XMLStreamWriter would then expose a hint that it's writing to UTF-8
>>>> OutputStream in a plain XML (or perhaps also MTOM), and then SP
>>>> can switch to write to OutputStream directly. We can use this for
>>>> JAXB, too.
>>>>
>>> Yes this will work just fine and this is what we had requested. If I
>>> am not wrong SP layer
>>> will need the information to determine if it can use outputstream or
>>> XMLStreamWriter.
>>>
>>>> I think this is cleaner in the sense that I'm only breaking the
>>>> abstraction one at a time (instead of going straight from Message
>>>> to stream), and each short-cut is usable for other things.
>>>>
>>>>
>>>> - I think similar thing applies to ServerEdgePipe, but let's settle on
>>>> ClientEdgePipe first, and we can just apply the same design to SEP.
>>>>
>>> Apart from this
>>>
>>> Regards,
>>> Venu
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109