axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
Subject Re: [Axis2] MTOM Works with Chunking & (partially) with Commons HTTP
Date Fri, 08 Jul 2005 15:46:58 GMT
+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 <davanum@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/
>

Mime
View raw message