Paul Sandoz wrote:
> 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:
>
Typically, start parameter tells which part is SOAP part if present
otherwise its always the first part.
> 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.
>
Not really. the MIME parts cant be assumed to be in a particular order.
> 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.
I dont see how will that help? It all depends on the infoset as to when
jaxb asks for a swaref part or mtom part data. Yes, a WSDL MIME part can
be put last because this would be needed only at the time of unpacking
or SOAP message -> parameters.
>
>
>> (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.
>
>
I would thnik so, otherwise we need to create new transport pipe for
every request.
-vivek.
>>
>>> 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.
>
--
Vivek Pandey
Web Services Standards and Technologies
Sun Microsystems Inc.