You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/10/12 19:07:12 UTC
Fixing javamail (again)
There have been 3 javamail questions on the user list in recent weeks
about how to resolve a NoSuchProviderException trying to use SMTP.
These problems all had the same root cause, having the javax.mail and
the provider implementations in separate jar files. It's not obvious to
most people that the dependency requirement exists and occasionally,
even adding the dependency doesn't fix the problem. There was a recent
problem of trying to use javamail from a Quartz job class where it was
necessary to explicitly set the context classloader before requesting a
transport instance to ensure the correct class loader was getting used.
This was a situation that could not occur with the Sun javamail
implementation because the api code and the providers are contained in
the same jar file.
This problem can be easily corrected if we just switched the references
to the javamail spec file to the geronimo-javamail_1.3_mail uber jar
that contains the merged spec and provider classes. More and more users
are tripping over this problem, which can be very easily corrected. Are
there any objections to making this change in 1.2?
Rick
Re: Fixing javamail (again)
Posted by Bill James <wi...@codics.com>.
Something that worked for me:
I have a Liferay war, 4.3.1-trunk, running inside Geronimo-Tomcat 1.1.1. In
order to get the smtp mailer working, it was necessary to add the following
dependency to geronimo-web.xml:
<dependency>
<groupId>geronimo</groupId>
<artifactId>javamail</artifactId>
<version>1.1.1</version>
<type>car</type>
</dependency>
The following bug report was key to getting things working:
http://issues.apache.org/jira/browse/GERONIMO-2498
based on debug diags I was evaluating that showed:
"Unable to locate provider for protocol: smtp"
when invoking session instance of:
javax.mail.Transport.send(...)
The war declares a gbean in geronimo-web.xml as:
<resource-ref>
<ref-name>mail/MailSession</ref-name>
<resource-link>LiferayMailSession</resource-link>
</resource-ref>
<gbean name="LiferayMailSession"
class="org.apache.geronimo.mail.MailGBean">
<attribute name="transportProtocol">smtp</attribute>
<attribute name="host">my-mail-server</attribute>
</gbean>
with the following dependencies:
<dependency>
<groupId>geronimo</groupId>
<artifactId>geronimo-mail</artifactId>
<type>jar</type>
<import>classes</import>
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-javamail_1.3.1_spec</artifactId>
<type>jar</type>
<import>classes</import>
</dependency>
and referenced in web.xml as:
<resource-ref>
<res-ref-name>mail/MailSession</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
</resource-ref>
- bvj
Christopher M. Cardona wrote:
> I would like to do the same change for trunk. Anybody got
> issues/concerns/objections to this?
There's an open JIRA for doing this that's marked as a "wish item".
http://issues.apache.org/jira/browse/GERONIMO-2498
I'd say go for it.
Rick
--
View this message in context: http://www.nabble.com/Fixing-javamail-%28again%29-tf2431708s134.html#a11734805
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Fixing javamail (again)
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Thanks Rick. Checked in the changes to:
- trunk: rev. 486492
- branches/2.0-M1: 486577
Rick McGuire wrote:
> Christopher M. Cardona wrote:
>> I would like to do the same change for trunk. Anybody got
>> issues/concerns/objections to this?
> There's an open JIRA for doing this that's marked as a "wish item".
> http://issues.apache.org/jira/browse/GERONIMO-2498
>
> I'd say go for it.
>
> Rick
>
>>
>> Best wishes,
>> chris
>>
>> Rick McGuire wrote:
>>> There have been 3 javamail questions on the user list in recent
>>> weeks about how to resolve a NoSuchProviderException trying to use
>>> SMTP. These problems all had the same root cause, having the
>>> javax.mail and the provider implementations in separate jar files.
>>> It's not obvious to most people that the dependency requirement
>>> exists and occasionally, even adding the dependency doesn't fix the
>>> problem. There was a recent problem of trying to use javamail from
>>> a Quartz job class where it was necessary to explicitly set the
>>> context classloader before requesting a transport instance to ensure
>>> the correct class loader was getting used. This was a situation
>>> that could not occur with the Sun javamail implementation because
>>> the api code and the providers are contained in the same jar file.
>>> This problem can be easily corrected if we just switched the
>>> references to the javamail spec file to the
>>> geronimo-javamail_1.3_mail uber jar that contains the merged spec
>>> and provider classes. More and more users are tripping over this
>>> problem, which can be very easily corrected. Are there any
>>> objections to making this change in 1.2?
>>>
>>> Rick
>>>
>>
>>
>
>
Re: Fixing javamail (again)
Posted by Rick McGuire <ri...@gmail.com>.
Christopher M. Cardona wrote:
> I would like to do the same change for trunk. Anybody got
> issues/concerns/objections to this?
There's an open JIRA for doing this that's marked as a "wish item".
http://issues.apache.org/jira/browse/GERONIMO-2498
I'd say go for it.
Rick
>
> Best wishes,
> chris
>
> Rick McGuire wrote:
>> There have been 3 javamail questions on the user list in recent weeks
>> about how to resolve a NoSuchProviderException trying to use SMTP.
>> These problems all had the same root cause, having the javax.mail and
>> the provider implementations in separate jar files. It's not obvious
>> to most people that the dependency requirement exists and
>> occasionally, even adding the dependency doesn't fix the problem.
>> There was a recent problem of trying to use javamail from a Quartz
>> job class where it was necessary to explicitly set the context
>> classloader before requesting a transport instance to ensure the
>> correct class loader was getting used. This was a situation that
>> could not occur with the Sun javamail implementation because the api
>> code and the providers are contained in the same jar file.
>> This problem can be easily corrected if we just switched the
>> references to the javamail spec file to the
>> geronimo-javamail_1.3_mail uber jar that contains the merged spec and
>> provider classes. More and more users are tripping over this
>> problem, which can be very easily corrected. Are there any
>> objections to making this change in 1.2?
>>
>> Rick
>>
>
>
Re: Fixing javamail (again)
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
I would like to do the same change for trunk. Anybody got
issues/concerns/objections to this?
Best wishes,
chris
Rick McGuire wrote:
> There have been 3 javamail questions on the user list in recent weeks
> about how to resolve a NoSuchProviderException trying to use SMTP.
> These problems all had the same root cause, having the javax.mail and
> the provider implementations in separate jar files. It's not obvious
> to most people that the dependency requirement exists and
> occasionally, even adding the dependency doesn't fix the problem.
> There was a recent problem of trying to use javamail from a Quartz job
> class where it was necessary to explicitly set the context classloader
> before requesting a transport instance to ensure the correct class
> loader was getting used. This was a situation that could not occur
> with the Sun javamail implementation because the api code and the
> providers are contained in the same jar file.
> This problem can be easily corrected if we just switched the
> references to the javamail spec file to the geronimo-javamail_1.3_mail
> uber jar that contains the merged spec and provider classes. More and
> more users are tripping over this problem, which can be very easily
> corrected. Are there any objections to making this change in 1.2?
>
> Rick
>
Re: Fixing javamail (again)
Posted by Rick McGuire <ri...@gmail.com>.
Jay D. McHugh wrote:
> Rick McGuire wrote:
>>
>> This problem can be easily corrected if we just switched the
>> references to the javamail spec file to the
>> geronimo-javamail_1.3_mail uber jar that contains the merged spec and
>> provider classes. More and more users are tripping over this
>> problem, which can be very easily corrected. Are there any
>> objections to making this change in 1.2?
>
> I actually did a test of using javamail on the 1.2 snapshot and ended
> up putting in this dependency to make it work:
> <dep:dependency>
> <dep:groupId>org.apache.geronimo.configs</dep:groupId>
> <dep:artifactId>javamail</dep:artifactId>
> <dep:version>1.2-SNAPSHOT</dep:version>
> <dep:type>car</dep:type>
> </dep:dependency>
>
>
> I don't know how that fits in with your suggestion though - but this
> did work for me.
And that's generally the correct solution, although in the case I cited
with Quartz, it wasn't enough to fix it because of the jar file split.
A lot of users trip over this because the javamail spec jar is pulled in
by other components (such as axix), without also pulling in the provider
jar. The missing provider doesn't show up until they attempt to use the
API and they get the exception.
Rick
>
> Jay
>
Re: Fixing javamail (again)
Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Rick McGuire wrote:
>
> This problem can be easily corrected if we just switched the
> references to the javamail spec file to the geronimo-javamail_1.3_mail
> uber jar that contains the merged spec and provider classes. More and
> more users are tripping over this problem, which can be very easily
> corrected. Are there any objections to making this change in 1.2?
I actually did a test of using javamail on the 1.2 snapshot and ended up
putting in this dependency to make it work:
<dep:dependency>
<dep:groupId>org.apache.geronimo.configs</dep:groupId>
<dep:artifactId>javamail</dep:artifactId>
<dep:version>1.2-SNAPSHOT</dep:version>
<dep:type>car</dep:type>
</dep:dependency>
I don't know how that fits in with your suggestion though - but this did
work for me.
Jay