Error during forward from MailList member

[cballew]

I have a maillist with two non local members. when it tries to forward something sent to the list to our internal mail servers I get the following:

15:35:19,736 ERROR [SMTPSender] Error sending mail
javax.mail.MessagingException: IOException while sending message;
nested exception is:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type text/plain; charset=US-ASCII
at com.sun.mail.smtp.SMTPTransport.sendMessage(Ljavax.mail.Message;[Ljavax.mail.Address;)V(SMTPTransport.java:421)
at org.jboss.mail.smtp.sender.SMTPSender$Sender.recursiveSend()V(SMTPSender.java:610)
at org.jboss.mail.smtp.sender.SMTPSender$Sender.sendMessage()Ljava.util.ArrayList;(SMTPSender.java:565)
at org.jboss.mail.smtp.sender.SMTPSender.sendForDomain([Lorg.jboss.mail.message.MailAddress;Lorg.jboss.mail.message.Mail;)Ljava.util.ArrayList;(SMTPSender.java:396)
at org.jboss.mail.smtp.sender.SMTPSender.send(Lorg.jboss.mail.message.Mail;[Lorg.jboss.mail.message.MailAddress;)[Lorg.jboss.mail.smtp.sender.SMTPResult;(SMTPSender.java:247)
at org.jboss.mail.mailhandler.remote.RemoteDeliveryMessageDrivenBean.deliver(Lorg.jboss.mail.mailbox.MailboxManager;[Lorg.jboss.mail.message.MailAddress;Lorg.jboss.mail.message.Mail;)[Lorg.jboss.mail.smtp.sender.SMTPResult;(RemoteDeliveryMessageDrivenBean.java:170)
at org.jboss.mail.mailhandler.remote.RemoteDeliveryMessageDrivenBean.onMessage(Ljavax.jms.Message;)V(RemoteDeliveryMessageDrivenBean.java:99)
at jrockit.reflect.NativeMethodInvoker.invoke0(Ljava.lang.Object;ILjava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
at org.jboss.invocation.Invocation.performCall(Ljava.lang.Object;Ljava.lang.reflect.Method;[Ljava.lang.Object;)Ljava.lang.Object;(Invocation.java:345)
at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(MessageDrivenContainer.java:475)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(CachedConnectionInterceptor.java:185)
at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(MessageDrivenInstanceInterceptor.java:87)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(CallValidationInterceptor.java:48)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Lorg.jboss.invocation.Invocation;Z)Ljava.lang.Object;(AbstractTxInterceptor.java:105)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(TxInterceptorCMT.java:316)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(TxInterceptorCMT.java:149)
at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(RunAsSecurityInterceptor.java:95)
at org.jboss.ejb.plugins.LogInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.MessageDrivenContainer.internalInvoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(MessageDrivenContainer.java:389)
at org.jboss.ejb.Container.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(Container.java:854)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(Ljava.lang.Object;Ljava.lang.reflect.Method;[Ljava.lang.Object;Ljavax.transaction.Transaction;Ljava.security.Principal;Ljava.lang.Object;)Ljava.lang.Object;(JMSContainerInvoker.java:920)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(Ljavax.jms.Message;)V(JMSContainerInvoker.java:1213)
at org.jboss.jms.asf.StdServerSession.onMessage(Ljavax.jms.Message;)V(StdServerSession.java:256)
at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(Lorg.jboss.mq.SpyMessage;)V(SpyMessageConsumer.java:877)
at org.jboss.mq.SpyMessageConsumer.addMessage(Lorg.jboss.mq.SpyMessage;)V(SpyMessageConsumer.java:159)
at org.jboss.mq.SpySession.run()V(SpySession.java:351)
at org.jboss.jms.asf.StdServerSession.run()V(StdServerSession.java:180)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run()V(PooledExecutor.java:743)

Any other output that might be useful?

[acoliver]

I'll take a look. Which release (m2rc1? HEAD from date XYZ)?

[cballew]

M2RC1 1/18/2005 JBOSS_MAIL_M2_RC1 label, I get the same results from the latest HEAD build as well. I'm testing aganst JBOSS 4.0.0 latest build.

[cballew]

Also, one other note that may be useful. I tried originating mail clients outlook 2000 sp3 using html and plain text. I also tried mozilla thunderbird version 1.0 (20041206) html and plain text. All with the same results.

[acoliver]

check this out: http://www-106.ibm.com/developerworks/forums/dw_thread.jsp?forum=190&thread=6294&cat=10
and this:
http://www-106.ibm.com/developerworks/forums/dw_thread.jsp?forum=190&thread=6294&cat=10

Any chances that is happening to you? Do you have other apps deployed that might have java-mail or JAF? Possible places to check: classpath priort ot JBoss starting, DefaultLoaderRepository MBean (click on it at http://hostname:8080/jmx-console and it will list the jars). Just for kicks, try scoping the mail.ear classloader (edit mail.ear/META-INF/jboss-app.xml) and stick in <jboss-app><loader-repostiory>jboss.mail:type=ScopedRepository,name=jboss.ear</loader-repository></jboss-app> or whatever you would like to call it (valid mbean name) and give it a whirl (I don't think we depend on anything that prevents you from scoping it).

[cballew]

that was it, the JVM I'm using had its own in the classpath. sorry I wasted your time on this. at least this should aid others to identify that issue. thanks again.

[acoliver]

No man, I appreciate it. You're giving me excuses to rewrite JavaMail (I'm under the impression that it is deficient in performance, simplicity). Besides, thanks for helping make the RC an R. Let me know any other way I can help.

[cballew]

Eureka, sorry Andrew. I thought the issue was fixed, but when it hit the offServer members of the list, it still choked for the same reason. I'm running on Windows Server 2003. I'm sure that was much of this problem. The jdk's jre/lib/ext had its own activation.jar. I followed your original suggestion except this time with the activation.jar to fix the issue and we're forwarding from the list as expected. Thanks again.

[pilhuhn]

cballew: So I understand it correctly, that the problem came from a different activation.jar in your classpath, that came with your VM (which?)

[cballew]

The issue is that it's not a normal part of the JVM release which is why everyone has their own.

The one I needed was the one that shipped with JBoss in my case in the server/default/lib directory, the one I was getting was in my JVM's jre/lib/ext directory. That's what created the compatibility issue between the mail.jar and the activation.jar. That's just my particular case, but on windows with any number of applications having their own copy it's a real case of the jar equivalent to dll hell. "whereis" would have helped me track down the issue quicker and was sorely missed on the windows box.

[acoliver]

activation.jar isn't fast and moreover This smells like freaking ODBC/DM on win32. If anyone has the itch, I have some really prelim structural code on my drive for a replacemnet. Otherwise I have us most likely upgrading to the next JavaMail (streams) for 1.0 and not starting this until 2.0.

Basic plan when we kick it off:

1. Create basic prototype
2. Create a set of strong unit tests with appropriate comments that should generate the bullets in strong spec.
3. dress the comments with a wiki-based spec
4. Formalize the spec
5. Create peformance tests (for this its raw throughput in/out on supported mail types)
6. Create a reference implementation that doesn't suck and has few/if any dependencies.

-andy