On Wed, 2006-04-05 at 15:46 -0400, Deepak Bhole wrote: > 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. >
*bump* Hi, The more I have been looking into this (all done actually, using the mechanism I stated above), the more I realize that it would be redundant. If the stream is always read only upon request (which it is) in the existing code, then providing a getNextStream() from an IncomingAttachmentsStream class provides no additional benefit in terms of performance. Should I finalize and post a patch on this anyway? Or is there a variation of this mechanism that someone would perhaps prefer? Thanks, Deepak
