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]
