Actually it depends on the scenario. Whether you are using Tomcat or if you are using any other Application Server like WebLogic or Websphere. Most app servers these days ship with the mail (and activation) jars in their server classpath which allows them to configure/manage mail Session as a resource independent of the webapps. Tomcat keeps things simple and less sophisticated. So it allows a possibility were you may not need to externally manage Java mail Session.
Nevertheless, I see a few reasons for putting the java mail jars in server classpath (if your app server does not provide it). 1) It allows for the JNDI configuration for java mail Session (like JDBC). This is probably beneficial in scenarios where one would like to configure the mail session at a server level. The server classloader cannot access a jar from the webapp classloader. But if the mail jar is ALSO present in webapp then it presents a risk as the Session class is loaded by both server and webapp classloaders, so the webapp classloader may complain that the instance loaded by the server does not belong to the class loaded by the child (webapp) classloader. 2) Low overhead for the webapp classloader if it has to maintain (load or unload) the Java Mail classes on a per webapp basis. I often have to run my apps on a VPS environment which constrains me on both CPU and memory fronts Besides, JavaMail has not gone through any significant changes in the recent past, so it would be a safe risk to assume that any recently developed webapps would be using the latest version, thereby eliminating the risk of version mismatch at the server class loader level. Just my 2 cents along with my first post, -Mrinal ________________________________ From: Grégory Joseph <[email protected]> To: Magnolia User-List <[email protected]> Sent: Thu, July 29, 2010 8:10:36 PM Subject: Re: [magnolia-user] mail.jar and Axis SOAP clients = Problems On Jul 29, 2010, at 16:16, Unger, Richard wrote: > Hello Everyone! > > I was just trying to integrate a (Axis-1.4 based) SOAP client into my >TemplateModel class, and was having problems with ClassNotFoundExceptions for >javax.mail.* classes. > > The reason is that magnolia includes “mail-1.4.1.jar” in the WEB-INF/lib >Directory of the magnolia webapps. > However, recent versions of Tomcat will refuse to load classes coming from > the >packages java.* or javax.* via the webapp classloader. JARs including such >classes must be placed in $CATALINA_HOME/common/lib to avoid problems. Do you know since which version this is the case ? I've deployed quite a few Magnolia instances under Tomcat 6 instances without issues. AFAIK (but I might be outdated), the only forbidden packages in webapps are the servlet and jsp ones. -g > > Moving mail-1.4.1.jar from the WEB-INF/lib to common/lib solves the problem. > > I don’t know whether this is really a bug (since other Servlet Containers may >not have this restriction), but perhaps it would be better to move the >mail.jar >in the magnolia-tomcat-bundle release… > > Regards from Vienna, > > Richard Unger > > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
