Setting up a Postgres JDBC JNDI connection in Tomcat

49 views
Skip to first unread message

Hrafn Malmquist

unread,
Nov 30, 2020, 11:01:48 AM11/30/20
to DSpace Technical Support
I am trying to set up a Postgres JNDI globally shared connection is running running several DSpace webapps.

I have been largely assisted by the official documentation here [0] and here [1] as well as DSpace documentation here [2] and discussion on a user mailing list for DSpace here [3].

I am running:

CentOS Linux release 7.8.2003
Tomcat 9.0.12
PostgreSQL 9.5.23
openjdk version "1.8.0_262"
OpenJDK Runtime Environment (build 1.8.0_262-b10)

  1.  I downloaded postgresql-42.2.18.jar from https://jdbc.postgresql.org/download/postgresql-42.2.18.jar and placed it in /home/lib/dspace/apache-tomcat-9.0.12/lib
  2. In /home/lib/dspace/apache-tomcat-9.0.12/conf/server.xml I added the following Resource

    <Resource name="jdbc/dspaceWeb"
                  factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
                  type="javax.sql.DataSource"             
                  auth="Container"
                  username="*****"
                  password="******"
                  driverClassName="org.postgresql.Driver"
                  url="jdbc:postgresql://localhost:5432/dspace"
                  initialSize="5"
                  maxTotal="50"
                  maxIdle="15"
                  minIdle="5" />

    There are a couple of issues that confuse me:
    a) the official documentation about JNDI datasource examples [0] says "This author has not had success here, although others have reported so. Clarification would be appreciated here."  in the section about Postgres. In other words, we can't be sure this works?
    b) in the official documtation about JDBC connection pool it says that if you want to define a JDBC connection pool in the Apache Container (which I understand to be trying to do) you have to specify the factory attribute and set the value to org.apache.tomcat.jdbc.pool.DataSourceFactory [1]

    This is not done in the example (that the author hasn't had success with?) in a)
  3. Created a context.xml in /dspace/webapps/xmlui/META-INF/

    <Context docBase="/dspace/webapps/xmlui">
        <ResourceLink name="jdbc/dspace"
                      global="jdbc/dspaceWeb"
                      type="javax.sql.DataSource"
        />
    </Context>

When I start up Tomcat howere. I get this in the log:

INFO [org.springframework.jndi.JndiObjectFactoryBean] JNDI lookup failed - returning specified default object instead: javax.naming.NameNotFoundException: Name [jdbc/dspace] is not bound in this Context. Unable to find [jdbc].

My understanding is that the webapp, DSpace, tried to look for a JNDI object in the namespace "jdbc/dspace" and barring that, falls back to instantiating it's own DataSource as a bean. See [4]

But I don't understand why the above doesn't work.

Thanks for your time

Sources:

Alan Orth

unread,
Dec 2, 2020, 4:07:24 AM12/2/20
to Hrafn Malmquist, DSpace Technical Support
Dear Hrafn,

You mention creating a context inside the webapp's META-INF directory. Is that a valid Tomcat configuration? I only know about creating contexts in Tomcat's server.xml (not recommended, according to Tomcat's docs¹) and in the Tomcat conf.Catalina/[hostname] directory. Our DSpace instances use Tomcat from the official binary releases rather than from our Linux distribution, and I create the following, for example:

# ls /usr/local/apache-tomcat-7.0.104/conf/Catalina/localhost/
jspui.xml  oai.xml  rest.xml  ROOT.xml  solr.xml

Where each context looks something like this:

# cat /usr/local/apache-tomcat-7.0.104/conf/Catalina/localhost/ROOT.xml
<Context docBase="/home/dspace/webapps/xmlui">
  <ResourceLink global="jdbc/dspaceWeb" name="jdbc/dspace" type="javax.sql.DataSource"/>
</Context>

The conf/Catalina/localhost directory doesn't exist in the binary Tomcat distributions. I can't remember if conf/Catalina exists in the CentOS/Ubuntu distribution. I hope that helps.

Regards,



--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/738f0710-f9a9-41ce-bb42-974bddff1a06n%40googlegroups.com.


--

Hrafn Malmquist

unread,
Dec 5, 2020, 12:10:22 PM12/5/20
to Alan Orth, DSpace Technical Support
Hi Alan

Thanks for getting back to me. Yes, I resolved this by placing the context in an [appname].xml under the [engine] directory. I'm not sure if [appname]/META-INF/context.xml is allowed. The docs seem to suggest it's dependant on whether or not auto-deployment of applications is enabled (see: https://tomcat.apache.org/tomcat-8.0-doc/config/context.html).

Anywho, I got it right finally. 

On a related note, if you or anyone else reading this, find the time to contribute to https://github.com/DSpace/DSpace/issues/3070 that would be great.

Cheers, Hrafn

Alan Orth

unread,
Dec 6, 2020, 3:19:49 AM12/6/20
to Hrafn Malmquist, DSpace Technical Support
Dear Hrafn,

Actually, ironically, in the very same docs I linked above it specifically states that adding a context in [appname]/META-INF/context.xml is allowed. I hadn't heard of that method before! If it's not working for you that sounds like a bug. In my opinion the [engine]/localhost/[appname].xml method is better because I deploy the infrastructure using some templates and I can pre-create those without having to build/install DSpace yet. Anyways, I'm glad you solved it. All of this is relevant for your discussion about documentation and pooling support in https://github.com/DSpace/DSpace/issues/3070. I will try to contribute there.

Regards,

P.S. for anyone reading this, Tomcat 8.0 has been deprecated for several years now. It has been replaced by 8.5 and you should try to run that one (or higher) if possible, unless your distribution provides an 8.0 package that they maintain.
Reply all
Reply to author
Forward
0 new messages