You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Deepak Bhole <db...@redhat.com> on 2006/04/05 21:46:32 UTC
Re: [Axis2] Show stoppers for Axis2 1.0
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
Re: [Axis2] Show stoppers for Axis2 1.0
Posted by Thilina Gunarathne <cs...@gmail.com>.
Ohh.. I just noticed the subject... May be we should move this
conversation under to a new subject :)...
IMO this is not an issue for 1.0..
~Thilina
On 4/8/06, Sanjiva Weerawarana <sa...@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 <db...@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
>
>
--
"May the SourcE be with u"
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
http://www.bloglines.com/blog/Thilina
Re: [Axis2] Show stoppers for Axis2 1.0
Posted by Davanum Srinivas <da...@gmail.com>.
+1 i removed it as a blocker.
-- dims
On 4/8/06, Sanjiva Weerawarana <sa...@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 <db...@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/
Re: [Axis2] Show stoppers for Axis2 1.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <db...@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
Re: [Axis2] Show stoppers for Axis2 1.0
Posted by Deepak Bhole <db...@redhat.com>.
Hi Thilina,
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..
>
Ah, you are right .. I was under the impression that MimeBodyPart only
read the headers, and then didn't read the remainder (i.e. that it
returned the attachment stream part when requested), but that is not the
case :( Looking at the MimeBodyPart code, I see now that the constructor
creates a ByteArrayOutputStream and empties the stream into that.
Eventually, I wanted internal axis2 code handling the stream, but I see
now that that is more of a necessity (for performance) than just another
TODO.
I have some ideas on how to implement things so that the stream is read
dynamically only upon request, and I will start working on that part
now.
As this is not a showstopper anymore, is there anything else blocking
1.0 that I could work on? or should I just continue on with this stream
handling stuff?
Deepak
Re: [Axis2] Show stoppers for Axis2 1.0
Posted by Thilina Gunarathne <cs...@gmail.com>.
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 <db...@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
Re: [Axis2] Show stoppers for Axis2 1.0
Posted by Deepak Bhole <db...@redhat.com>.
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