I'm very unclear as to what works in your example and what doesn't.
I'd appreciate clear answers to the following questions:
As a starting point, I'm assuming that you are using the configuration
in which you have put the sun javamail and activation implementations
into the classpath before or instead of the geronimo ones.
1. If you remove the attribute
<attribute name="debug">true</attribute>
completely, can you send and receive mail?
2. If you include the attribute
<attribute name="debug">true</attribute>
can you send and receive mail, although there is no debug output?
3. If you remove the attribute
<attribute name="debug">true</attribute>
and include an attribute
<attribute name="properties">mail.debug=true</attribute>
can you send and receive mail, and is there debug output?
There is definitely a bug in the handling of the "debug" attribute, but
you should be able to work around it by using the properties attribute.
It is not clear from your post whether including the explicit debug
attribute results in no mail service or no debug info with working mail
service.
I have not followed the issues of shipping the sun javamail
implementation in depth, but I believe that until very recently the
license definitely prohibited apache from distributing the sun
implementation and that the license has recently changed to make this
issue murky.
Many thanks,
david jencks
On Oct 2, 2005, at 11:00 AM, Neal Sanche wrote:
Okay All,
I have worked quite a lot on this issue, and will try to explain what
my current findings are, so that anyone else trying to get JavaMail
working can avoid the pitfalls. I have tested several versions
(snapshots, and an M5 release candidate) and can only conclude that
JavaMail API support isn't complete yet. If it were complete, you
would be able to do the following:
In your geronimo-application.xml deployment plan add a dependency to
the Geronimo Mail component:
<dependency>
<uri>geronimo/jars/geronimo-mail-1.0-M5.jar</uri>
</dependency>
And Configure two GBeans:
<gbean name="JavaMailProtocol.smtp"
class="org.apache.geronimo.mail.SMTPTransportGBean">
<attribute name="host">192.168.10.10</attribute>
</gbean>
<gbean name="mail/MailSession"
class="org.apache.geronimo.mail.MailGBean">
<attribute name="transportProtocol">smtp</attribute>
<attribute name="useDefault">false</attribute>
<attribute name="debug">true</attribute>
<reference
name="Protocols"><name>JavaMailProtocol.smtp</name></reference>
</gbean>
Then in a Stateless Session Bean's Object JavaDocs you can put this
XDoclet tag:
* @ejb.resource-ref description="JavaMail Resource"
* res-ref-name="mail/MailSession"
* res-type="javax.mail.Session" res-auth="Container"
* res-sharing-scope="Shareable"
Or, if you're still using Deployment Descriptors directly, something
like the following in your ejb-jar.xml would work:
<resource-ref >
<description><![CDATA[JavaMail Resource]]></description>
<res-ref-name>mail/MailSession</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Okay, so why in the world doesn't this work? Well, there's no actual
providers available in Geronimo to support the SMTP protocol. So, what
you end up with is an execption that looks like this:
javax.mail.NoSuchProviderException: Unable to locate provider for
protocol: smtp
at javax.mail.Session.getProvider(Session.java:225)
at javax.mail.Session.getTransport(Session.java:331)
at javax.mail.Session.getTransport(Session.java:320)
What's nice is the Geronimo developers have gone through and
implemented the javax.mail.Session class and if there were some
providers available it would be possible to tell Geronimo's Mail API
about them and have them used. I've confirmed that it would get that
far, if there were any.
So, why not use the JavaMail reference implementation from Sun? You
could personally do so, yes, download it, put its jars into the
Geronimo repository and you'd be able to do just that. Personally I
downloaded the JavaMail mail.jar and JAF activation.jar and put them
into repository/javamail/jars/ under my Geronimo server root. Then I
added the following dependencies before the geronimo-mail dependency
in my geronimo-application.xml deployment plan like so:
<dependency>
<uri>javamail/jars/mail.jar</uri>
</dependency>
<dependency>
<uri>javamail/jars/activation.jar</uri>
</dependency>
<dependency>
<uri>geronimo/jars/geronimo-mail-1.0-M5.jar</uri>
</dependency>
Now, when I write code like the following in my SLSB bean, it gives me
a Session and I can use it to get a transport and send mail:
InitialContext ctx = null;
try {
ctx = new InitialContext();
javax.mail.Session session =
(Session)ctx.lookup("java:comp/env/mail/MailSession");
MimeMessage mes = new MimeMessage(session);
mes.setFrom(InternetAddress.parse("[EMAIL PROTECTED]")[0]);
mes.setRecipients(RecipientType.TO,"[EMAIL PROTECTED]");
mes.setSubject("Testing");
mes.setSentDate(new Date());
mes.setContent(body,"text/plain");
mes.saveChanges();
Transport transport = session.getTransport();
transport.connect();
transport.sendMessage(mes,InternetAddress.parse("[EMAIL PROTECTED]")
);
transport.close();
} catch (Throwable ex) {
ex.printStackTrace();
} finally {
if (ctx != null) ctx.close();
}
This looks easy enough. But there are problems with this. What's
actually happening behind the scenes here is that the $getResource()
method of the MailGBean is being called to obtain a javax.mail.Session
instance. MailGBean makes a fairly fatal mistake in how it sets up the
Session's default Properties, however. Sun's JavaMail will not accept
any properties that aren't Strings when it goes to parse things. So
although you can see that I set the attribute 'debug' to 'true' in the
MailGBean configuration, above, it is actually converted to a Boolean
object, and that object is put into the properties. And Sun's JavaMail
ignores it because it's not a String.
So that means that although it's nice to have the MailGBean and
associated ProtocolGBean subclasses, the way they build the Properties
for the Session isn't compatible with Sun's JavaMail implementation,
so you can't use it.
So that leaves me with no alternative, at this time, than to add the
JavaMail dependencies, and use Sun's JavaMail API directly to obtain
sessions through the javax.mail.Session.getDefaultInstance() method
instead of the more typical resource-ref and InitialContext.lookup().
As I say, this is how it is with the current state of Geronimo, days
before an M5 release. I'm just reporting... I know it'll get fixed up
soon anyway.
Cheers.
-Neal
