Kohsuke Kawaguchi wrote:
>> 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.
>
I think it is possible.
The SOAP part is read first. If there are any parts before it they need
to be cached. If the reading of the infoset in the SOAP part results in
access to a part after the SOAP part then:
1) on the first time the whole SOAP part is cached, and any parts
between the SOAP part and the part to acccess are cached; or
2) on the second or subsequent time any parts between the SOAP part and
the part to acccess are cached (if not already done so).
When using just MTOM i am not sure caching will always be used needed
because i would expect attachments to be serialized linearly.
I think the interesting case occurs when mixing MTOM and swa:Ref
attachments. We should put the latter as the last parts to avoid
processing until the last minute when they are accessed.
> (But sometimes only way to know if it's possible is to actually do it,
> which makes things complicated...)
>
Yes!
>
>> 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.
>
OK.
Should Encoder/Decoder implementations be stateless? If not i can
improve on the current StreamSOAPDecoder implementation.
>
>> 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.
>
+1 I want to move all the utility methods on XMLStreamReaderUtil to the
new interface.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109