axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [Axis2] Show stoppers for Axis2 1.0
Date Sat, 08 Apr 2006 08:05:17 GMT
Given that this is not going to affect the external APIs of Axis2 in any
way, I think this is not an issue for 1.0. Do you guys agree?

Sanjiva.

On Sat, 2006-04-08 at 13:42 +0600, Thilina Gunarathne wrote:
> 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