DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073 no object DCH for MIME type text/plain --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 18:52 --- In fact, there is another possible cause for this problem depending on the platform: on Mac OS X (server), the existence of a different version of activation.jar in /Library/Java/ Extensions will cause this error, and no amount of catalina.policy manipulation will clear it up. The solution is to remove /Library/Java/Extensions/activation.jar . (Not sure if this causes other problems on the system, haven't run into any yet.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073 no object DCH for MIME type text/plain [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-11-24 16:55 --- This is not a bug in Tomcat bug a misconfigured catalina.policy for using the JavaMail API. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073
no object DCH for MIME type text/plain
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
OS/Version|Windows NT/2K |Solaris
Platform|Other |Sun
--- Additional Comments From [EMAIL PROTECTED] 2003-11-22 15:20 ---
Hi,
Our client also got the exactly same exception.
Their environment is Tomcat 4.1.12 with:
mail.jar
activation.jar
installed in:
${catalina.home}/shared/lib
Even we placed these JAR files into:
(docBase)/WEB-INF/lib
we still had the same problem.
As you pointed, the implementation of DataContentHandler is available within
activation.jar.
So, I investigated how JavaMail API (Transport class) get DataContentHandler...
According to the Java Doc of Java Activation Framework, DataContentHandler is
available within CommandMap object.
On the CommandMap object, we can query the DataContentHandler object appropriate
for the specified mime-type String.
The code fragment will look like this:
CommandMap cmap=CommandMap.getDefaultCommandMap();
DataContentHandler dch=cmap.createDataContentHandler(text/plain);
The return value of the first line is always MailCapCommandMap.
To create the appropriate DataContentHandler for the given mime-type,
MailCapCommandMap searched the mailcap file in the several places.
According to the Java Doc of Java Activation Framework again, the last place to
be searched is:
META-INF/mailcap.default
that should exist within activation.jar in usual case.
I extracted the activation.jar, but
META-INF/mailcap.default
exists in fact, and its contents also look fine...
The question here is... What prevents this mailcap to be loaded?
The answer on our case is SecurityManager!
If I understand Servlet Spec correctly, the classes marked as Java Extension
should be searched by the parent class-loader at first.
So, when we place activation.jar into:
${catalina.home}/shared/lib
all the classes in Java Activation Framework will be loaded from this JAR file,
even if we place it also in:
(docBase)/WEB-INF/lib
But, with SecurityManager enabled, the classes loaded from:
${catalina.home}/shared/lib/activation.jar
need the read permission for:
${catalina.home}/shared/lib/activation.jar!META-INF/mailcap.default
We updated:
${catalina.home}/conf/catalina.policy
and add:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission /usr/local/tomcat418/shared/lib/-,read;
};
And the problem gone way.
I'm not sure about the details of your environment, but if you run your Tomcat
with SecurityManager, the my solution may help you too.
Any questions are welcome to me.
--
Happy Java programming!
Jun Inamori
OOP-Reserch Corporation
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073
no object DCH for MIME type text/plain
--- Additional Comments From [EMAIL PROTECTED] 2003-11-22 21:05 ---
Hi again,
I was somewhat confused in my previous message.
The definition of mime-type and DCH should be:
META-INF/mailcap
in mail.jar, not
META-INF/mailcap.default
in activation.jar.
And the required entity in catalina.policy will look like this:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
};
Anyway, I re-wrote my message...
-
As you did, our client got the exception like this:
javax.mail.SendFailedException: Sending failed;
nested exception is:
javax.mail.MessagingException: IOException while sending message;
nested exception is:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
text/plain
at javax.mail.Transport.send0(Transport.java:219)
To re-produce it on our development machine, I tried several configurations.
And only when I start Tomcat with ScurityManager, I got the same one.
DCH is short hand of DataContentHandler, and it is responsible for creating
the binary stream that will be sent to the SMTP server.
Because there are many kinds of mail body, the several implementations are
included in mail.jar.
For example, mail.jar shipped with the DataContentHandler for text/plain and
image/jpeg.
When javax.mail.Transport tries to send the e-mail, it creates the
DataContentHandler implementation appropriate for the mime-type of the out-going
e-mail.
The mapping between the mime-map and the class name of DataContentHandler is
defined by:
META-INF/mailcap
in mail.jar, and this mailcap is read by CommandMap object.
For example, to create DataContentHandler implementation for text/plain, your
code will look like this:
CommandMap cmap=CommandMap.getDefaultCommandMap();
DataContentHandler dch=cmap.createDataContentHandler(text/plain);
Then, CommandMap object reads:
META-INF/mailcap
from mail.jar, and creates the DataContentHandler object for text/plain.
This is what is done by javax.mail.Transport to send the e-mails.
By the way, where CommandMap comes from?
Its fully qualified class name is:
javax.activation.CommandMap
Yes, this class is included in activation.jar.
According to Servlet Spec, the classes marked as Java Extension should be
searched by the parent class-loader at first, rather than by the class-loader
for each web application.
So, when we place activation.jar into:
${catalina.home}/shared/lib
all the classes in Java Activation Framework will be loaded from this JAR file,
even if we place it also in:
(docBase)/WEB-INF/lib
To read:
META-INF/mailcap
from:
${catalina.home}/shared/lib/mail.jar
CommandMap object from:
${catalina.home}/shared/lib/activation.jar
needs the read permission to:
${catalina.home}/shared/lib/mail.jar
To make it possible, catalina.policy should include the entity like:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
};
In addition, mail.jar in:
${catalina.home}/shared/lib
needs the Socket permission to access the SMTP server.
So, catalina.policy also need the entities like:
grant codeBase file:${catalina.home}/shared/lib/mail.jar {
permission java.net.SocketPermission localhost, connect,resolve;
};
I'm not sure about the details of your environment, but if you run your Tomcat
with SecurityManager, the my solution may help you too.
Any questions are welcome to me.
Best regards,
--
Happy Java programming!
Jun Inamori
OOP-Reserch Corporation
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073 no object DCH for MIME type text/plain [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |Medium --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 14:15 --- Came across this problem with own code invoking JavaMail, using Tomcat 4.1.24 on Mac OS X, using smtp to localhost sendmail. Same code, jars, environment, etc. works correctly on Tomcat 4.1.24 and 4.1.18 on Linux and Solaris. Verified that mail.jar (including the 'mailcap' meta-inf file) is on classpath, and classes from the jar are being loaded. For example, you can explicitly load com.sun.mail.handlers.text_plain before attempting to use the JavaMail package, to no avail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
