Welcome Mrinal, Thanks for the insights, makes sense indeed. Seems to me, though, that this is something of a semi-advanced level; I'd rather get a few savvy users have to knowingly remove (or use a maven-dependency-exclusion) the mail and activation jars, than scare away newcomers with obscure NoClassDefFoundError s - wdyt ?
-g On Jul 29, 2010, at 17:45, Mrinal Kanti wrote: > 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]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
