Hi, On Sat, 2006-03-25 at 00:38 -0800, Thilina Gunarathne wrote: > Got ur point about the Attachment streaming support.. I can remember > the earlier conversation too...Even though I thought of trying it out, > unfortunately I wasn't able to do anything use full about it due to > lack of time.. >
I am thinking of adding an IncomingAttachmentStreams object (same as there was in axis1) which will serve as a container for streams. The objects can then use getNextStream() on this object to access the MIME streams. I am wondering if we need an IncomingAttachmentInputStream wrapper object though. IncomingAttachmentStreams, while a stream for containers, will have access to the Part objects directly (and the streams via Part.getDataHandler().getDataSource().getInputStream()). In axis1, the streams had an api which provided getContentType(), getContentId() etc. functions. If there is no IncomingAttachmentInputStream wrapper, there will simply be an InputStream stream, which won't provide those things. I am for creating an IncomingAttachmentInputStream wrapper which will provide those functions... > > being able to treat > > MTOM/XOP messages just like SwA as well. > I think we can do this in the inflow using the MIMEHelper.. I'm > definitely +1 if we can replace it with a consistent API for both > in/out flows. > See above, IncomingAttachmentStreams will be contained inside MIMEHelper, and thus can provide stream access. > >On the server-side say i get > > a 1 MB attachment, don't want to put that into a data handler in > > memory, i just want to stream it directly into whatever my application > > specific wants > Just a suggestion.. We can add another method to the OMText to get the > stream directly.. Even in the current model the actual binary is read > only when the user requests the data..(by calling getDataHandler() or > getText() ). So it won't be hard to get the actual stream directly > from there... > The stream is within DataHandler, and not read until requested. Above mentioned IncomingAttachmentStreams can take care of supplying that stream.. > > OR if i am writing an intermediary i want to access all > > the mime parts by myself > IMO In the case of an intermediary we need to take special care with > the content-id's.. If not the ultimate receiver will go in to trouble > processing the mime parts. > I am still getting to know axis2 .. could you please shed some light on what you are referring to when you say intermediary? > >don't want Axis2 to do any MTOM related > > processing. Please see Axis 1.X API [1] especially the > > Even at this moment Axis2 would create the OMText objects without data > (only with a reference to the data) instead of XOP:Include elements. > Other than this current Axis2 will not do any kind of MTOM specific > processing of mime parts unless asked to do so.. > right.. Base64 re-encoding is done in OMText::getText(), and thus not done until requested (atleast afaik.. I might be off on this one) > > getIncomingAttachmentStreams method that allows direct access to the > > mime parts. > This would be a nice API for somebody who wants to do some low level > processing. But we need to make sure to throw an Exception in the case > a user trying to access them from both API's. If not Axiom will go > nuts looking for the streams.. > In the WIP implementation I have, I have it so that an IllegalStateException is thrown (as in axis1) if the user attempts to access the stream and the parts simultaneously. Thoughts? Deepak
signature.asc
Description: This is a digitally signed message part
