Paul Sandoz wrote:
> Hi,
>
> Vivek and i agreed that for stream-based attachment decoding there
> should be a AttachmentStreamSOAPDecoder that can either inherit from or
> delegate to StreamSOAPDecoder for processing the SOAP message part.
Sounds like a good idea.
> We want to use the Boyer More MIME multipart parsing code. For
> expediency intially we can buffer the whole message into memory and mark
> all parts and create Attachment wrappers. Later we can work out smarter
> ways with lazy marking (although since Grizzly buffers the whole message
> anyway as long as we can access the byte array there is no need for lazy
> marking).
+1. As long as we can make sure that such improvement can be done (as a
design validation), we don't have to do all the hard work right away.
(But sometimes only way to know if it's possible is to actually do it,
which makes things complicated...)
> We may need a Decoder factory to create the appropriate Decoder
> implementation given the content type. However, the pipeline will also
> dictate what Decoder implementation to use e.g. using SAAJ or stream. So
> we may need different factories per pipeline configuration.
Yes. We need some way to bridge content-type to Decoder. Whether it
needs to be factory (which suggests pluggability), or it can be just a
map, I don't know.
> There can also be an attachment-based XMLStreamReaderEx implementation
> that processes XOP infoset. This requires an XMLStreamReader wrapper
> that delegates to an underlying XMLStreamReader implementation like SJSXP.
Yep.
> The same XMLStreamReaderEx interface can also be used for FI to return
> binary data.
Yes. I think maybe XMLStream(Reader|Writer)Ex needs to live outside
JAX-WS, so that other projects can import them --- I want to use them
from JAXB, too, for example.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com