Thanks Gregor, I see your position. Perhaps one of the key points in building a product is that you do not (want to) control the diversity of target environments. So its natural to make such assumptions so long as you "believe" they would be accepted/benefited by majority of your users. Since I, as an user is at the receiving end who would have to customize the install scripts for each third-party webapp to exclude such jars, it does add a little overhead during installation for each webapp.
Just another perspective, Mrinal ________________________________ From: Grégory Joseph <[email protected]> To: Magnolia User-List <[email protected]> Sent: Thu, July 29, 2010 9:18:51 PM Subject: Re: [magnolia-user] mail.jar and Axis SOAP clients = Problems 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]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
