axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thilina Gunarathne" <cset...@gmail.com>
Subject Re: [Axis2] Show stoppers for Axis2 1.0
Date Sat, 08 Apr 2006 07:42:39 GMT
Hi Depak,
My apologies for the very late response.. I was planning to write a
detailed a response to your proposal, but wasn't able till now :(..

IMHO we need to do some internal tweekings of the mime parser in order
to achive the attachment streaming capability.. Currently we use Java
Mail to parse the content inside mime parts.. (content between the two
boundaries)..Our parser do the parsing up the boundaries.. AFAIK java
mail reads the whole MIME part whenever we create a MIMEPart... We'll
be returning an already read and buffered stream to the user If we go
ahead with this setup..

Inorder to give the user access to the pure  attachments from the
instream, we need have the ability of deffrred parsing those MIMEparts
too... This basically means we need to improve our mime parser even to
parse the contents inside the MIMEParts too, so that we get the
capability to handle the stream in to Axis2.. Then we can just parse
the headers of the MIME part and wait at that point.. So that we can
return the real stream directly to the user  when he requests it..

Did you addressed the above issue.. If so the perfomance will
definitely be improved..

~Thilina

On 4/8/06, Deepak Bhole <dbhole@redhat.com> wrote:
> 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
>
>


--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/                
http://www.bloglines.com/blog/Thilina

Mime
View raw message