[Bug 53665] Minor JNDI Howto document enhancement concerning mail properties

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=53665

--- Comment #1 from David Bullock <da...@machaira.com.au> ---
I was about to file this one, and noticed I had been beaten to the punch.  My
description for the issue would have been: 

"Documentation of JavaMail JNDI resource factories fails to document the
'password' attribute".

I was lucky to have found
http://stackoverflow.com/questions/6372171/documentation-of-java-mail-api-configuration-for-jndi-in-tomcat
or else I'd have been reading the source-code myself.

It's great that when we get a javax.mail.Session via JNDI, Tomcat can arrange
for it to have an administrator-configured javax.mail.Authenticator already.

But you do need to:

a) tell the administrator:
   i) what they're doing (causing the Session to issue Transports with
Authenitcators already set); and
  ii) how to do it (using the 'password' attribute in combination with various
JavaMail provider attributes)

b) re-assure the coder that:
   i) Transport.send(aMessage) ... is right; and using
  ii) aTransport.sendMessage() ... is not *necessary*, because
 iii) the behaviour of Transport.send(Message), in calling aTransport.connect()
is OK so long as the deployer knew his work.

c) document who "wins" when the coder calls
aTransport.connect(String,String,String) and aTransport.sendMessage(Message) in
lieu of using Transport.send(Message)... BUT the deployer already set things up
such that the Transport has an Authenticator.  Who will prevail?  (NB.  This is
an entirely legitimate use of the Transport, at least as far as the JavaMail
FAQ is concerned: http://www.oracle.com/technetwork/java/faq-135477.html#send  
I'm not sure if the JavaEE spec says anything about it. (I hope it does, but
hopes are not high, and I don't have time to hunt for it rght now).

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org