tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
Date Sat, 22 Nov 2003 15:20:05 GMT
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

jun@oop-reserch.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@johncorrigan.net
         OS/Version|Windows NT/2K               |Solaris
           Platform|Other                       |Sun



------- Additional Comments From jun@oop-reserch.com  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: jun@oop-reserch.com
URL:    http://www.oop-reserch.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message