Hi Brian,
On 05-Aug-2011, at 9:33 AM, Brian Joh wrote:
> Hello,
>
> Excuse me if this is not the appropriate mailing list....
>
>
This is the right mailing list. Thanks for the detailed mail..
> For several months, we've been working with the SAAJ package built into the Sun JDK 6 to parse incoming SOAP messages with attachments. We found some issues, so recently we've been using and fixing the problems in the SAAJ Standard Implementation.
>
> 1. If the "start" parameter in the document Content-Type is not surrounded by angle brackets, the root part will not be found, and an Exception will be thrown. This issue is already open in your JIRA as SAAJ-59 and a patch for this problem exists (but not yet applied), so I won't provide our workaround. However, please see the attached "missing-angle-brackets.txt" for a simple example of the problem. And I believe this is not valid MIME but we have seen this problem quite a bit.
>
Will apply the fix soon.
> 2. This next problem only occurs when "saaj.mime.optimization" is turned off (so Javamail is used for MIME parsing), but the problem is in SAAJ not JavaMail. When "start" is specified in the document's Content-Type , and one of the parts does not have a Content-ID header, a NullPointerException will be thrown. That is, when the "start" is specified, the code assumes each part has a Content-ID. We don't see this problem often because usually in a multipart-related each part will has a Content-ID to allow the parts to be "related". However, MIME parts can also be referenced through Content-Location instead of Content-ID, and that's when the problem can crop up Please note again that this code path is only followed when "saaj.mime.optimization" is set to false, but the problem is in the SAAJ code, not JavaMail. I've attached an example in "missing-cid.txt" and a patch in "MessageImpl.java.missing-cid.patch".
>
OK.
> 3. An Exception will be thrown when "saaj.mime.optimization" is set to true and there are extra whitespace characters after a MIME boundary (and before the CR LF). The example is in "extra-boundary-white-space.txt". We fixed it by setting "saaj.mime.optimization" to false (and using JavaMail for MIME parsing), so I don't have a patch.
>
I shall fix this one.
>
> The next few issues were identified while parsing examples from various notes/specs, such as http://www.w3.org/TR/SOAP-attachments. They are less critical, because we haven't seen the problems with real SOAP clients yet, so I haven't created fixes. But the operative word is "yet".
>
> 1. In the document Content-Type, an exception is thrown when the "type" parameter's value (e.g text/xml) is not surrounded by quotes. The code sees the "/" as a delimiter and interprets the value as three separate tokens ("text" "/" "xml" ). Please see the attached "missing-quotes.txt" for an example. I'm not sure if this is valid MIME or not.
This is bad, there is no need to surround the type parameter in quotes. I shall fix this.
>
> 2. The Content-Type is not interpreted properly when upper case characters are used (e.g "Multipart/Related"). I've concocted an example in "mixed-case-content-type.txt", where the "start" parameter in the Content-Type is ignored. This causes an Exception when the first part is not the start/SOAP part.
>
Matching of media type and subtype should be case insensitive. Will fix it.
Your .txt however is not using mixed case : Content-Type: multipart/related
> 3. In folded or wrapped MIME headers, only the first line is being recognized In the attached "folded-content-type.txt", I've concocted another example where the start parameter in the Content-Type is ignored. And again this causes an Exception when the SOAP part is not the first part.
We do have a MimeUtility class that can handle folding and unfolding of headers. Looks like we are not using it for the Content-Type. Will look into it.
>
> If you prefer, I can also submit these issues into your JIRA.
>
Ultimately i need to have bugs for all these so i can get them integrated to various releases. I can file the bugs myself with the info you have provided.
>
> Finally, I have some questions:
>
> 1. From what I understand, the SAAJ Standard Implementation is incorporated into many projects. It's incorporated into Project Metro, which is used by Glassfish, which then gets pulled into the OpenJDK. And I can tell that the SUN JDK SAAJ version is very similar, maybe even almost identical, to the SAAJ Standard Implementation, but they are not totally the same. So what is the relationship between SAAJ standard implementation and the SAAJ version packaged in the SUN JDK? And how soon can we expect bug fixes made in the SAAJ Standard Implementation to be pulled into SUN JDK releases and/or OpenJDK releases. How soon can we expect a stable stand-alone release of the Standard Implementation that incorporates these fixes?
I can do a stable standalone release and publish to maven as soon as i am done. Integrating to Glassfish will happen soon as well though it will be integrated into Trunk of GlassFish. Integrating to JDK 6 Update releases and JDK7 will take a little longer since they have longer uptake cycles.
>
> 2. Since SAAJ is built into Sun JDK 6, we've been dropping the SAAJ Standard Implementation into our lib/endorsed directory. And we also overrode the SAAJ implementation by setting properties such as "javax.xml.soap.SOAPFactory", "javax.xml.soap.MessageFactory", "javax.xml.soap.SOAPConnectionFactory". Are there any other ways to incorporate the SAAJ Standard Implementation into a JDK 6/7 application?
>
The endorsed mechanism is the only way when you want to use a different impl.
Thanks again for the feedback, i shall work on making a stable standalone release with these fixes soon. And try to get them into the next JDK6/7 cycles.
regards,
kumar
> Keep up the good work and thank you!
>
> Brian Joh
> Software Engineer
> Twitter Mobile
> http://twitter.com/brianwjoh
>
> <missing-angle-brackets.txt><missing-cid.txt><MessageImpl.java.missing-cid.patch><extra-boundary-white-space.txt><missing-quotes.txt><mixed-case-content-type.txt><folded-content-type.txt>