I just configured a JAASRealm and a login module for it that authenticates users. I've gotten that to work just fine. But in the process I discovered something very strange. My loging module relies on mail.jar, the JavaMail API. I put my login module and its dependency jars into the common/lib directory to be loaded there, but I was getting NoSuchProviderException when trying to create a store using the "imap" protocol. I know for a fact my mail.jar was being loaded, because Tomcat found and executed classes successfully which were contained within the mail.jar. After spending hours with logs and API docs, I finally just put mail.jar on Tomcat's classpath, and it resolved the problem. Stranger still, all worked fine without putting mail.jar in the classpath in Tomcat 5.0.28.
Can anyone shed light on why putting this Jar on the literal Tomcat classpath would have a different effect than putting jars into common/lib? I am guessing that this has something to do with other resources (property files and the like) which might be contained in the jar. The reason this is a concern for me, is that it leads me to believe that there's no point in placing jars into any of the directories governed by Tomcat's classloader hierarchy, but rather that I ought to place all jars on the classpath? Help! I need to get to the bottom of this problem! Brad --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]