Thilina, i'd suggest you concentrate on cleaning up the code for MTOM and writing more test cases with actual assert statements while we research this a bit more.
for example - there are so many while loops which don't check if there are any more characters in the stream - are u handling unsupposted media exception? are we throwing it. are we catching it? are we handling all the exceptions in the specs? are there test cases for it? - are we handling all the http status codes specified in mtom/xop specs? - why are we createing intermediate ByteArrayOutputstreams and putting things in them. what is going to happen if we get 1 GB attachment or 512 MB soap part? there should not be any intermediate storage especially of things that are likely to grow. - was there any effort to at least architect the code so that we can add mime and SwA later when we get a chance? - Can we get rid of httptransportsender as we talked about earlier? and so on.... -- dims On 7/18/05, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > Earlier I replied to a incorrect thread...Pls bare with me If you receive > this twice ...... > > > > > > > Hi, > > It seems we are going to be *bug-compatible* with WSE3.0 CTP....Below > mentioned is a bug in WSE3.0 in the way it handles Content- ID's. > > > > > > I'm *-1* on changing the way Axis2 handles content-id's for the sake of > interoperability with WSE...... IMO we should stick to the standards..... > > > > > > > > Following is an extract from " Content-ID and Message-ID Uniform Resource > Locators" RFC specifying how to convert a URL to a content-id.... > > > > > > > > A "cid" URL is converted to the corresponding Content-ID message > > header [MIME] by removing the "cid:"; prefix, converting %hh hex- > > escaped characters to their ASCII equivalents and enclosing the > > remaining parts with an angle bracket pair, "<" and ">". For > > example, "mid:[EMAIL PROTECTED]" corresponds to > > > > Message-ID: <[EMAIL PROTECTED]> > > > > According to what I saw in WSE3.0 CTP, it's mime generator is not doing > any of the above mentioned things. They are putting the raw URL as the > content-ID > > > > Following is a message part captured from WSE CTp... > > > > > > Content-Type: multipart/related; > boundary=--MIMEBoundary632572390051733984; > type="application/xop+xml"; > start="cid:[email protected]";; > start-info="text/xml; charset=utf-8; > > > > ----MIMEBoundary632572390051733984 > > > > content-id: cid:[email protected] > > > > content-type: application/xop+xml; charset=utf-8; type="text/xml; > charset=utf-8"content-transfer-encoding: > binary<soap:Envelope> ...... > > <GetChartResult> > > <xop:Include > href="cid:[email protected]"/> > > </GetChartResult></soap:Envelope> > > > > ----MIMEBoundary632572390051733984 > > > > content-id: cid:[email protected] > > > > > > > > According to the RFC above should be > > > > content-id: <[EMAIL PROTECTED] > > > > > > > When it comes to interoperability I feel these are the most important > thigns MTOM implementors have to take care. > > > > URL to the RFC: > > > > http://www.ietf.org/rfc/rfc2111.txt > > Regards, > > ~Thilina > > > > > > > > > > > > On 7/16/05, Davanum Srinivas <[EMAIL PROTECTED] > wrote: > > > Thilina, > > > > > > well, i ended up fixing geronimo. i've updated the geronimo jars to > > > snapshot. (you may need to build them from svn till they update the > > > snapshots for maven). If you have any other problems, let me know. > > > > > > thanks, > > > dims > > > > > > On 7/15/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > > Thilina, > > > > > > > > best way to do this is to get patches to geronimo. Could u spend say > > > > 30 mins and let me know? we need to get geronimo fixes in ASAP. > > > > > > > > -- dims > > > > > > > > On 7/15/05, Thilina Gunarathne < [EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > > Today when i tried to run the MTOM test cases I found out that they > are > > > > > failing and MTOM is not working :( . I know this is unavoidable with > the > > > > > changes we are doing to other modules, unless we have a way to test > MTOM. > > > > > > > > > > I think it's better If we can come up with a way to run MTOM test > cases > > > > > whenever we are doing a commit. (For the moment MTOM test cases have > been > > > > > excluded due to unavailability of JavaMail & Activation). A > separate maven > > > > > goal, for which we guarantee to the presence of java mail & > activation, will > > > > > be a fine solution for this. If not we'll continuously face this > problem... > > > > > > > > > > Devs, > > > > > Till we have a mechanism to test MTOM pls be carefull with ur > > > > > changes.......Specially OM and Transport packages.. > > > > > > > > > > ~Thilina > > > > > > > > > > -- > > > > > "May the SourcE be with u" > > > > > http://www.bloglines.com/blog/thilina > > > > > > > > > > > > -- > > > > Davanum Srinivas -http://blogs.cocoondev.org/dims/ > > > > > > > > > > > > > -- > > > Davanum Srinivas - http://blogs.cocoondev.org/dims/ > > > > > > > > > > > -- > > > > "May the SourcE be with u" > > http://www.bloglines.com/blog/thilina > > > > > > -- > "May the SourcE be with u" > http://www.bloglines.com/blog/thilina -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
