org.apache.naming.factory.MailSessionFactory is missing from naming-factory.jar in Tomcat 5.5.20.
I'm having the same problem with Tomcat 5.5.20. Has the class been moved elsewhere? Are there plans to reintroduce it in the Tomcat distribution?
Until there is an updated release, you can patch your Tomcat 5.5.20 installation by adding the following two files (with paths) to the TOMCAT_HOME\common\classes\ directory: org\apache\naming\factory\MailSessionFactory.class org\apache\naming\factory\MailSessionFactory$1.class The files can be obtained from the Tomcat 5.5.17 distribution: http://www.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.zip This solution has worked for me using the JavaMail 1.4 API.
Can it be that a total of 5 files are missing in Tomcat 5.5.20 naming-factory.jar? SendMailFactory SendMailFactory$1 MailSessionFactory MailSessionFactory$1 MailSessionFactory$2
(In reply to comment #3) > Can it be that a total of 5 files are missing in Tomcat 5.5.20 naming-factory.jar? > SendMailFactory > SendMailFactory$1 > MailSessionFactory > MailSessionFactory$1 > MailSessionFactory$2 > Good point! Yes, all these files are missing from the 5.5.20 distribution ...
Critical ? When you simply have to compile a JNDI object factory ?
(In reply to comment #5) > Critical ? When you simply have to compile a JNDI object factory ? I consider it critical as I have to patch my Tomcat installation to avoid loss of functionality. Was this omission planned? That is, will future Tomcat versions also omit these libraries?
I can confirm this problem on 5.5.20 on Linux.
Minor releases are meant as a drop-in replacement, which 5.5.20 is obviously not. Could you raise the priority again?
(In reply to comment #8) > Could you raise the priority again? Done!
(In reply to comment #5) > Critical ? When you simply have to compile a JNDI object factory ? Backwards compatibility is always critical in a prodution environment.
This looks similar to bug 29255. It's probably because JavaMail wasn't on the classpath when 5.5.20 was built.
(In reply to comment #11) > It's probably because JavaMail wasn't on the classpath when 5.5.20 was built. Good point! I cannot recommend 5.5.20 to for use on any of our development or production servers when a critical component that we rely on is missing. Does anyone know when the next release of Tomcat 5.5.x is scheduled?
This is really pathetic ...
(In reply to comment #13) > This is really pathetic ... There are a least six people (other than you) who have taken the time to post comments regarding this bug. Obviously, the missing libraries from the 5.5.20 distribution is causing concern to them - otherwise they would not have posted. The hope is that by providing feedback in a forum such as this that concerns will be taken seriously ... at the end of the day, a more robust software product will be developed - that we can all benefit from.
(In reply to comment #5) > Critical ? When you simply have to compile a JNDI object factory ? Applications using mail resources not working properly without a recompile is frankly quite bad. But you are right its not critical, this should have severity regression (which is between major and critical so it's just one of :)
I don't understand why this is not just fixed (which sounds really trivial for a missing class) instead of talking 1.5 months about the severity of the bugzilla entry.
There is nothing to fix / no code to change. It was caused by a build error (optional JAR not present during build) which will be corrected in the next release.
(In reply to comment #17) > ... will be corrected in the next release. Can you tell us when the next release is planned?
Created attachment 19186 [details] Patch for missing libraries from Tomcat 5.5.23 distibution Until the next version is released, you can unzip the attached class files (from the Tomcat 5.5.17 release) to your TOMCAT_HOME\common\classes\ directory.
(In reply to comment #13) > This is really pathetic ... While breaking any application that uses a container-provided JNDI mail session because of a silly build mistake is indeed unfortunate, I think "pathetic" is perhaps too strong a word. It would, however, be very nice to be able to use the binary release instead of having to roll my own. When I tell other people in my company that the official Tomcat binary doesn't work any more due to this issue, the first response I get is "what container should we switch to?" rather than "let's just compile our own version."
This bug is still there after two months. I think there should either be a 5.5.21 release or AT LEAST a warning on the webpage about that problem. We did install the 5.5.20 and wondered why we received only few mailforms. (The ones from the not upgraded servers)
Notices added to RELEASE-NOTES online as well as the README text on the download pages. The notices include links to this Bugzilla issue. The issue itself will be addressed in the next release, v5.5.21. There is currently no established deadline for the 5.5.21 release. Users who can't use one of the workarounds suggested here, such as copying the relevant classes from a 5.5.17 distro or download the patch attached to this issue, can retrograde their Tomcat installation to 5.5.17 completely. Thank you for reporting this issue.
This issue has not been resolved in Tomcat 5.5.23: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.naming.factory.MailSessionFactory] at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:132) The class is not present in common/lib/naming-factory.jar where I believe it belongs to.
(In reply to comment #23) > This issue has not been resolved in Tomcat 5.5.23: > > Could not create resource factory instance [Root exception is > java.lang.ClassNotFoundException: org.apache.naming.factory.MailSessionFactory] > at > org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:132) > > The class is not present in > > common/lib/naming-factory.jar > > where I believe it belongs to. I can confirm that both the MailSessionFactory and SendMailFactory classes are missing from the 5.5.23 ZIP distribution. It is very difficult to convince our production IT people that an "Apache" disto must be patched due to missing files. They would prefer to use an older distro that does not require patching, but of course it does not have the most recent bug fixes. There are now fourteen (14) votes for this bug - which is more than for any other bug in the Tomcat 5.x release. Do these votes count for "nothing"?
We realy need a working release, please make a 5.5.24 release. I think this one is worth fixing, especially since a web container is also commonly used to provide a way for the end users to send feedback via contact forms. And with these missing classes it miserably fails. (Since 5 months now)
This has been fixed in the build script. You are now unable to complete a release package without these two jars in your classpath. The libraries were optional in the distribution, so if they were not present they wouldn't be included. Next major release will include this, in the meantime, the recommend work around is already mentioned here http://issues.apache.org/bugzilla/show_bug.cgi?id=40668#c2 Please note, it is safe to patch these two files, they have not changed since 5.5.17 Sorry for the inconvenience
Thanks for fixing this. Note that JavaMail 1.4 and JAF 1.1 have moved to a free license, so you could make those classes as permanent in the build process as everything else.
I just read through the license, and it doesn't look like a BSD style license, I doubt its compatible.
The link in comment #2 to obtain the missing files does not work. Could somebody post a working link?
I found a working link: http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.zip
You can also use the patch (taken from the Tomcat 5.5.17 distribution) from: http://issues.apache.org/bugzilla/attachment.cgi?id=19186
Just adding myself to CC list.
add cc
It's amazing that Apache Tomcat people can't properly build their own software, and that they care very little about having a broken release out there for months. We are stuck (as many others) in 5.5.17 for this. Please release a 5.5.24.
I recently learned that Debian Etch comes with Tomcat 5.5.20 which indeed contains MailSessionFactory (amongst the other missing JNDI Factories). So if you happen to run Debian, don't hesitate to use the Debian packaged version rather than the downloadable binary from apache.org. This will also allow for easy critical bug updates.
Problem: Tomcat 5.5.23 naming-factory.jar doesn’t contain the org.apache.naming.factory.MailSessionFactory class. Upon startup the following message is generated in the Catalina.log file when trying to configure JNDI resources: javax.naming.NamingException: Could not create resource factory instance [Root exception is java.lang.ClassNotFoundException: org.apache.naming.factory.MailSessionFactory] Solution/Work Around: Copy Tomcat 5.5.17 naming-factory.jar to \common\lib. Environment: Pentium 4 (3.4 Mhz) 2 GB memory Windows XP Pro SP2 MySQL 5.1 Apache 2.2.4 Mod_jk 2.2.4 Tomcat 5.5.23 (port 8084) Java 1.5.0_11-b03
(In reply to comment #26) > This has been fixed in the build script. You are now unable to complete a > release package without these two jars in your classpath. > The libraries were optional in the distribution, so if they were not present > they wouldn't be included. Next major release will include this, in the > meantime, the recommend work around is already mentioned here > http://issues.apache.org/bugzilla/show_bug.cgi?id=40668#c2 > > Please note, it is safe to patch these two files, they have not changed since 5.5.17 > > Sorry for the inconvenience > This still isn't fixed in the core binary distribution downloaded here: http://tomcat.apache.org/download-55.cgi#5.5.23
(In reply to comment #37) > This still isn't fixed in the core binary distribution downloaded here: > http://tomcat.apache.org/download-55.cgi#5.5.23 If I were holding my breath to have this problem fixed .... well, lets just say I'd be pushing up worms. You can use this patch (taken from the Tomcat 5.5.17 distribution) to add the required libraries to Tomcat 5.5.23 /common/classes folder: http://issues.apache.org/bugzilla/attachment.cgi?id=19186 You can also download the 5.5.17 distribution and replace the /common/lib/naming-factory.jar in your Tomcat 5.5.23 installation with the 5.5.17 version. http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.zip
This bug/omission has cost my 5 hours of my life (and a very, very late night :-). I hope it gets resolved in the next release. Everything about Tomcat usually "just works" so it took me some time to realize my problem was in Tomcat and not the webapp (3rd party webapp with no debug output you see!). Please, please fix.
A more accurate description of the cause of this bug is probably that the tomcat binary build process is not done in a repeatable fashion. The person creating the builds is probably not even aware their build environment is creating broken tomcat binaries. One of the key purposes of Maven is to create repeatable builds that will produce the exact same artifact, regardless of who ran the build. I suggest that to permanently solve this problem, Maven be used in the Tomcat build.
The recently released 5.5.25 contains the missing class files.
*** Bug 43565 has been marked as a duplicate of this bug. ***