CODEWITHSUNDEEP
javawebsphere
user2210071
user2210071

Reputation: 203

How to read external properties files in WebSphere?

I developed a sample web application which will read the data from an external properties file. The properties file is in the source folder in my system and is not included inside the WAR file.

The property file is accessed like this:

Properties prop = new Properties();
//File f1 = new File("Property.properties");
prop.load(getClass().getClassLoader().getResourceAsStream("Property.properties"));
  1. How do I access this property file externally inside the WAR file?
  2. What changes have to be made in the code to read it in the WAR file?

Upvotes: 3

Views: 15765

Answers (3)

weberjn
weberjn

Reputation: 1985

WebSphere has two folders on the classpath, properties can be loaded from there:

Enterprise Applications > myear > Manage Modules > myjar.jar > Class loader viewer 4 - Extension - com.ibm.ws.bootstrap.ExtClassLoader

file:/projekte/IBM/WebSphere/AppServer-8.5/classes/

file:/projekte/IBM/WebSphere/AppServer-8.5/lib/

Upvotes: 0

Jacek Laskowski
Jacek Laskowski

Reputation: 74709

I think the most versatile approach is to define a simple environment entry as described in the section EE.5.4 Simple Environment Entries of Java™ Platform, Enterprise Edition (Java EE) Specification, v5.

From the section (page 68):

A simple environment entry is a configuration parameter used to customize an application component’s business logic. The environment entry values may be one of the following Java types: String, Character, Byte, Short, Integer, Long, Boolean, Double, and Float.

You may also use URL connection factory as described in the section EE.5.6.1.4 Standard Resource Manager Connection Factory Types of the specification.

The Application Component Provider must use the java.net.URL resource manager connection factory type for obtaining URL connections.

Both require a definition of a resource reference in the deployment descriptor WEB-INF/web.xml of your web application so you can inject the value using @Resource or use JNDI API with java:comp/env as the entry point.

The benefit is that you can change the configuration of your web application without having to recompile the code as well as let you change it using an application server's administrative tools your admins are accustomed with.

In web.xml you define the resource reference.

<resource-ref>
  <res-ref-name>propertiesURL</res-ref-name>
  <res-type>java.net.URL</res-type>
  <res-auth>Container</res-auth>
  <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
<resource-ref>
  <res-ref-name>propertiesPath</res-ref-name>
  <res-type>java.lang.String</res-type>
  <res-auth>Container</res-auth>
  <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

Then in your code you use the following to access the values:

@Resource
String propertiesPath;

@Resource
URL propertiesURL;

With this you met the requirements of Java EE and you can use propertiesPath or propertiesURL as if they were passed as input parameters to your methods.

Now, it's time to meet expectations of WebSphere Application Server.

What you defined are logical names that need to be mapped to their administered names (an application server knows about and can provide to the application).

In WebSphere Application Server you use WebSphere Binding descriptor WEB-INF/ibm-web-bnd.xml with the following configuration:

<?xml version="1.0" encoding="UTF-8"?>
<web-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-bnd_1_1.xsd"
  version="1.1">

  <virtual-host name="default_host" />

  <resource-ref name="propertyURL" binding-name="propertyURL" />
  <resource-ref name="propertyURL" binding-name="propertyURL" />
</web-bnd>

When the application gets deployed WAS allows you to map these mappings to its administered resources. Use the ISC console to define values of the environment entries and map them to the application.

It has became easier with WebSphere Liberty Profile. I described the mechanism as offered by WLP in my article Using @Resource to access JNDI in WebSphere AS 8.5 Liberty Profile.

Upvotes: 8

Jens Schauder
Jens Schauder

Reputation: 81990

You have three options:

  1. configure the Websphere to include the directory which contains the property file in the classpath. Don't know how to do it, but I'm sure it is possible, since our application does the same thing

  2. include the property file in the war archive. You probably don't want to do that.

  3. instead using the classloader to load the property file use the file api with an absolute path. I'm not completely sure WAS does allow that, but it is a bad idea anyway, because it makes your application very dependent on things that it really shouldn't care about, such as the installation path of your application.

Upvotes: 1

Related Questions