+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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/ >
