I have an application running on Openshift. It works fine, but testing is difficult because i have to push every little thing to openshift and wait for all the building and restarting to see the changes.
So i am trying to find a way to test the application locally.
Another guy asked the same thing here: How to test an openshift application on local host, but i am wondering if an easier solution exists.
I used the quickstart project here http://github.com/openshift/spring-eap6-quickstart.git to start it. So basically it is a Spring application using Hibernate.
What i have in mind to have two sets of configuration files (persistence.xml etc.) in the project, one for local Tomcat server and one for Jboss eap and
change web.xml according to the server i want to deploy to. Is this doable? Looks so simple, i am afraid of any surprise problems before changing the
project.
This is how i ended up doing. I renamed the original web.xml file, with something like web-openshift.xml. When projects are built in OpenShift, the maven openshift profile is used. You can find it in your <profiles> section in pom.xml. So i added a line to my pom.xml:
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
....
<webXml>src/main/webapp/WEB-INF/web-openshift.xml</webXml> <!--add this-->
This makes the maven-war-plugin to use the web-openshift.xml file as the web deployment descriptor when building the war. Then i added a web.xml file, which will be used for my local build. In those files you configure your servlets with:
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/jboss-as-spring-mvc-context.xml</param-value>
So by changing the <param-value> in my two web.xml files, I was able to configure Spring and Hibernate in different ways.
Then I added the jars marked as <provided> in pom.xml to the \lib directory of my Tomcat installation. Now i am able to deploy and run the application both to OpenShift and Tomcat.
If you have a fast connection you can run your app on a local server, and let the persistence.xml point to the openshift db. To access the db remotely you will have to use port forwarding(https://www.openshift.com/blogs/getting-started-with-port-forwarding-on-openshift ). You will need to setup the rhc client (https://www.openshift.com/developers/rhc-client-tools-install) and run the rhc port forward client to access the database.
You can then point just run the eclipse project on your tomcat server, and it will ( with persistence.xml I assume you are using a db) connect to the database. Any code changes will be treated like any other tomcat project.
There is no need to have a separate web.xml for most case (unless you have some openshift specific configurations).
You can even use tools like Toad to connect to the db if you want.
In an app that I have running both locally and on Openshift, I used the persistent app-root/data folder to store any specific OpenShift configuration.
In my web.xml, I am including the properties as follows:
<context:property-placeholder location="file:${user.home}/app-root/data/configuration.properties"/>
If you're managing sensitive configuration properties like usernames and passwords, Openshift's env variables can go a long way. For example, you can put the following properties in your pom.xml, under the openshift profile:
<properties>
<db.username>${env.OPENSHIFT_POSTGRESQL_DB_USERNAME}</db.username>
<db.password>${env.OPENSHIFT_POSTGRESQL_DB_PASSWORD}</db.password>
<db.connectionURL>postgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:5432/${env.PGDATABASE}</db.connectionURL>
</properties>
To retrieve your database connection properties from the Openshift environment variables. You can then use maven's resource filtering to put these properties into any files in specific directories like src/main/resources
My own local db connection properties are managed in a profile in my ~/.m2/settings.xml file.
This approach enables me to:
- keep all sensitive properties out of my public code repository
- very simply switch between openshift and local deployment by enabling/disabling maven build profiles.
