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/
