https://issues.apache.org/bugzilla/show_bug.cgi?id=53665
--- Comment #1 from David Bullock <david.bull...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org