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"
