RE: geronimo mail 1.1.1
Does anybody know how to create JNDI URL resources for files in Geronimo (like file://dir/file.properties) like in Websphere. I believe it is J2EE stantdard. _ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. application/ms-tnef
Re: geronimo mail 1.1.1
Michael C. wrote: Sorry about that, honestly I was not sure exactly where to add one up. How do you add a Jira, and how can I track its progress? New Jiras can be created here: http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 I have a suspicion your problem is a duplicate of this already created issue: http://issues.apache.org/jira/secure/IssueNavigator.jspa?pager/start=20
Re: geronimo mail 1.1.1
We are now finally using the geronimo1.1 jars and the application is trying to send the email but it cannot seem to find our mail.smtp.host property: Loading javamail.default.providers from jar:file:/our path/WEB-INF/lib/geronimo-javamail-transport-1.1.1.jar!/META-INF/javamail.default.providers DEBUG: loading new provider protocol=smtp, className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport, vendor=Apache Software Foundation, version=1.1 DEBUG: loading new provider protocol=smtps, className=org.apache.geronimo.javamail.transport.smtp.SMTPSTransport, vendor=Apache Software Foundation, version=1.1 DEBUG: getProvider() returning provider protocol=smtp; [EMAIL PROTECTED]; class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport; vendor=Apache Software Foundation;version=1.1 SMTPTransport DEBUG: Connecting to server null:-1 for user userId SMTPTransport DEBUG: Attempting plain socket connection to server null:25 220 machineName.domain.com Microsoft ESMTP MAIL Service, Version: 6.0.2600.2180 ready at Wed, 31 Jan 2007 13:36:52 -0500 EHLO machineName 250-machineName.domain.com Hello [127.0.0.1] 250-SIZE 2097152 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250 OK MAIL FROM: [EMAIL PROTECTED] 250 2.1.0 [EMAIL PROTECTED] OK RCPT TO: [EMAIL PROTECTED] 550 5.7.1 Unable to relay for [EMAIL PROTECTED] RSET 250 2.0.0 Resetting QUIT 221 Closing connection. Good bye. We have this setting configured in our properties file that is being read from our mail session. We also added mail.smtp.localhost. How do we tell gerinomo to use our host? Notice the line: Attempting plain socket connection to server null:25 where 25 is the port, but it cannot find the host name. Rick McGuire wrote: Michael C. wrote: We have been using the debug attribute. This is all we get: (I omitted the errors since those are in an earlier thread i sent) Uh, where? I don't see a stack traceback for an authentication exception in any of your earlier emails. Loading javamail.default.providers from jar:file:/our path/lib/geronimo-javamail-transport.jar!/META-INF/javamail.default.providers DEBUG: loading new provider protocol=smtp, className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport, vendor=Apache Software Foundation, version=1.0 H, this isn't correct. The 1.1.1 version of the SMTPTransport should be showing a 1.1 version number. I just went back to the source to verify. Somehow, you're picking up the 1.0 version of the javamail-transport code. The 1.1.1 version is a significant update over the 1.0 version. In particular, it has much better debug support. Rick DEBUG: getProvider() returning provider protocol=smtp; [EMAIL PROTECTED]; class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport; vendor=Apache Software Foundation;version=1.0 When we run this in WebSphere however, we get this debug information: [1/29/07 15:39:32:677 EST] 09a4 SystemOut O DEBUG: setDebug: JavaMail version 1.3.1 [1/29/07 15:39:32:693 EST] 09a4 SystemOut O DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc] [1/29/07 15:39:32:739 EST] 09a4 SystemOut O DEBUG SMTP: useEhlo true, useAuth false [1/29/07 15:39:32:739 EST] 09a4 SystemOut O DEBUG SMTP: trying to connect to host our.host.com, port 25 [1/29/07 15:39:32:833 EST] 09a4 SystemOut O 220 our web server Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Mon, 29 Jan 2007 15:39:32 -0500 [1/29/07 15:39:32:833 EST] 09a4 SystemOut O DEBUG SMTP: connected to host our.mail.host, port: 25 [1/29/07 15:39:32:833 EST] 09a4 SystemOut O EHLO our app server [1/29/07 15:39:32:880 EST] 09a4 SystemOut O 250-our web server Hello [10.155.100.175] 250-TURN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension TURN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension SIZE, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension ETRN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension PIPELINING, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension DSN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension ENHANCEDSTATUSCODES, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension 8bitmime, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension BINARYMIME, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG
Re: geronimo mail 1.1.1
We have been using the debug attribute. This is all we get: (I omitted the errors since those are in an earlier thread i sent) Loading javamail.default.providers from jar:file:/our path/lib/geronimo-javamail-transport.jar!/META-INF/javamail.default.providers DEBUG: loading new provider protocol=smtp, className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport, vendor=Apache Software Foundation, version=1.0 DEBUG: getProvider() returning provider protocol=smtp; [EMAIL PROTECTED]; class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport; vendor=Apache Software Foundation;version=1.0 When we run this in WebSphere however, we get this debug information: [1/29/07 15:39:32:677 EST] 09a4 SystemOut O DEBUG: setDebug: JavaMail version 1.3.1 [1/29/07 15:39:32:693 EST] 09a4 SystemOut O DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc] [1/29/07 15:39:32:739 EST] 09a4 SystemOut O DEBUG SMTP: useEhlo true, useAuth false [1/29/07 15:39:32:739 EST] 09a4 SystemOut O DEBUG SMTP: trying to connect to host our.host.com, port 25 [1/29/07 15:39:32:833 EST] 09a4 SystemOut O 220 our web server Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Mon, 29 Jan 2007 15:39:32 -0500 [1/29/07 15:39:32:833 EST] 09a4 SystemOut O DEBUG SMTP: connected to host our.mail.host, port: 25 [1/29/07 15:39:32:833 EST] 09a4 SystemOut O EHLO our app server [1/29/07 15:39:32:880 EST] 09a4 SystemOut O 250-our web server Hello [10.155.100.175] 250-TURN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension TURN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension SIZE, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension ETRN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension PIPELINING, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension DSN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension ENHANCEDSTATUSCODES, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension 8bitmime, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension BINARYMIME, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension CHUNKING, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension VRFY, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension X-EXPS, arg GSSAPI NTLM LOGIN [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension X-EXPS=LOGIN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension AUTH, arg GSSAPI NTLM LOGIN [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension AUTH=LOGIN, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension X-LINK2STATE, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension XEXCH50, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: Found extension OK, arg [1/29/07 15:39:32:880 EST] 09a4 SystemOut O DEBUG SMTP: use8bit false [1/29/07 15:39:32:880 EST] 09a4 SystemOut O MAIL FROM:[EMAIL PROTECTED] [1/29/07 15:39:32:927 EST] 09a4 SystemOut O 250 2.1.0 [EMAIL PROTECTED] OK [1/29/07 15:39:32:927 EST] 09a4 SystemOut O RCPT TO:[EMAIL PROTECTED] [1/29/07 15:39:32:974 EST] 09a4 SystemOut O 250 2.1.5 [EMAIL PROTECTED] [1/29/07 15:39:32:974 EST] 09a4 SystemOut O DEBUG SMTP: Verified Addresses [1/29/07 15:39:32:974 EST] 09a4 SystemOut O DEBUG SMTP: [EMAIL PROTECTED] [1/29/07 15:39:32:974 EST] 09a4 SystemOut O DATA [1/29/07 15:39:33:021 EST] 09a4 SystemOut O 354 Start mail input; end with CRLF.CRLF [1/29/07 15:39:33:021 EST] 09a4 SystemOut O Message-ID: [EMAIL PROTECTED] app server From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Payment Confirmation - Subject Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rick McGuire wrote: Michael C. wrote: I am working on getting you the exact string for the addRecipient call between other daily endeavors. Meanwhile, we changed our code to use the getInstance() and get the same authentication error. I reviewed the geronimo SMTPTransport class to see what is going on and found these constants: private static final char CR = 13; private static final char LF = 10; private static final String MAIL_HOST = mail.host; private static final String
Re: geronimo mail 1.1.1
Michael C. wrote: We are finally using the SMTPTransport class from Geronimo. We had a mail.jar file on our system path that was being picked up. At this point, we are getting an AuthenticationFailedException. If we do not need a GBEAN configuration, how do we configure our mail server and port number in the plan? Or should we not need to since our application logic is reading this information from an external file and will tranparently pass this information to the geronimo SMTPTransport class. I hate to keep asking the same question over and over again, but I'm afraid I have to. How you configure the transport depends on how you are creating the mail session within your application. This includes setting up authentication information if your target SMTP server requires it. If you are creating the session by doing: Session mySession = Session.getInstance(props); Then you are responsible for configuring things like the server and port number in the property bundle you use to create the session. No GBean configuration is necessary, or even has any effect if you do happen to specify it. If you are using InitialContext.lookup() to get the configured mail session GBean, then you DO need to have a configured mail session and can set up things like the authentication information on the SMTPTransport definition. Below is the new error and includes the form of the email address we were using, which is actually the FROM address, but seems to be treating it as a TO address according to the error: I really would like to see the exact string being set in the API call, not the string reported by the error message. However, an authentication failure us different than the error you were reporting earlier, and indicates you've not provided correct information for accessing the target server. Rick Loading javamail.default.providers from jar:file:/C:/Our Path/Our .war/WEB-INF/lib/geronimo-javamail-transport.jar!/META-INF/javamail.default.providers DEBUG: loading new provider protocol=smtp, className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport, vendor=Apache Software Foundation, version=1.0 DEBUG: getProvider() returning provider protocol=smtp; [EMAIL PROTECTED]; class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport; vendor=Apache Software Foundation;version=1.0 Error Fri Jan 26 16:28:04 EST 2007 ; Class=framework.services.OutboundEmailMgr ; ID=2 ; Message=Could not send eMail to address [EMAIL PROTECTED] ; Thread=Thread[WebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.SendFailedException: Send failure (javax.mail.AuthenticationFailedException: null):Send failure (javax.mail.AuthenticationFailedException: null) /Error Rick McGuire wrote: Michael C. wrote: We removed all references to the sun mail.jar file in the geronimo classpath and i removed the GBEAN references from the geronimo email plan and left only the geronimo mail dependency jars. We undeployed the old plan and redeployed the new and ran the application. We recieved an error that i expected. The app could not find the provider for smtp. Since our application references the sun javax.mail SMTP class indirectly via the javax.mail.Transport.send(message); call, i am not sure how internally geronimo would resolve to use the geronimo SMTPTransport mail class. Transport.send() uses the context class loader to identify and load the list of Transport and Store providers using files contained in the META-INF directories of the jar files. Once the classpath is set up correctly, it's all automatic. Your original problem was caused by having both the sun mail.jar in the classpath with the Geronimo mail jars. This caused the Sun version to end up overriding the Geronimo version. This might actually work, but it appears you might have hit an incompatibility. I'm willing to chase that incompatibility, but I'll need the exact form of the address you used to add the address. But, i thought somehow the geronimo email plan we deployed would handle this. Here is the error: Thu Jan 25 16:33:49 EST 2007 ; ; ID=3 ; Message=Could not locate the internet provider for [EMAIL PROTECTED]; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.NoSuchProviderException: Unable to locate provider for protocol: smtp:Unable to locate provider for protocol: smtp We cannot change our application logic to use the geronimo SMTPTransport class since our production environment is not Geronimo. Here is our application import list: import javax.mail.Message; import javax.mail.MessagingException; import javax.mail.NoSuchProviderException; import javax.mail.SendFailedException; import javax.mail.Session; import javax.mail.Transport; import javax.mail.internet.AddressException; import javax.mail.internet.InternetAddress; import javax.mail.internet.MimeMessage; We cannot change these imports due to the reasons i mentioned above, but
Re: geronimo mail 1.1.1
Here is our send logic, a lot of code has been omitted, including error
handling...
public void send(EmailMessage outboundMsg) {
String workString;
MimeMessage message;
Properties systemProp =
SystemImpl.getInstance().getApplicationProperties(System_Defaults);
workString = systemProp.getProperty(mail.smtp.host);
Session session = Session.getDefaultInstance(systemProp, null);
try {
message = new MimeMessage(session);
if( !outboundMsg.isBccEmpty() ) {
message.addRecipient(Message.RecipientType.BCC,
new
InternetAddress(outboundMsg.getBcc().trim()));
}
if( !outboundMsg.isCcEmpty() ) {
message.addRecipient(Message.RecipientType.CC,
new
InternetAddress(outboundMsg.getCc().trim()));
}
message.setFrom(new InternetAddress(outboundMsg.getFrom().trim()));
// ***NOTE: Geronimo 1.0 has an incomplete implementation for JavaMail.
There is no implementation for
//addRecipient. The recommended workaround is to use SetRecipient.
Version 1.1 is supposed to
//address the issue. However, we may be able to continue to use the
setRecipient going forward.
//
message.addRecipient(Message.RecipientType.TO, new
InternetAddress(outboundMsg.getTo().trim()));
message.setRecipient(Message.RecipientType.TO,
new
InternetAddress(outboundMsg.getTo().trim()));
}
message.setSubject(outboundMsg.getSubject());
//Determine if this message is to be sent as text or
html and setup
accordingly
if (outboundMsg.getMimeType().endsWith(plain)) {
message.setText(outboundMsg.getText());
}
else {
message.setContent(outboundMsg.getText(),
outboundMsg.getMimeType());
}
Transport.send(message);
}
//end send logic
The outboundMsg.getTo() and outboundMsg.getFrom() just return strings for
the actual email addresses configured in our properties files or from input
fields on pages that vary on an application basis.
Rick McGuire wrote:
Michael C. wrote:
We are finally using the SMTPTransport class from Geronimo. We had a
mail.jar file on our system path that was being picked up. At this
point,
we are getting an AuthenticationFailedException. If we do not need a
GBEAN
configuration, how do we configure our mail server and port number in the
plan? Or should we not need to since our application logic is reading
this
information from an external file and will tranparently pass this
information to the geronimo SMTPTransport class.
I hate to keep asking the same question over and over again, but I'm
afraid I have to. How you configure the transport depends on
how you are creating the mail session within your application. This
includes setting up authentication information if your target SMTP
server requires it. If you are creating the session by doing:
Session mySession = Session.getInstance(props);
Then you are responsible for configuring things like the server and port
number in the property bundle you use to create the session. No GBean
configuration is necessary, or even has any effect if you do happen to
specify it.
If you are using InitialContext.lookup() to get the configured mail
session GBean, then you DO need to have a configured mail session and
can set up things like the authentication information on the
SMTPTransport definition.
Below is the new error and includes the form of the email address we were
using, which is actually the FROM address, but seems to be treating it as
a
TO address according to the error:
I really would like to see the exact string being set in the API call,
not the string reported by the error message. However, an
authentication failure us different than the error you were reporting
earlier, and indicates you've not provided correct information for
accessing the target server.
Rick
Loading javamail.default.providers from jar:file:/C:/Our Path/Our
.war/WEB-INF/lib/geronimo-javamail-transport.jar!/META-INF/javamail.default.providers
DEBUG: loading new provider protocol=smtp,
className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport,
vendor=Apache Software Foundation, version=1.0
DEBUG: getProvider() returning provider protocol=smtp;
[EMAIL PROTECTED];
class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport;
vendor=Apache Software Foundation;version=1.0
Error Fri Jan 26 16:28:04 EST
Re: geronimo mail 1.1.1
Well, ok. You are creating your own mail session, but I really
recommend you NOT use getDefaultInstance(). If something else in the
JVM has done a getDefaultInstance() call, then you're going to end up
with an instance with a different configuration than you expect.
getInstance() will return an instance that respects your property bundle.
Once you've fixed that, if you're still having the problem, then you
need to look at what properties you are passing in when you create the
session. Done the way you are doing now, your host, port, userid, and
password should all be defined there, since it appears that the target
SMTP server is requiring authentication.
As for the still unresolved problem of the internet address parsing, I'm
looking for the exact string that is getting passed into the
addRecipient() call. I really don't care where it comes from, I just
want have the exact string so I can write some test cases to make sure
that string is getting parsed compatibly with the Sun implementation.
Rick
Michael C. wrote:
Here is our send logic, a lot of code has been omitted, including error
handling...
public void send(EmailMessage outboundMsg) {
String workString;
MimeMessage message;
Properties systemProp =
SystemImpl.getInstance().getApplicationProperties(System_Defaults);
workString = systemProp.getProperty(mail.smtp.host);
Session session = Session.getDefaultInstance(systemProp, null);
try {
message = new MimeMessage(session);
if( !outboundMsg.isBccEmpty() ) {
message.addRecipient(Message.RecipientType.BCC,
new
InternetAddress(outboundMsg.getBcc().trim()));
}
if( !outboundMsg.isCcEmpty() ) {
message.addRecipient(Message.RecipientType.CC,
new
InternetAddress(outboundMsg.getCc().trim()));
}
message.setFrom(new InternetAddress(outboundMsg.getFrom().trim()));
// ***NOTE: Geronimo 1.0 has an incomplete implementation for JavaMail.
There is no implementation for
//addRecipient. The recommended workaround is to use SetRecipient.
Version 1.1 is supposed to
//address the issue. However, we may be able to continue to use the
setRecipient going forward.
//
message.addRecipient(Message.RecipientType.TO, new
InternetAddress(outboundMsg.getTo().trim()));
message.setRecipient(Message.RecipientType.TO,
new
InternetAddress(outboundMsg.getTo().trim()));
}
message.setSubject(outboundMsg.getSubject());
//Determine if this message is to be sent as text or
html and setup
accordingly
if (outboundMsg.getMimeType().endsWith(plain)) {
message.setText(outboundMsg.getText());
}
else {
message.setContent(outboundMsg.getText(),
outboundMsg.getMimeType());
}
Transport.send(message);
}
//end send logic
The outboundMsg.getTo() and outboundMsg.getFrom() just return strings for
the actual email addresses configured in our properties files or from input
fields on pages that vary on an application basis.
Rick McGuire wrote:
Michael C. wrote:
We are finally using the SMTPTransport class from Geronimo. We had a
mail.jar file on our system path that was being picked up. At this
point,
we are getting an AuthenticationFailedException. If we do not need a
GBEAN
configuration, how do we configure our mail server and port number in the
plan? Or should we not need to since our application logic is reading
this
information from an external file and will tranparently pass this
information to the geronimo SMTPTransport class.
I hate to keep asking the same question over and over again, but I'm
afraid I have to. How you configure the transport depends on
how you are creating the mail session within your application. This
includes setting up authentication information if your target SMTP
server requires it. If you are creating the session by doing:
Session mySession = Session.getInstance(props);
Then you are responsible for configuring things like the server and port
number in the property bundle you use to create the session. No GBean
configuration is necessary, or even has any effect if you do happen to
specify it.
If you are using InitialContext.lookup() to get the configured mail
session GBean, then you DO need to have a configured mail session and
can set up things like the authentication information on the
SMTPTransport definition.
Re: geronimo mail 1.1.1
I am working on getting you the exact string for the addRecipient call
between other daily endeavors. Meanwhile, we changed our code to use the
getInstance() and get the same authentication error. I reviewed the
geronimo SMTPTransport class to see what is going on and found these
constants:
private static final char CR = 13;
private static final char LF = 10;
private static final String MAIL_HOST = mail.host;
private static final String MAIL_SMTP_LOCALHOST = mail.smtp.localhost;
private static final String MAIL_SMTP_PORT = mail.smtp.port;
private static final int MIN_MILLIS = 6;
private static final String DEFAULT_MAIL_HOST = localhost;
private static final int DEFAULT_MAIL_SMTP_PORT = 25;
I cross-referenced these tags with our email configuration properties file
and found that we are using mail.smtp.host which does not exist here. So i
added it to our email properties. The class does default to port 25 so that
should not be an issue. We also only need host-name and port to connect and
these entries are in our properties. We debugged our app and saw the mail
Session object does contain the port and host name properties as they are
identified in the constants of the geronimo SMTPTransport class. We still
get the authentication error. Is there any other configuration that we
could be missing?
To summarize:
-We modified our email deployment plan shown below
-we removed our GBEAN references from the earlier 1.0 version
-we removed the mail.jar from our classpath
-we changed our send() method to use getInstance() instead of
getDefaultInstance()
-we validated the host and port number (which is all that is needed) is in
the mail Session object before sending the email
Here is our plan we have deployed:
?xml version=1.0 encoding=UTF-8?
module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1;
dep:environment
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1;
dep:moduleId
dep:groupIdgeronimo/dep:groupId
dep:artifactIdjavamail-server/dep:artifactId
/dep:moduleId
dep:dependencies
dep:dependency
dep:groupIdgeronimo/dep:groupId
dep:artifactIdgeronimo-javamail/dep:artifactId
dep:version1.3.1_spec/dep:version
dep:typejar/dep:type
dep:importclasses/dep:import
/dep:dependency
dep:dependency
dep:groupIdgeronimo/dep:groupId
dep:artifactIdgeronimo-activation/dep:artifactId
dep:version1.0.2_spec/dep:version
dep:typejar/dep:type
dep:importclasses/dep:import
/dep:dependency
dep:dependency
dep:groupIdgeronimo/dep:groupId
dep:artifactIdgeronimo-javamail-transport/dep:artifactId
dep:version1.0/dep:version
dep:typejar/dep:type
dep:importclasses/dep:import
/dep:dependency
dep:dependency
dep:groupIdgeronimo/dep:groupId
dep:artifactIdgeronimo-mail/dep:artifactId
dep:version1.1.1/dep:version
dep:typejar/dep:type
dep:importclasses/dep:import
/dep:dependency
dep:dependency
dep:groupIdgeronimo/dep:groupId
dep:artifactIdgeronimo-management/dep:artifactId
dep:version1.1.1/dep:version
dep:typejar/dep:type
dep:importclasses/dep:import
/dep:dependency
/dep:dependencies
dep:hidden-classes/
dep:non-overridable-classes/
/dep:environment
/module
Rick McGuire wrote:
Well, ok. You are creating your own mail session, but I really
recommend you NOT use getDefaultInstance(). If something else in the
JVM has done a getDefaultInstance() call, then you're going to end up
with an instance with a different configuration than you expect.
getInstance() will return an instance that respects your property bundle.
Once you've fixed that, if you're still having the problem, then you
need to look at what properties you are passing in when you create the
session. Done the way you are doing now, your host, port, userid, and
password should all be defined there, since it appears that the target
SMTP server is requiring authentication.
As for the still unresolved problem of the internet address parsing, I'm
looking for the exact string that is getting passed into the
addRecipient() call. I really don't care where it comes from, I just
want have the exact string so I can write some test cases to make sure
that string is getting parsed compatibly with the Sun implementation.
Rick
Michael C. wrote:
Here is our send logic, a lot of code has been omitted, including error
handling...
public void send(EmailMessage outboundMsg) {
String workString;
MimeMessage message;
Properties systemProp =
SystemImpl.getInstance().getApplicationProperties(System_Defaults);
workString = systemProp.getProperty(mail.smtp.host);
Session session =
Re: geronimo mail 1.1.1
The message about unable to relay for that address is sent back from the SMTP server. I'm not sure what it didn't like, but it appears it couldn't figure out where to relay the message. The part I find interesting is the stack trace. You're using the Sun javamail transport implementation, not the Geronimo one. The API code (javax.mail.* appears to be the Geronimo version). Is that what you intended? I know we've never tested that combo, so it's unclear how well that would work. You might want to check around for a spurious mail.jar file. Having that in your classpath can potentially cause the other transports to get registered and override the Geronimo ones. Rick Michael C. wrote: I tried your approach and that particular error went away but now i believe i am back to the root cause of all this effort; our email logic is throwing an error on this line in our application: javax.mail.Transport.send(message); Message=Could not send eMail to address [EMAIL PROTECTED] ; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.SendFailedException: Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ):Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] Thu Jan 25 09:28:14 EST 2007 ; Message=Could not send eMail to address [EMAIL PROTECTED]; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.SendFailedException: Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ):Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ) :Could not send eMail to address [EMAIL PROTECTED] javax.mail.SendFailedException: Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ) at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:804) at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:320) at javax.mail.Transport.send(Transport.java:93) at javax.mail.Transport.send(Transport.java:46) Caused by: javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:672) I supplemented the real address but we are using a good address. This error only occurs in our local testing using Geronimo but once we move our code to the next tier where WebSphere is running, everything works fine. There is a configuration issue that i do not understand. djencks wrote: It looks to me as if the error message is fairly clear about the first think that is wrong with your xml resource-ref propertyMailSession/property res-typejavax.mail.Session/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope pattern namemail/MailSession/name /pattern /resource-ref Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.1, I think this will work: resource-ref ref-nameMailSession/ref-name resource-linkmail/MailSession/resource-link /resource-ref and I also think that if you name the mail session the same in your app and your mail-server plan you won't need any entry in the geronimo-web.xml at all. thanks david jencks On Jan 24, 2007, at 7:57 AM, Michael C. wrote: Our team has just upgraded from geronimo 1.0 to 1.1.1 Previously, to surpress javamail errors, we had to create a gbean and deploy it, then add a resource-ref entry to our geronimo-web.xml file and this worked. Since our upgrade, we are back to our original javamail errors. I found entries on other postings here and successfully deployed the following plan: ?xml version=1.0 encoding=UTF-8? module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:moduleId dep:groupIdgeronimo/dep:groupId dep:artifactIdjavamail-server/dep:artifactId /dep:moduleId dep:dependencies dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdgeronimo-mail/dep:artifactId dep:version1.1.1/dep:version dep:typejar/dep:type dep:importclasses/dep:import /dep:dependency dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdgeronimo-javamail-transport/dep:artifactId dep:version1.1.1/dep:version dep:typejar/dep:type dep:importclasses/dep:import /dep:dependency dep:dependency dep:groupIdgeronimo/dep:groupId
Re: geronimo mail 1.1.1
Thank you for your replies, they are greatly appreciated. I would like to step back for a moment and be sure i understand the big picture. When our team first changed over from WSAD to MyEclipse and decided to use Geronimo 1.0 as our local app server, we ran into this same email problem. I found that there were some email bugs in the Geronimo 1.0 version, and that you had to use the geronimo-mail.jar and the geronimo-javamail-transport.jar files, and configure geronimo thru a GBEAN to use these jars to fix the email issue. Maybe already, my understanding was incorrect but this did fix the issue. We just upgraded to geronimo 1.1.1 and re-introduced the same email issue. I have read where this email issue was fixed with 1.1.1. But without any changes, we still throw errors. When i deployed the new email plan(in my earlier threads), we still throw errors. So i have a couple questions... Since our application code uses the javax.mail.* packages, it would be best to configure geronimo to use these packages for email. To be honest, if this is fixed with 1.1.1, then why are there still geronimo version email packages in the new install? Our intent would certainly be to use the mail packages from Sun since this is the .jar file used in our app and our WebSphere production server. Is it an option to configure Geronimo to use this mail.jar file and if so, how do we go about doing it? Rick McGuire wrote: The message about unable to relay for that address is sent back from the SMTP server. I'm not sure what it didn't like, but it appears it couldn't figure out where to relay the message. The part I find interesting is the stack trace. You're using the Sun javamail transport implementation, not the Geronimo one. The API code (javax.mail.* appears to be the Geronimo version). Is that what you intended? I know we've never tested that combo, so it's unclear how well that would work. You might want to check around for a spurious mail.jar file. Having that in your classpath can potentially cause the other transports to get registered and override the Geronimo ones. Rick Michael C. wrote: I tried your approach and that particular error went away but now i believe i am back to the root cause of all this effort; our email logic is throwing an error on this line in our application: javax.mail.Transport.send(message); Message=Could not send eMail to address [EMAIL PROTECTED] ; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.SendFailedException: Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ):Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] Thu Jan 25 09:28:14 EST 2007 ; Message=Could not send eMail to address [EMAIL PROTECTED]; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.SendFailedException: Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ):Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ) :Could not send eMail to address [EMAIL PROTECTED] javax.mail.SendFailedException: Invalid Addresses (javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] ) at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:804) at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:320) at javax.mail.Transport.send(Transport.java:93) at javax.mail.Transport.send(Transport.java:46) Caused by: javax.mail.SendFailedException: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:672) I supplemented the real address but we are using a good address. This error only occurs in our local testing using Geronimo but once we move our code to the next tier where WebSphere is running, everything works fine. There is a configuration issue that i do not understand. djencks wrote: It looks to me as if the error message is fairly clear about the first think that is wrong with your xml resource-ref propertyMailSession/property res-typejavax.mail.Session/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope pattern namemail/MailSession/name /pattern /resource-ref Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: cvc-complex-type.2.4a: Expected element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.1, I think this will work: resource-ref ref-nameMailSession/ref-name
Re: geronimo mail 1.1.1
We removed all references to the sun mail.jar file in the geronimo classpath and i removed the GBEAN references from the geronimo email plan and left only the geronimo mail dependency jars. We undeployed the old plan and redeployed the new and ran the application. We recieved an error that i expected. The app could not find the provider for smtp. Since our application references the sun javax.mail SMTP class indirectly via the javax.mail.Transport.send(message); call, i am not sure how internally geronimo would resolve to use the geronimo SMTPTransport mail class. But, i thought somehow the geronimo email plan we deployed would handle this. Here is the error: Thu Jan 25 16:33:49 EST 2007 ; ; ID=3 ; Message=Could not locate the internet provider for [EMAIL PROTECTED]; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.NoSuchProviderException: Unable to locate provider for protocol: smtp:Unable to locate provider for protocol: smtp We cannot change our application logic to use the geronimo SMTPTransport class since our production environment is not Geronimo. Here is our application import list: import javax.mail.Message; import javax.mail.MessagingException; import javax.mail.NoSuchProviderException; import javax.mail.SendFailedException; import javax.mail.Session; import javax.mail.Transport; import javax.mail.internet.AddressException; import javax.mail.internet.InternetAddress; import javax.mail.internet.MimeMessage; We cannot change these imports due to the reasons i mentioned above, but since the javax.mail.Transport object uses the com.sun.mail.smtp.SMTPTransport class, how can we tell it to use the geronimo SMTPTransport class? Should this be handled by our plan without having to change our application code? here is the plan we deployed: ?xml version=1.0 encoding=UTF-8? module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:moduleId dep:groupIdgeronimo/dep:groupId dep:artifactIdjavamail-server/dep:artifactId /dep:moduleId dep:dependencies dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdgeronimo-mail/dep:artifactId dep:version1.1.1/dep:version dep:typejar/dep:type dep:importclasses/dep:import /dep:dependency dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdgeronimo-javamail-transport/dep:artifactId dep:version1.1.1/dep:version dep:typejar/dep:type dep:importclasses/dep:import /dep:dependency dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdrmi-naming/dep:artifactId dep:version1.1.1/dep:version dep:typecar/dep:type /dep:dependency /dep:dependencies dep:hidden-classes/ dep:non-overridable-classes/ /dep:environment /module Rick McGuire wrote: Michael C. wrote: Thank you for your replies, they are greatly appreciated. I would like to step back for a moment and be sure i understand the big picture. When our team first changed over from WSAD to MyEclipse and decided to use Geronimo 1.0 as our local app server, we ran into this same email problem. I found that there were some email bugs in the Geronimo 1.0 version, and that you had to use the geronimo-mail.jar and the geronimo-javamail-transport.jar files, and configure geronimo thru a GBEAN to use these jars to fix the email issue. Maybe already, my understanding was incorrect but this did fix the issue. We just upgraded to geronimo 1.1.1 and re-introduced the same email issue. I have read where this email issue was fixed with 1.1.1. But without any changes, we still throw errors. When i deployed the new email plan(in my earlier threads), we still throw errors. So i have a couple questions... Since our application code uses the javax.mail.* packages, it would be best to configure geronimo to use these packages for email. To be honest, if this is fixed with 1.1.1, then why are there still geronimo version email packages in the new install? Our intent would certainly be to use the mail packages from Sun since this is the .jar file used in our app and our WebSphere production server. Is it an option to configure Geronimo to use this mail.jar file and if so, how do we go about doing it? Geronimo comes with its own implementation of the javax.mail.* apis and it's own transport implementation. The javax.mail APIs are used by other components (e.g., Axis) so they are pretty fundamental to Geronimo operations and show up in a lot of dependencies. Unfortunately, part of javamail processing is locating and loading all transport implementations contained in jars on the classpath. If both the sun jar and the geronimo jars are present, then both sets of transports get loaded and depending on the search order, the default transports
Re: geronimo mail 1.1.1
Michael C. wrote: We removed all references to the sun mail.jar file in the geronimo classpath and i removed the GBEAN references from the geronimo email plan and left only the geronimo mail dependency jars. We undeployed the old plan and redeployed the new and ran the application. We recieved an error that i expected. The app could not find the provider for smtp. Since our application references the sun javax.mail SMTP class indirectly via the javax.mail.Transport.send(message); call, i am not sure how internally geronimo would resolve to use the geronimo SMTPTransport mail class. Transport.send() uses the context class loader to identify and load the list of Transport and Store providers using files contained in the META-INF directories of the jar files. Once the classpath is set up correctly, it's all automatic. Your original problem was caused by having both the sun mail.jar in the classpath with the Geronimo mail jars. This caused the Sun version to end up overriding the Geronimo version. This might actually work, but it appears you might have hit an incompatibility. I'm willing to chase that incompatibility, but I'll need the exact form of the address you used to add the address. But, i thought somehow the geronimo email plan we deployed would handle this. Here is the error: Thu Jan 25 16:33:49 EST 2007 ; ; ID=3 ; Message=Could not locate the internet provider for [EMAIL PROTECTED]; Thread=Thread[AmicaWebApp--TP-Processor3,5,main] ; Original Exception=javax.mail.NoSuchProviderException: Unable to locate provider for protocol: smtp:Unable to locate provider for protocol: smtp We cannot change our application logic to use the geronimo SMTPTransport class since our production environment is not Geronimo. Here is our application import list: import javax.mail.Message; import javax.mail.MessagingException; import javax.mail.NoSuchProviderException; import javax.mail.SendFailedException; import javax.mail.Session; import javax.mail.Transport; import javax.mail.internet.AddressException; import javax.mail.internet.InternetAddress; import javax.mail.internet.MimeMessage; We cannot change these imports due to the reasons i mentioned above, but since the javax.mail.Transport object uses the com.sun.mail.smtp.SMTPTransport class, how can we tell it to use the geronimo SMTPTransport class? Should this be handled by our plan without having to change our application code? here is the plan we deployed: You shouldn't have to, this should be getting resolved automatically. The critical dependencies to make this happen are the javamail spec jar, the activation jar, and the javamail transport jar (geronimo-javamail_1.3.1_spec, geronimo-activation_1.0.2_spec and geronimo-javamail-transport). You do not need a dependency on geronimo-mail and you do not need to configure a mail session GBean unless your application obtains the mail session by doing a jndi lookup. I have seen a problem where some application environments (e.g, the Quartz scheduler) were not setting the correct thread context class loader before calling the application methods. This resulted in a failure because the incorrect class loader was getting used to resolve the javamail transport code. In this case, it was necessary to set the context class loader using the load obtained from this.getClass().getClassLoader() . Rick ?xml version=1.0 encoding=UTF-8? module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:environment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:moduleId dep:groupIdgeronimo/dep:groupId dep:artifactIdjavamail-server/dep:artifactId /dep:moduleId dep:dependencies dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdgeronimo-mail/dep:artifactId dep:version1.1.1/dep:version dep:typejar/dep:type dep:importclasses/dep:import /dep:dependency dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdgeronimo-javamail-transport/dep:artifactId dep:version1.1.1/dep:version dep:typejar/dep:type dep:importclasses/dep:import /dep:dependency dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdrmi-naming/dep:artifactId dep:version1.1.1/dep:version dep:typecar/dep:type /dep:dependency /dep:dependencies dep:hidden-classes/ dep:non-overridable-classes/ /dep:environment /module Rick McGuire wrote: Michael C. wrote: Thank you for your replies, they are greatly appreciated. I would like to step back for a moment and be sure i understand the big picture. When our team first changed over from WSAD to MyEclipse and decided to use Geronimo 1.0 as our local app server, we ran into this same email problem. I found that there were some email bugs in the Geronimo 1.0 version, and that you had to use the geronimo-mail.jar and the
