Kohsuke Kawaguchi wrote:
> Vivek Pandey wrote:
>
>> I tried doing that but preffered this approach as having a helper
>> class - SourceUtils that can be used by SourceMessage and
>> SourceHeader that composes with it.
>
>
> OK, if you considered that approach and decided not to take it, I
> guess I'm fine, then.
>
I will take another look and try to see what can be done.
>>> I think StreamSource can be turned into the current StreamMessage,
>>> and chances are DOMMessage and SAXMessage would look very different
>>> to each other that warrants a separate implementation.
>>>
>> Thats right. In the current approach thats what is done. For
>> StreamSource a StreamMessage is used.
>
>
> I actually then realized that StreamMessage might not really work. I
> thought here we'd like to use StreamSource as the payload, whereas
> StreamMessage is about using a stream as a whole envelope.
>
I dont see StreamMessage implemented that way - I see it as being
implemented as to work with payload.
>
>>> I think it makes the code easier to follow as well as faster.
>>>
>> Probably easier to read, but why do you think faster. There nothing
>> that the current SourceMessage does would be slower unless I am
>> missing something.
>
>
> I guess I just feel that it's the right abstraction. For example since
> you already sniffed the source once at the beginning, using separate
> message implementation would allow code to get to the right processing
> code in just one virtual method invocation (like
> Message.getNamespaceURI), whereas currently you are paying one virtual
> method invocation + flag look up.
>
> And if you have separate implementations for separate Source types,
> you can mostly avoid casting like
>
> SAXSource saxSrc = (SAXSource)src;
>
Ok. I think in the code its done at few places, then it can be worked to
do only once during construction.
> Different Source also calls for different data structure. For example,
> if you got DOMSource, you don't need nsUri and localName kept around.
> Node.getNamespaceURI() is just as fast.
>
> And then there's the cost of a separate SourceUtils object.
>
> But I don't feel that strongly. I suspect the difference it makes is
> not that big, and we don't even know if this is in the critical path.
>
It definitely will be used by Dispatch and with LogicalHandlers. I will
take another look at it and see how all different things can fit
togather - SourcEMessage for payload vs protocol message for different
kinds of Sources.
-vivek.
> So I'm fine to keep it as is....
>
--
Vivek Pandey
Web Services Standards and Technologies
Sun Microsystems Inc.