Dynamically Get Properties Filename in EJB Jar (deployed in ear)

Question

When creating/deploying war files, I use a in my web.xml to define which property file to use:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">
    <context-param>
        <param-name>PropertiesFile</param-name>
        <param-value>/path/to/my.properties</param-value>
    </context-param>
    <display-name>MyServlet</display-name>
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-class>com.my.company.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>MyServlet</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

and use that in my servlet's init method so that I don't have to hardcode the filename in my code:

public void init(ServletConfig config) throws ServletException
{
    super.init(config);

    log.debug("Enter init()");

    // get the properties location from web.xml
    String propertiesFile = config.getServletContext()
            .getInitParameter("PropertiesFile");

    log.info("Using properties file: " + propertiesFile);

    // Finish intiliazing...
}

Is there something similar (or completely different) to set/get the properties file for an ear that contains an EJB jar without hardcoding it in my class? The properties file won't be included in either the jar or ear but is located on the server outside of the app server.

Answer 1

You can use environment entries and inject them using @Resource to achieve what you want.

Take a look at this OpenEJB example.

However, if you say something like:

The properties file won't be included in either the jar or ear but is located on the server outside of the app server.

It doesn't sound good for an enterprise application. You should not depend on resources outside of the container and not make any assumptions about resources you (or the container) can't control.
Operations on files are also discouraged (if not forbidden - don't remember exactly.)