Daniel,
On 6/19/24 16:37, Daniel Schwartz wrote:
I followed you instruction to move the context.xml file into the application
WEB-INF directory and restored the original context.xml file in the tomcat conf
directory, but the problem persists. Very puzzling.
To be clear, I was recommending putting context.xml into META-INF and
not WEB-INF.
Your remark regarding the MySQL login ID and password is well-taken, and I will
change this when/if the system goes into production.
In the meantime, however, I have explored the current version of Glassfish. I
had been using Glassfish 4.1 years ago, and it had a nice interface for setting
up database connection pooling. You just had to input some parameters and it
automatically generated all the necessary files in the appropriate directories.
That system would not work with any version of Java later than 1.8.
Then they upgrader to Glassfish 5.0, which would work with later versions of
Java. Unfortunately, when the upgraded version introduced a big that made the
connection pooling module unusable.
Then I put that project on hold for a few years, and have now come back to it.
This is why I recently decided to explore Tomcat, as an alternative to
Glassfish, since it wasn't working when I last left it. Yesterday, however, I
decided to look at the current version of Glassfish, and discovered that that
old bug has now been fixed, and the connection pooling module once again works
exactly as it did in version 4.1. And the new version will work with Java 21.
So I do have something working now, and actually don't need Tomcat. However,
it does still bother me that I have been unable to get Tomcat to work. The
Tomcat people should consider developing a module like the one they have in
Glassfish.
Web-based configuration tools are somewhat dangerous in our opinion.
Yes, we have some (e.g. manager and host-manager) but they don't
generally mess with configuration files.
JNDI connection pooling requires both the container and the application
to be configured properly, and applications can be configured in myriad
ways, so a tool to configure the pooling for your application would only
go so far.
Patches are always welcome.
I'm still interested in why this isn't working. I've never seen a
situation where JNDI wasn't working and Tomcat generated ZERO error
messages. Is it possible that the files you are editing aren't the ones
being deployed into the container? Are you using anything that might
take control of any JNDI namespaces in the JVM? For me, this always
"just works" and so no configurator-style tool is necessary :/
-chris
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, June 19, 2024 12:34 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat MySQL Connection Pooling JNDI lookup
Daniel,
On 6/19/24 11:40, Daniel Schwartz wrote:
Dear Felix,
Thank you for your reply. The connector jar file is at
C:\Program
Files\apache-tomcat-10.1.24\lib\mysql-connector-j-8.4.0.jar
The latest entry in catalina.2024-06-17.log is copied below. The latest entry
in localhost.2024-06-17.log is copied after that. The two entries are
essentially identical.
The cause of the failure is reported as
Caused by: java.lang.NullPointerException: Cannot invoke
"javax.sql.DataSource.getConnection()" because "this.dataSource" is null
at
com.worldholidaysandevents.restjsonwebservice.HolidaysRestJsonWebServi
ceResource.getJsonCountries(HolidaysRestJsonWebServiceResource.java:56
)
However, this is turn is caused by the failure reported in my previous
email on the line
dataSource = (DataSource) ctx.lookup("jdbc/holidays");
in a file called DataSourceSingleton.java, which is invoked by the
getJsonCountries method. The method is supposed to extract a list of countries
from the database, but the list is returned as null since the JNDI lookup
fails. I identified this failure by putting print statements immediately
before and after this line. The statement before the line outputs its message,
and the one after this line does not. You can see this in the Command Prompt
where Tomcat is running. I copied this error message in my previous email.
Your code looks fine. Fully-specifying the JNDI URL is basically optional, but
it wouldn't hurt.
I would move that context.xml file into your application under
META-INF/context.xml and restore the original conf/context.xml because you do
not need that JNDI resource to be made available to every application on your
server (right?).
I would also recommend NOT using the "root" user for your database connection. I realize
that you are probably "just getting started" but it would be best to use an
application-specific user for your database, and to get into that habit as soon as possible.
----------------------------------------------------------------------------------------------------------
catalina.2024-06-17.log:
-----------------------
17-Jun-2024 15:43:06.184 SEVERE [http-nio-8080-exec-1]
org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse Error while
closing the output stream in order to commit response.
org.glassfish.jersey.server.ContainerException:
java.util.concurrent.ExecutionException:
java.lang.NullPointerException: Cannot invoke
"javax.sql.DataSource.getConnection()" because "this.dataSource" is
null
Are there any other errors you can see in any log file?
Usually, Tomcat will emit an error if the JNDI resource cannot be created.
-chris
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
