The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Stephan van Hulst wrote:So, can you show us the code where you retrieve the data source from the context?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:It will not do.
When you use the Tomcat database connection pool resource, Tomcat itself constructs and owns the pool and all the connections in the pool. Your web application does not (and SHOULD not) know the database URL, user ID or password.
To obtain a Connection from that pool, your web application code should do a JNDI lookup on the JNDI directory path "java:comp/env/jdbc/hi5". The object that the lookup returns will be a pool connection ready to be used immediately.
It is important to note, however, that you should explicitly close that Connection as soon as you are done using it, so that it may be returned to the pool for other users to use. If you do not do so, the pool will run dry and future users will not be able to obtain connections.
In a similar vein, do not attempt to save pool connections between HTTP service requests (for example, by storing them in an HttpSession). First, because that violates the previous recommendation, and more importantly, Connections are not serializable objects, so attempting to save them is an object that MUST be serializable (HttpSession) can result in random unpleasant results.
tangara goh wrote:
The information such as database URL, user ID or password are all inside a properties file which is in the classpath.
Will that not do?
This webapp consists of JSP, Servlet, JPA and hibernate.
Also, I'd like to know if it is necessary to add a listener in order for the connection to work ?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:
tangara goh wrote:
The information such as database URL, user ID or password are all inside a properties file which is in the classpath.
Will that not do?
This webapp consists of JSP, Servlet, JPA and hibernate.
Also, I'd like to know if it is necessary to add a listener in order for the connection to work ?
No. It will not do. You should be using a Connection pool. The connection pool is defined for the server, not for the webapp, and, in fact, it's perfectly valid for more than one webapp to use a common connection pool.
The URL, userid and password are not needed in the webapp. In fact, that's both a security risk and a complication when testing webapps. The URL, userid and password are defined as part of the pool Resource definition in Tomcat, which is part of the context.xml, conf/Catalina/localhost/context.xml or server.xml file. These are all Tomcat configuration files, although context.xml is an optional part of the WAR known as the "server-dependent deployment descriptor".
If you define the pool properly, getting access to the pool is as simple as a JNDI lookup of that pool in your application code. Nothing else is actually required.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Consider Paul's rocket mass heater. |