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 Thilina Gunarathne <cs...@gmail.com> on 2005/07/08 12:30:31 UTC
[Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Hi all,
I tested our MTOM impl with chunking enabled. It worked well :). Binary mime
parts went as separate big chunks.
After some fixes we were able to get MTOM working with Commons-Http
transport, but only for small attachments. When we tried to use with
moderate sized attachments it gives an exception when reading the Mime
parts(Stream not available). I think the problem arises with our deferred
reading of Mime Parts. May be the Commons transport closes the stream. If it
is the case this will even cause problems with deferred building of the OM.
Anyway I'll look in to that matter more deeply and give the feedback.
I'm at the Uni today and I can't commit the fixes to commons transport now
itslef. So pls bare with me till i go home ;-).
Thanks & Regards,
~Thilina
--
"May the SourcE be with u"
Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Posted by Davanum Srinivas <da...@gmail.com>.
I know....the mime parser in .NET/WSE is crappy. remove 2 underscores
from the beginning of mimeBoundary
("----=_AxIs2_Def_boundary_=42214532")
thanks,
-- dims
On 7/9/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> Hi,
> Commited the changes to CommonsHttpSender.
> I found a copy of VS2005 beta 2 form our uni. Now I'm trying to send a
> request to that sample using commonsHttp. Still i get a 400 Bad Request.
>
> Thanks,
> ~Thilina
>
>
>
> On 7/8/05, Srinath Perera <he...@gmail.com> wrote:
> > +1 for commons transport sender and depricating the our thingy
> >
> > I got to admit I do not like http client jar in the needed list .. yet
> > I know what happens with Axis 1.x and I agree to your point. yep we
> > are here to write the SOAP stack not a http transport
> > Thanks
> > Srinath
> >
> > On 7/8/05, Davanum Srinivas < davanum@gmail.com> wrote:
> > > Thanks, i will pick it up as soon as you check in your code and try
> > > against the .NET server am working with.
> > >
> > > -- dims
> > >
> > > On 7/8/05, Thilina Gunarathne < csethil@gmail.com> wrote:
> > > > Hi,
> > > > I am +1 on using a default transport sender. I too have spent so many
> hours
> > > > integrating MTOM in to our transports architecture. In that we had to
> use
> > > > lot of switches at various places, making the things much more
> complicated ,
> > > > and also confused me in a big way.
> > > >
> > > > What i feel is having so many transport options without a clearly
> defined
> > > > architecture will complicate the things & make it hard to plugin new
> > > > improvements like Binary Serialisation........ It's a good idea to use
> > > > CommonsHTTP a s defualt transport, which will keep the things simple
> and
> > > > accurate.
> > > >
> > > > Regarding the problem with MTOM , I'll test with bigger SOAP Envelopes
> and
> > > > see wat'll happen.
> > > >
> > > > Best regards,
> > > > ~Thilina
> > > >
> > > >
> > > >
> > > > On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
> > > > > Thilina, Team,
> > > > >
> > > > > having our own hand-crafted HttpTransportSender is a big mistake. I
> > > > > spent countless hours fighting with Axis1.X custom HTTPSender, you
> > > > > have no idea. As a group, we cannot keep up with testing against all
> > > > > possible combinations. for example, we don't have support for
> "Expect"
> > > > > which is used extensively. Another example is if for some reason the
> > > > > server returns a 400 without a body, we fail miserably. We have to
> > > > > learn from our mistakes with 1.X and start using Commons HTTP from
> > > > > RIGHT now. We can do NTLM via proxies otherwise for example. It's
> just
> > > > > too much to do. In Axis, we are implementing a SOAP engine, not a
> HTTP
> > > > > sending thingy. If testing is our problem, we can use a jetty based
> > > > > simple axis server (see code in Axis 1.X). So let's *PLEASE*
> deprecate
> > > > > our custom http sender and switch completely to Commons HTTP
> transport
> > > > > sender.
> > > > >
> > > > > FYI, if we have problems with Commons HTTP, one of us (me!) has
> commit
> > > > privs.
> > > > >
> > > > > Thanks,
> > > > > dims
> > > > >
> > > > > On 7/8/05, Thilina Gunarathne < csethil@gmail.com> wrote:
> > > > > > Hi all,
> > > > > > I tested our MTOM impl with chunking enabled. It worked well :).
> Binary
> > > > > > mime parts went as separate big chunks.
> > > > > >
> > > > > > After some fixes we were able to get MTOM working with
> Commons-Http
> > > > > > transport, but only for small attachments. When we tried to use
> with
> > > > > > moderate sized attachments it gives an exception when reading the
> Mime
> > > > > > parts(Stream not available). I think the problem arises with our
> > > > deferred
> > > > > > reading of Mime Parts. May be the Commons transport closes the
> stream.
> > > > If it
> > > > > > is the case this will even cause problems with deferred building
> of the
> > > > OM.
> > > > > > Anyway I'll look in to that matter more deeply and give the
> feedback.
> > > > > >
> > > > > > I'm at the Uni today and I can't commit the fixes to commons
> transport
> > > > now
> > > > > > itslef. So pls bare with me till i go home ;-).
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > ~Thilina
> > > > > >
> > > > > > --
> > > > > >
> > > > > > "May the SourcE be with u"
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > "May the SourcE be with u"
> > >
> > >
> > > --
> > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > >
> >
>
>
>
> --
>
>
> "May the SourcE be with u"
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi,
Commited the changes to CommonsHttpSender.
I found a copy of VS2005 beta 2 form our uni. Now I'm trying to send a
request to that sample using commonsHttp. Still i get a 400 Bad Request.
Thanks,
~Thilina
On 7/8/05, Srinath Perera <he...@gmail.com> wrote:
>
> +1 for commons transport sender and depricating the our thingy
>
> I got to admit I do not like http client jar in the needed list .. yet
> I know what happens with Axis 1.x and I agree to your point. yep we
> are here to write the SOAP stack not a http transport
> Thanks
> Srinath
>
> On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
> > Thanks, i will pick it up as soon as you check in your code and try
> > against the .NET server am working with.
> >
> > -- dims
> >
> > On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> > > Hi,
> > > I am +1 on using a default transport sender. I too have spent so many
> hours
> > > integrating MTOM in to our transports architecture. In that we had to
> use
> > > lot of switches at various places, making the things much more
> complicated ,
> > > and also confused me in a big way.
> > >
> > > What i feel is having so many transport options without a clearly
> defined
> > > architecture will complicate the things & make it hard to plugin new
> > > improvements like Binary Serialisation........ It's a good idea to use
> > > CommonsHTTP a s defualt transport, which will keep the things simple
> and
> > > accurate.
> > >
> > > Regarding the problem with MTOM , I'll test with bigger SOAP Envelopes
> and
> > > see wat'll happen.
> > >
> > > Best regards,
> > > ~Thilina
> > >
> > >
> > >
> > > On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
> > > > Thilina, Team,
> > > >
> > > > having our own hand-crafted HttpTransportSender is a big mistake. I
> > > > spent countless hours fighting with Axis1.X custom HTTPSender, you
> > > > have no idea. As a group, we cannot keep up with testing against all
> > > > possible combinations. for example, we don't have support for
> "Expect"
> > > > which is used extensively. Another example is if for some reason the
> > > > server returns a 400 without a body, we fail miserably. We have to
> > > > learn from our mistakes with 1.X and start using Commons HTTP from
> > > > RIGHT now. We can do NTLM via proxies otherwise for example. It's
> just
> > > > too much to do. In Axis, we are implementing a SOAP engine, not a
> HTTP
> > > > sending thingy. If testing is our problem, we can use a jetty based
> > > > simple axis server (see code in Axis 1.X). So let's *PLEASE*
> deprecate
> > > > our custom http sender and switch completely to Commons HTTP
> transport
> > > > sender.
> > > >
> > > > FYI, if we have problems with Commons HTTP, one of us (me!) has
> commit
> > > privs.
> > > >
> > > > Thanks,
> > > > dims
> > > >
> > > > On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> > > > > Hi all,
> > > > > I tested our MTOM impl with chunking enabled. It worked well :).
> Binary
> > > > > mime parts went as separate big chunks.
> > > > >
> > > > > After some fixes we were able to get MTOM working with
> Commons-Http
> > > > > transport, but only for small attachments. When we tried to use
> with
> > > > > moderate sized attachments it gives an exception when reading the
> Mime
> > > > > parts(Stream not available). I think the problem arises with our
> > > deferred
> > > > > reading of Mime Parts. May be the Commons transport closes the
> stream.
> > > If it
> > > > > is the case this will even cause problems with deferred building
> of the
> > > OM.
> > > > > Anyway I'll look in to that matter more deeply and give the
> feedback.
> > > > >
> > > > > I'm at the Uni today and I can't commit the fixes to commons
> transport
> > > now
> > > > > itslef. So pls bare with me till i go home ;-).
> > > > >
> > > > > Thanks & Regards,
> > > > > ~Thilina
> > > > >
> > > > > --
> > > > >
> > > > > "May the SourcE be with u"
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > "May the SourcE be with u"
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >
>
--
"May the SourcE be with u"
Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Posted by Srinath Perera <he...@gmail.com>.
+1 for commons transport sender and depricating the our thingy
I got to admit I do not like http client jar in the needed list .. yet
I know what happens with Axis 1.x and I agree to your point. yep we
are here to write the SOAP stack not a http transport
Thanks
Srinath
On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
> Thanks, i will pick it up as soon as you check in your code and try
> against the .NET server am working with.
>
> -- dims
>
> On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> > Hi,
> > I am +1 on using a default transport sender. I too have spent so many hours
> > integrating MTOM in to our transports architecture. In that we had to use
> > lot of switches at various places, making the things much more complicated ,
> > and also confused me in a big way.
> >
> > What i feel is having so many transport options without a clearly defined
> > architecture will complicate the things & make it hard to plugin new
> > improvements like Binary Serialisation........ It's a good idea to use
> > CommonsHTTP a s defualt transport, which will keep the things simple and
> > accurate.
> >
> > Regarding the problem with MTOM , I'll test with bigger SOAP Envelopes and
> > see wat'll happen.
> >
> > Best regards,
> > ~Thilina
> >
> >
> >
> > On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
> > > Thilina, Team,
> > >
> > > having our own hand-crafted HttpTransportSender is a big mistake. I
> > > spent countless hours fighting with Axis1.X custom HTTPSender, you
> > > have no idea. As a group, we cannot keep up with testing against all
> > > possible combinations. for example, we don't have support for "Expect"
> > > which is used extensively. Another example is if for some reason the
> > > server returns a 400 without a body, we fail miserably. We have to
> > > learn from our mistakes with 1.X and start using Commons HTTP from
> > > RIGHT now. We can do NTLM via proxies otherwise for example. It's just
> > > too much to do. In Axis, we are implementing a SOAP engine, not a HTTP
> > > sending thingy. If testing is our problem, we can use a jetty based
> > > simple axis server (see code in Axis 1.X). So let's *PLEASE* deprecate
> > > our custom http sender and switch completely to Commons HTTP transport
> > > sender.
> > >
> > > FYI, if we have problems with Commons HTTP, one of us (me!) has commit
> > privs.
> > >
> > > Thanks,
> > > dims
> > >
> > > On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> > > > Hi all,
> > > > I tested our MTOM impl with chunking enabled. It worked well :). Binary
> > > > mime parts went as separate big chunks.
> > > >
> > > > After some fixes we were able to get MTOM working with Commons-Http
> > > > transport, but only for small attachments. When we tried to use with
> > > > moderate sized attachments it gives an exception when reading the Mime
> > > > parts(Stream not available). I think the problem arises with our
> > deferred
> > > > reading of Mime Parts. May be the Commons transport closes the stream.
> > If it
> > > > is the case this will even cause problems with deferred building of the
> > OM.
> > > > Anyway I'll look in to that matter more deeply and give the feedback.
> > > >
> > > > I'm at the Uni today and I can't commit the fixes to commons transport
> > now
> > > > itslef. So pls bare with me till i go home ;-).
> > > >
> > > > Thanks & Regards,
> > > > ~Thilina
> > > >
> > > > --
> > > >
> > > > "May the SourcE be with u"
> > >
> > >
> > > --
> > > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> > >
> >
> >
> >
> > --
> >
> > "May the SourcE be with u"
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Posted by Davanum Srinivas <da...@gmail.com>.
Thanks, i will pick it up as soon as you check in your code and try
against the .NET server am working with.
-- dims
On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> Hi,
> I am +1 on using a default transport sender. I too have spent so many hours
> integrating MTOM in to our transports architecture. In that we had to use
> lot of switches at various places, making the things much more complicated ,
> and also confused me in a big way.
>
> What i feel is having so many transport options without a clearly defined
> architecture will complicate the things & make it hard to plugin new
> improvements like Binary Serialisation........ It's a good idea to use
> CommonsHTTP a s defualt transport, which will keep the things simple and
> accurate.
>
> Regarding the problem with MTOM , I'll test with bigger SOAP Envelopes and
> see wat'll happen.
>
> Best regards,
> ~Thilina
>
>
>
> On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
> > Thilina, Team,
> >
> > having our own hand-crafted HttpTransportSender is a big mistake. I
> > spent countless hours fighting with Axis1.X custom HTTPSender, you
> > have no idea. As a group, we cannot keep up with testing against all
> > possible combinations. for example, we don't have support for "Expect"
> > which is used extensively. Another example is if for some reason the
> > server returns a 400 without a body, we fail miserably. We have to
> > learn from our mistakes with 1.X and start using Commons HTTP from
> > RIGHT now. We can do NTLM via proxies otherwise for example. It's just
> > too much to do. In Axis, we are implementing a SOAP engine, not a HTTP
> > sending thingy. If testing is our problem, we can use a jetty based
> > simple axis server (see code in Axis 1.X). So let's *PLEASE* deprecate
> > our custom http sender and switch completely to Commons HTTP transport
> > sender.
> >
> > FYI, if we have problems with Commons HTTP, one of us (me!) has commit
> privs.
> >
> > Thanks,
> > dims
> >
> > On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> > > Hi all,
> > > I tested our MTOM impl with chunking enabled. It worked well :). Binary
> > > mime parts went as separate big chunks.
> > >
> > > After some fixes we were able to get MTOM working with Commons-Http
> > > transport, but only for small attachments. When we tried to use with
> > > moderate sized attachments it gives an exception when reading the Mime
> > > parts(Stream not available). I think the problem arises with our
> deferred
> > > reading of Mime Parts. May be the Commons transport closes the stream.
> If it
> > > is the case this will even cause problems with deferred building of the
> OM.
> > > Anyway I'll look in to that matter more deeply and give the feedback.
> > >
> > > I'm at the Uni today and I can't commit the fixes to commons transport
> now
> > > itslef. So pls bare with me till i go home ;-).
> > >
> > > Thanks & Regards,
> > > ~Thilina
> > >
> > > --
> > >
> > > "May the SourcE be with u"
> >
> >
> > --
> > Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >
>
>
>
> --
>
> "May the SourcE be with u"
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi,
I am +1 on using a default transport sender. I too have spent so many hours
integrating MTOM in to our transports architecture. In that we had to use
lot of switches at various places, making the things much more complicated ,
and also confused me in a big way.
What i feel is having so many transport options without a clearly defined
architecture will complicate the things & make it hard to plugin new
improvements like Binary Serialisation........ It's a good idea to use
CommonsHTTP a s defualt transport, which will keep the things simple and
accurate.
Regarding the problem with MTOM , I'll test with bigger SOAP Envelopes and
see wat'll happen.
Best regards,
~Thilina
On 7/8/05, Davanum Srinivas <da...@gmail.com> wrote:
>
> Thilina, Team,
>
> having our own hand-crafted HttpTransportSender is a big mistake. I
> spent countless hours fighting with Axis1.X custom HTTPSender, you
> have no idea. As a group, we cannot keep up with testing against all
> possible combinations. for example, we don't have support for "Expect"
> which is used extensively. Another example is if for some reason the
> server returns a 400 without a body, we fail miserably. We have to
> learn from our mistakes with 1.X and start using Commons HTTP from
> RIGHT now. We can do NTLM via proxies otherwise for example. It's just
> too much to do. In Axis, we are implementing a SOAP engine, not a HTTP
> sending thingy. If testing is our problem, we can use a jetty based
> simple axis server (see code in Axis 1.X). So let's *PLEASE* deprecate
> our custom http sender and switch completely to Commons HTTP transport
> sender.
>
> FYI, if we have problems with Commons HTTP, one of us (me!) has commit
> privs.
>
> Thanks,
> dims
>
> On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> > Hi all,
> > I tested our MTOM impl with chunking enabled. It worked well :). Binary
> > mime parts went as separate big chunks.
> >
> > After some fixes we were able to get MTOM working with Commons-Http
> > transport, but only for small attachments. When we tried to use with
> > moderate sized attachments it gives an exception when reading the Mime
> > parts(Stream not available). I think the problem arises with our
> deferred
> > reading of Mime Parts. May be the Commons transport closes the stream.
> If it
> > is the case this will even cause problems with deferred building of the
> OM.
> > Anyway I'll look in to that matter more deeply and give the feedback.
> >
> > I'm at the Uni today and I can't commit the fixes to commons transport
> now
> > itslef. So pls bare with me till i go home ;-).
> >
> > Thanks & Regards,
> > ~Thilina
> >
> > --
> >
> > "May the SourcE be with u"
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
--
"May the SourcE be with u"
Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Posted by Davanum Srinivas <da...@gmail.com>.
Thilina, Team,
having our own hand-crafted HttpTransportSender is a big mistake. I
spent countless hours fighting with Axis1.X custom HTTPSender, you
have no idea. As a group, we cannot keep up with testing against all
possible combinations. for example, we don't have support for "Expect"
which is used extensively. Another example is if for some reason the
server returns a 400 without a body, we fail miserably. We have to
learn from our mistakes with 1.X and start using Commons HTTP from
RIGHT now. We can do NTLM via proxies otherwise for example. It's just
too much to do. In Axis, we are implementing a SOAP engine, not a HTTP
sending thingy. If testing is our problem, we can use a jetty based
simple axis server (see code in Axis 1.X). So let's *PLEASE* deprecate
our custom http sender and switch completely to Commons HTTP transport
sender.
FYI, if we have problems with Commons HTTP, one of us (me!) has commit privs.
Thanks,
dims
On 7/8/05, Thilina Gunarathne <cs...@gmail.com> wrote:
> Hi all,
> I tested our MTOM impl with chunking enabled. It worked well :). Binary
> mime parts went as separate big chunks.
>
> After some fixes we were able to get MTOM working with Commons-Http
> transport, but only for small attachments. When we tried to use with
> moderate sized attachments it gives an exception when reading the Mime
> parts(Stream not available). I think the problem arises with our deferred
> reading of Mime Parts. May be the Commons transport closes the stream. If it
> is the case this will even cause problems with deferred building of the OM.
> Anyway I'll look in to that matter more deeply and give the feedback.
>
> I'm at the Uni today and I can't commit the fixes to commons transport now
> itslef. So pls bare with me till i go home ;-).
>
> Thanks & Regards,
> ~Thilina
>
> --
>
> "May the SourcE be with u"
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/