axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [Axis2] Show stoppers for Axis2 1.0
Date Sat, 08 Apr 2006 12:18:02 GMT
+1 i removed it as a blocker.

-- dims

On 4/8/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
> 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
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message