Feature? jdbc driver vs javamail loading from WEB-INF/lib
Hello, Is the jdbc driver loading from WEB-INF/lib and used in jndi datasource an official feature, given that it is used in so many webapps? Then what about mail session and javamail? Before saying yes of course or never it is, see that the jdbc driver is loaded from WEB-INF/lib and used in a jndi datasource declared in context.xml, with the source of a basic webapp (https://github.com/evernat/jdbcDatasourceVsMailSession) : 1. Either run |mvn tomcat7:run| 2. Open http://localhost:8080/jdbc.jsp or 1. Run |mvn package| then deploy target/test-0.1.war in Tomcat 9 or Tomcat 8 or in most versions of Tomcat 7 2. Open http://localhost:8080/test-0.1/jdbc.jsp and see "JDBC connection OK". And note that this quite well known Tomcat's feature since some version of Tomcat long ago seems to me the opposite of what says the Tomcat's doc, https://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html#DriverManager,_the_service_provider_mechanism_and_memory_leaks: Drivers packaged in web applications (in WEB-INF/lib) and in the shared class loader (where configured) will not be visible and will not be loaded automatically. If you are considering disabling this feature, note that the scan would be triggered by the first web application that is using JDBC, leading to failures when this web application is reloaded and for other web applications that rely on this feature. Thus, the web applications that have database drivers in their WEB-INF/lib directory cannot rely on the service provider mechanism and should register the drivers explicitly. And perhaps some version of the JRE Memory Leak Prevention Listener introduced by accident this feature of loading from WEB-INF/lib which is used by so many webapps now. Users don't think anymore that it is an accident and they think that it is a feature which makes their webapps' deployment autonomous. You have seen that the jdbc driver is loaded from WEB-INF/lib and used in a jndi datasource declared in context.xml. Now, a jndi mail session is the second thing declared in context.xml next to the datasource, to configure smtp server like the database server for the datasource. Is the javamail driver loaded from WEB-INF/lib and used in a jndi mail session? But see that the javamail driver is not loaded from WEB-INF/lib: 3. Open mail.jsp next to jdbc.jsp (http://localhost:8080/mail.jsp or http://localhost:8080/test-0.1/mail.jsp) and see "root Cause ClassNotFoundException: javax.mail.Authenticator" Why is there a difference of behavior from the user's point of view, between jdbc datasource and mail session? Could it be fixed by loading the javamail driver from WEB-INF/lib? Or could the latest javamail driver be added in the Tomcat's lib directory? (There are not many questions for which javamail to use anyway and it would make things easier.) Thanks for your opinion, Emeric
Re: Tomcat pausing and no java process
Hi Miguel, To be more precise about used memory and active threads count, I think that you could send a screenshot of the main graphics of javamelody in your browser (used memory, http sessions, active threads, etc...). And once you have the heap dump as said by Christopher, Eclipse MAT is quite good to analyze the heap dump. Emeric Le 03/05/2012 16:52, Christopher Schultz a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel, On 5/3/12 6:35 AM, Miguel González Castaños wrote: Anything I can check or any setting I can set to get more information in the next crash? Add -XX:+HeapDumpOnOutOfMemoryError to your CATALINA_OPTS environment variable before you launch Tomcat and you'll get a heap dump file when OOME occurs. You could also enable verbose gc if you want to go back and graph the memory usage.. but if you're using javamelody you probably already have that. Once you have the heap dump, look for either single objects that are taking a huge amount of memory or one particular class that has a lot of objects and/or takes up a lot of memory per object. Follow those objects to their GC roots and you'll find out where the references are. Perhaps you have a memory leak entirely by accident, or maybe a cache that isn't tuned properly for your heap size. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+im5MACgkQ9CaO5/Lv0PD7uQCgiKEtK56xU+l6kw/0UmxruLBf 95MAnRJ3hfZd/POoD09B12MglevNqekk =tzaU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
