Changing a datasoure using Hibernate

[marilyn murphy]

I am currently supporting a java application that uses hibernate. I have not used hibernate before. My task is to update the datasources to use new urls. I thought it would be pretty easy.... just search the app for the existing urls (10.*.*.*) and replace with the new urls (146.*.*.*) in the xml files, but it isn't working.

         <property name="connection.driver_class">com.ibm.db2.jcc.DB2Driver</property>
<!--    <property name="connection.url">jdbc:db2://10.*.*.*:<port>/<database1>:sslConnection=true;sslTrustStoreLocation=/opt/WebSphere/AppServer/java/8.0/jre/lib/security/cacerts;</property> -->
        <property name="connection.url">jdbc:db2://146.*.*.*:<port>/<database1>:sslConnection=true;sslTrustStoreLocation=/opt/WebSphere/AppServer/java/8.0/jre/lib/security/cacerts;</property> -->
        <property name="connection.username">marilyn</property>
        <property name="connection.password">pwd</property>

I change this xml, rebuild using ant and deploy to Tomcat.
Everything seems to work fine at first ...

(WebToolServlet.java:1145) - ...creation of slamandb data source successful.
2020-11-16 13:11:11,581 [http-nio-8080-exec-3] [DEBUG] (LoginPlugin.java:59) - PERFORMANCE: Step6: after authenticate users   took 2013 ms.
2020-11-16 13:11:11,586 [http-nio-8080-exec-3] [DEBUG] (LoginPlugin.java:84) - Authenticated user marilyn
and then I get the error
java.sql.SQLException: Cannot create PoolableConnectionFactory ([jcc][t4][2043][11550][4.16.53] Exception java.io.FileNotFoundException: Error opening socket to server /10.*.*.* 
on port 50,002 with message: \optWebSphere\AppServer\java\8.0\jre\lib\security\cacerts (The system cannot find the path specified.). ERRORCODE=-4499, SQLSTATE=08001)

There are two issues with this error
#1 it is trying to open a connection to a 10. address that I commented out
#2 It is using the wrong path to cacerts

I feel that if I resolve the first issue, the second one will also be resolved. But why is it trying to open a connection to an IP that has been commented out? I've searched the code multiple times for any reference to the 10. ips and they have all been commented out
I have done a clean build
I have deleted the war file and the expanded folder that Tomcat created when it deployed the war file and replaced it
I have searched inside the war file for the 10. IP (I found none that were not commented out). (I searched all the files, not just the xml files using Eclipse and also on the command line)

C:\apache-tomcat-9.0.39\webapps\rm_uat>grep -ri "10.*"
./WEB-INF/classes/hibernate-config/hibernate.dsnbat.cfg.xml:    <!--    <property name="connection.url">jdbc:db2://10.*.*.*:<port1>/<database1>:sslConnection=true;sslTrustStoreLocation=/opt/WebSphere/AppServer/java/8.0/jre/lib/security/cacerts;</property> -->
./WEB-INF/classes/hibernate-config/hibernate.rptdb.cfg.xml:<!--         <property name="connection.url">jdbc:db2://10.*.*.*:<port2>/<database2>:sslConnection=true;sslTrustStoreLocation=/opt/WebSphere/AppServer/java/8.0/jre/lib/security/cacerts;</property> -->
Binary file ./WEB-INF/classes/test/com/ibm/global/gsmrt/db/DatabaseTest.class matches

What could I be missing?
(I realize that the sslTrustStoreLocation is not in Tomcat, but it's working this way in production currently, so that is not the issue)

[Tim Holloway]

Something seems off about that. It sounds like you have a webapp with hard-coded database connection information in it. The only excuse for ever doing that in my book would be if the app is a general-purpose database editor, and definitely not a Hibernate app.

Ordinarily you should be using a JEE Database Connection Pool, and Connection Pools should not be part of the webapp, but instead part of the webapp server. You can share a single pool between multiple webapps, and define the pool in Tomcat's conf/server.xml file, but more often each webapp would have its own associated pool, defined in that webapp's server-dependent deployment information.

JEE defines 2 sets of deployment data for every deployed webapp. The server-independent deployment data, which is /WEB-INF/web.xml including data dynamically added to it via annotations.

The server-dependent deployment data, is, as its name indicates variable depending on what webapp server you use. For Tomcat, it's contained in a Context XML element. The Context element can be defined in a file in the WAR: /META-INF/context.xml and/or supplied externally, in which case the WAR Context is overridden. A Context is generated automatically when you drop a WAR into TOMCAT_HOME/webapps, but it's minimal and will not include database connection pool info.

For maximum flexibility, use an external Context XML file. By default, this will be located in the TOMCAT_HOME/conf/Catalina/localhost directory and be named "something.xml", where "something" is the context path name that the webapp will be deployed under. The contents of that file, like those of the WAR context file are a single Context XML element and its children.

And THAT, is where you'd define your webapp's connection pool(s).

Note that since the external context file is indeed external to the WAR, you can re-target database servers without updating the WAR. That's my standard practice for having the same WAR file used for testing and production, which cuts down on confusion and possible security problems arising from building custom for each environment.

I use Spring Data JPA with Hibernate JPA, and Spring will automatically inject the pool service point into the webapp via JNDI, but if you're not using Spring, you can always look up the pool and connect it manually as part of your app startup code.

[Marilyn de Queiroz]

Tim Holloway wrote:Something seems off about that. It sounds like you have a webapp with hard-coded database connection information in it. The only excuse for ever doing that in my book would be if the app is a general-purpose database editor, and definitely not a Hibernate app.

If it were hard-coded into the webapp, I think it would show up in my search. The connections were only found in the xml/properties files. Nothing in the java code or the jsps (this is a really old application originally written in 2002)
As I said, I searched using Eclipse and also in the command line and also using grep (cygwin) and did not find any 10 dot IPs that were not commented out in the xml config files

[Tim Holloway]

Hi Marilyn,

I can do Skype, but it would be text-only, since my wife stole my headset for her job. Or if you think Slack will work better, we can try that.

Main thing I need to know is the exact path/filename of your "xml/properties" files. Just to make sure I know what they are. Probably will want to look at them, but the name/location is the most important part, since I can work up some reasonable contents given that.

Also, just to make sure, check that you don't have more than one Tomcat server on the machine that you're talking to - and that you're talking to the right Tomcat server machine. Right files on wrong machine have been known to cause me a lot of confusion.

[Marilyn de Queiroz]

Thank you very much for being willing to help me. I did find one more file in Tomcat itself (context.xml) that was separate from the Tomcat context.xml that I could see in Eclipse that contained the wrong IPs. After I updated that file in both places, I am now getting a different (handshake) error. I think that is not related to hibernate and will investigate more on that Friday.

Happy Thanksgiving.

[Tim Holloway]

If you're referring to TOMCAT_HOME/conf/context.xml, that file should not contain any datasource definitions. I think it's actually used as the basis for default deployments and it has, as they say, "No User Serviceable Parts inside".

In other words, it should not be modified by civilians. And it absolutely should NOT have any hostname or IP references in it.

You might check TOMCAT_HOME/conf/server.xml also. That file could be modified under rare circumstances and one of those rare circumstances is when you want to define a DataSource pool that's shared among multiple web applications. But in theory, that would get overridden if a specific webapp's Context.xml chose to do so. The JNDI pathname would probably be the thing to look at.