You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Thilina Gunarathne <cs...@gmail.com> on 2005/07/18 11:20:44 UTC
[Axis2] MIME Content ID handling for MTOM
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:foo4%25foo1@bar.net" corresponds to
>
> Message-ID: <foo4%foo1@bar.net <fo...@bar.net>>
>
> 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:0.632572390051733984@example.org"; start-info="text/xml;
> charset=utf-8;*
>
> *----MIMEBoundary632572390051733984*
>
> *content-id: cid:0.632572390051733984@example.org*
>
> *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:1.632572390052034416@example.org"/>
> </GetChartResult></soap:Envelope>*
>
> *----MIMEBoundary632572390051733984*
>
> *content-id: cid:1.632572390052034416@example.org*
>
> According to the RFC above should be
>
> *content-id: <1....@example.org>*
>
>
> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <cs...@gmail.com> 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
Re: [Axis2] MIME Content ID handling for MTOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 for not being bug-compatible; a key value of open source impls is
sticking to the stds strictly!
Sanjiva.
On Mon, 2005-07-18 at 15:20 +0600, Thilina Gunarathne 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:foo4%25foo1@bar.net" corresponds to
>
> Message-ID: <fo...@bar.net>
>
>
> 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:0.632572390051733984@example.org";
> start-info="text/xml; charset=utf-8;
>
> ----MIMEBoundary632572390051733984
>
> content-id: cid:0.632572390051733984@example.org
>
> 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:1.632572390052034416@example.org"/>
> </GetChartResult></soap:Envelope>
>
> ----MIMEBoundary632572390051733984
>
> content-id: cid:1.632572390052034416@example.org
>
>
>
> According to the RFC above should be
>
> content-id: <1....@example.org>
>
>
> 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 <da...@gmail.com> 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 <da...@gmail.com>
> 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 <cs...@gmail.com>
> 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
Re: [Axis2] MIME Content ID handling for MTOM
Posted by Davanum Srinivas <da...@gmail.com>.
Sanjiva,
Did you read my email? i said explicitly "any effort to at least
architect the code" am not asking us to add support. If i did, i'd
open a JIRA issue, just like i did for others.
-- dims
On 7/18/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2005-07-18 at 11:41 -0400, Davanum Srinivas wrote:
> > > You do agree with the principle of getting the faulty impl corrected,
> > > right?
> >
> > if we determine that it is faulty. then yes. let's not change it for now.
>
> I thought that Thilina's message dump and spec dump showed that it was
> indeed faulty. Unless there's something wrong in his evidence let's push
> on the MSFT folks to fix it. Its still CTP code so I'm sure its
> relatively straightforward, unlike if it was a major released version.
>
> Simon: Can you please take a look at the stuff and let us know your
> interpretation of the spec and the impls please?
>
> > > What did you mean by "mime"?
> >
> > typo i meant dime
>
> DIME is dead'er than the copper penny .. even MSFT has abandoned it. I
> don't see any reason to support it ... esp. not in Axis2. Let's keep
> Axis2 as clean as possible without adding support for "other" stuff.
>
> Sanjiva.
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: [Axis2] MIME Content ID handling for MTOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2005-07-18 at 11:41 -0400, Davanum Srinivas wrote:
> > You do agree with the principle of getting the faulty impl corrected,
> > right?
>
> if we determine that it is faulty. then yes. let's not change it for now.
I thought that Thilina's message dump and spec dump showed that it was
indeed faulty. Unless there's something wrong in his evidence let's push
on the MSFT folks to fix it. Its still CTP code so I'm sure its
relatively straightforward, unlike if it was a major released version.
Simon: Can you please take a look at the stuff and let us know your
interpretation of the spec and the impls please?
> > What did you mean by "mime"?
>
> typo i meant dime
DIME is dead'er than the copper penny .. even MSFT has abandoned it. I
don't see any reason to support it ... esp. not in Axis2. Let's keep
Axis2 as clean as possible without adding support for "other" stuff.
Sanjiva.
Re: [Axis2] MIME Content ID handling for MTOM
Posted by Davanum Srinivas <da...@gmail.com>.
Sanjiva,
On 7/18/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2005-07-18 at 06:27 -0400, Davanum Srinivas wrote:
> > 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.
>
> You do agree with the principle of getting the faulty impl corrected,
> right?
if we determine that it is faulty. then yes. let's not change it for now.
> > 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.
>
> +1 for cleaning up the code.
>
> > - was there any effort to at least architect the code so that we can
> > add mime and SwA later when we get a chance?
>
> A XOP message is supposed to be wire-compatible with SwA. Is that not
> the case?
>
> What did you mean by "mime"?
typo i meant dime
> > - Can we get rid of httptransportsender as we talked about earlier?
> > and so on....
>
> Not directly MTOM related .. in progress but slow week this week because
> Ajith, Chathura and Eran are all at AC Europe.
>
> Sanjiva.
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: [Axis2] MIME Content ID handling for MTOM
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2005-07-18 at 06:27 -0400, Davanum Srinivas wrote:
> 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.
You do agree with the principle of getting the faulty impl corrected,
right?
> 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.
+1 for cleaning up the code.
> - was there any effort to at least architect the code so that we can
> add mime and SwA later when we get a chance?
A XOP message is supposed to be wire-compatible with SwA. Is that not
the case?
What did you mean by "mime"?
> - Can we get rid of httptransportsender as we talked about earlier?
> and so on....
Not directly MTOM related .. in progress but slow week this week because
Ajith, Chathura and Eran are all at AC Europe.
Sanjiva.
Re: [Axis2] MIME Content ID handling for MTOM
Posted by Davanum Srinivas <da...@gmail.com>.
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 <cs...@gmail.com> 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:foo4%25foo1@bar.net" corresponds to
> >
> > Message-ID: <fo...@bar.net>
> >
> > 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:0.632572390051733984@example.org";
> start-info="text/xml; charset=utf-8;
> >
> > ----MIMEBoundary632572390051733984
> >
> > content-id: cid:0.632572390051733984@example.org
> >
> > 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:1.632572390052034416@example.org"/>
> > </GetChartResult></soap:Envelope>
> >
> > ----MIMEBoundary632572390051733984
> >
> > content-id: cid:1.632572390052034416@example.org
> >
> >
> >
> > According to the RFC above should be
> >
> > content-id: <1.632572390052034416@example.org >
> >
> >
> > 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 <davanum@gmail.com > 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 <da...@gmail.com> 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 < csethil@gmail.com> 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/
web service bench mark tool
Posted by md kumara lal <ar...@yahoo.com>.
I am deweloping a web service bench mark tool.While I am doing that I need to acess java written webservicr from C# Client.Please send me some detail how to do that.If possible some example code.Any kind of request is appriciate.
Kind Regards
Madushan Thilina.
---------------------------------
Start your day with Yahoo! - make it your home page