Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      In a Java EE application deployment descriptors are used to configure and setup the application. One major issue is that these deployment descriptors are mostly static. In practice, there's often a need to have a different set of configuration files for different situations.

      For instance, for a development environment I might want a link configured by a context-param in web.xml to point to 'localhost:8080/someapp/myresource', while in a QA environment I want it to point to 'qa.mycompany.com/myresource' etc.

      As another example, since Java EE 6 a data source can be configured in among others web.xml using the data-source element. Especially in this case there is a pressing need to have different data sources pointing to different databases depending on the context.

      Yet another example is a Servlet Filter that provides some development utilities, which should definitely not be activated in a production environment.

      A possible solution for this could be the introduction of descriptor fragments that are included from the main descriptor based on a placeholder. E.g. in web.xml:

      <web-app> 
          ... 
          <fragment>WEB-INF/conf/${mycompany.staging}/web-fragment.xml</fragment>
      </web-app>
      

      Inside the WEB-INF/conf directory, multiple folders could be created, each corresponding to a stage, e.g.

      WEB-INF
          conf
              dev
                  web-fragment.xml
              qa
                  web-fragment.xml
              live
                  web-fragment.xml
      

      Starting up the application with -Dmycompany.staging=dev would then cause WEB-INF/conf/dev/web-fragment.xml to be processed.

      Besides being useful for directing different fragment descriptors to be processed, placeholders can also be used to externalize some values completely. E.g. the password in a production datasource:

      <data-source>
          <name>java:app/someDS</name>
          <class-name>org.example.Something</class-name>
          <url>jdbc:someDB</url>
          <user>${mycompany.someDS.user}</user>
          <password>${mycompany.someDS.password}</password>
      </data-source>
      

      For the above to be really useful, another concept should be introduced: the ability to load system properties from an external properties file. Specifying the above password via a -D command line option is of course not secure, since it can be seen in the running processes (e.g. using the ps command). Something like the following would be more suitable:

      -Djavax.config.properties=/somepath/config.properties.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            ljnelson
            Reporter:
            arjan tijms
          • Votes:
            17 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated: