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 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 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;
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.
So I'm fine to keep it as is....
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com