Spring JSF Hibernate - Get variables from catalina.properties inside xml files and class

[Partheban Udayakumar]

Hi all

We are currently working on a project that is a combination of Spring, JSF and Hibernate. Recently we completed the project and we tried to deploy it in amazon cloud (s3-amazon or elastic beanstalk, I don't know much about this, pardon me if I am wrong). Another team which works on JSF have already deployed in cloud and they are using the database connection string from catalina.properties file. They have been using

System.getProperty("JDBC_URL");

to retrieve the property but when I tried the same with my project, it returns null. Out of curiosity, I tried the following

Properties properties = System.getProperties();
    Enumeration<Object> keys = properties.keys();
    while (keys.hasMoreElements()) {
        String param = (String) keys.nextElement();
	System.out.println(param);
    }
    Collection<Object> propsTable = properties.values();
    for (Iterator<Object> iterator = propsTable.iterator(); iterator.hasNext();) {
        Object object = (Object) iterator.next();
	System.out.println("Object: " + object);
    }

It returned around 68 properties none of which was my jdbc url. So if I am defining the jdbc url in catalina.properties, how do I use it in my xml configuration files (applicationContext.xml & springrestcontroller-servlet.xml) and as well as in my java class. If adding the details to catalina.properties is not the correct way, what would be the alternative? In my config xml's I use url, username and password as 3 different variables for initializing Hibernate session factory. Can I use the String I am retrieving as a single variable(jdbc-url) in both my config xml files ?

[Tim Holloway]

"catalina.properties" is a Tomcat configuration file. You would have attracted more expertise by asking about this in the Tomcat forum.

The catalina.properties file is also a bad place to put server and application configuration data. It is intended to provide configuration data for the Tomcat internal functions and I've never heard of anyone customizing before outside of people who are actually building custom Tomcat servers.

A MUCH better way to handle this is via Context properties if you are configuring database information on a per-application basis, or in the TOMCAT_HOME/conf/server.xml file for Connection pools that are shared between multiple apps.

You can then use JNDI to retrieve this data like so:
<!-- DataSource --> <bean id="myDataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/jdbc/localDB" /> </bean> <!-- Persistence Definitions --> <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> <property name="dataSource" ref="myDataSource" /> <property name="loadTimeWeaver"> <bean class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver" /> </property> <property name="packagesToScan" value="com.mousetech.persistence.model"/> <property name="jpaPropertyMap" ref="jpaPropertyMap"/> <property name="jpaVendorAdapter"> <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"> <property name="showSql" value="false" /> <property name="generateDdl" value="true" /> <property name="databasePlatform" value="org.hibernate.dialect.DB2Dialect" /> </bean> </property> </bean>

The above Spring configuration elements will tap into a standard Tomcat JDBC Connection Pool (name, in this case, "localDB") and use it as a resource to the EntityManagerFactory used by Hibernate JPA.

Spring does all the heavy lifting. There are no System.getProperty calls (which are a bad idea in a webapp anyway), or even any JNDI logic in the application (since Spring handles it for you). Just an EntityManager which can be injected into the DAO classes via the @EntityModel annotation.

[Partheban Udayakumar]

Tim Holloway wrote:Just an EntityManager which can be injected into the DAO classes via the @EntityModel annotation.

I am not sure if I got this the right way. Could you please show me the localDB file and since you have written "/env/jdbc/localDB", I guess you are working in a Linux environment. Could you also please explain me the localDB location?

[Tim Holloway]

There is no "localDB file" and while this particular webapp was running under Linux, that's not why the JNDI lookup key is coded like it is. The exact same syntax would be required under Windows. Use this as a reference: http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html

"localDB" is the JDBC Connection pool being used by this web application. You can define shared Connection Pools in the Tomcat server.xml file, but this particular pool is being used by a single webapp, so it's defined as part of the server-dependent deployment descriptor for that webapp:

<?xml version="1.0"?> <!-- Context configuration file for the WMS web app. --> <Context path="/WMS-tomcat" docBase="/home/timh/workspace/WMS-webapp_v3_12/target/WMS-tomcat" privileged="true" > <Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader" /> <Resource name="jdbc/localDB" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="wmsdb" password="secret" driverClassName="com.ibm.db2.jcc.DB2Driver" url="jdbc:db2://www3.mousetech.com:50001/test0" /> </Context>

[Partheban Udayakumar]

Tim,

Thanks for the reply.

From here, it says

It is NOT recommended to place <Context> elements directly in the server.xml file. This is because it makes modifying the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.

but you have suggested to make changes in server.xml I am now

[Tim Holloway]

No I am not.

If you wanted a Connection Pool that was shared between multiple Contexts, you would define that pool in server.xml. Most of the time, however, each webapp has its own Connection Pool(s) and they are then defined in the Context element that is used to deploy the webapp and server.xml is not modified.

That Context element should either be in a META-INF/context.xml file in the WAR or in a file in the conf/Catalina/localhost directory under the same name that will define the context part of URLs targeting that webapp. I often create a META-INF/context.xml file with default deployment information in it, but use a conf/Catalina/localhost context XML file to override that default information.

[Partheban Udayakumar]

Tim

Can you show me a sample of the context.xml?

[Tim Holloway]

I already did. Look upwards in this thread.

[Partheban Udayakumar]

Tim

I thought the above code was a part of server.xml. I shall check and get back to you.

[Tim Holloway]

You can put a Context in server.xml. However, doing so is strongly discouraged.

See http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html

Also see http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html