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

        Hide
        Darious3 added a comment -

        Bill, I don't know about Resin but in JBoss you have to activate this feature explicitly by making a change in standalone.xml. Everybody who makes this change should know the result is not Java EE compatible anymore.

        I believe JBoss has kept this functionality to their product-specific deployment descriptors (e.g. jboss-web.xml) for years, but I guess the demand for having this in the standard descriptors as well was so huge that they could no longer ignore it.

        It's a big, very big tradeoff for application architects to make now. Portable deployment descriptors are almost holy. Like you said, their most important virtue is being portable. But, not being able to substitute settings in web.xml is such a nuisance and has always been such a nuisance that this feature is just to good to ignore.

        Case in point; we need the Facelets refresh setting in web.xml be a -1 (no refresh) for production and 0 (always refresh) for development. Having a $

        {facelets.refresh:-1}

        there so developers can configure their JBoss server to start up with -Dfacelets-refresh=0 makes a lot of things so much easier for everyone. Same goes for things like JPA query logging.

        Show
        Darious3 added a comment - Bill, I don't know about Resin but in JBoss you have to activate this feature explicitly by making a change in standalone.xml. Everybody who makes this change should know the result is not Java EE compatible anymore. I believe JBoss has kept this functionality to their product-specific deployment descriptors (e.g. jboss-web.xml) for years, but I guess the demand for having this in the standard descriptors as well was so huge that they could no longer ignore it. It's a big, very big tradeoff for application architects to make now. Portable deployment descriptors are almost holy. Like you said, their most important virtue is being portable. But, not being able to substitute settings in web.xml is such a nuisance and has always been such a nuisance that this feature is just to good to ignore. Case in point; we need the Facelets refresh setting in web.xml be a -1 (no refresh) for production and 0 (always refresh) for development. Having a $ {facelets.refresh:-1} there so developers can configure their JBoss server to start up with -Dfacelets-refresh=0 makes a lot of things so much easier for everyone. Same goes for things like JPA query logging.
        Hide
        reza_rahman added a comment -

        This is how Resin does it: http://wiki4.caucho.com/Resin:_Application_Server:_Parameterized_Web_Server_Cluster. It is completely Resin specific and bound to Resin deployment descriptors. This is a general pattern in Resin (favoring Resin deployment descriptors and even creating outright one-to-one alternatives to standard XML deployment descriptors - perhaps too much so) as the standard XML descriptors are seen as needing a significant overhaul/modernization. This is something I've mentioned in the EG in the past as well.

        Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Show
        reza_rahman added a comment - This is how Resin does it: http://wiki4.caucho.com/Resin:_Application_Server:_Parameterized_Web_Server_Cluster . It is completely Resin specific and bound to Resin deployment descriptors. This is a general pattern in Resin (favoring Resin deployment descriptors and even creating outright one-to-one alternatives to standard XML deployment descriptors - perhaps too much so) as the standard XML descriptors are seen as needing a significant overhaul/modernization. This is something I've mentioned in the EG in the past as well. Please note that these are purely my personal views and certainly not of Oracle's as a company.
        Hide
        Bill Shannon added a comment -

        Darious3, it's important to remember the key Java compatibility rule
        that we call the "all modes" rule - a product must be compatible
        all the time, in all modes, no matter how you configure it. There
        can be no documented settings that make the product behave differently
        than required by the specs.

        (Further discussion of this issue is best done on the mailing list.)

        Show
        Bill Shannon added a comment - Darious3, it's important to remember the key Java compatibility rule that we call the "all modes" rule - a product must be compatible all the time, in all modes, no matter how you configure it. There can be no documented settings that make the product behave differently than required by the specs. (Further discussion of this issue is best done on the mailing list.)
        Hide
        arjan tijms added a comment -

        A related discussion on the JBoss mailing list: http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001522.html

        It also looks like the Java EE configuration as proposed by e.g. http://www.jfokus.se/jfokus13/preso/jf13_JavaEEConfiguration.pdf is not actually happening. Instead there's a Java configuration JSR proposal, but for now if I understand it correctly it seems to focus more on Java SE and injection and not really on Java EE deployment descriptors (but maybe I misunderstood). See https://groups.google.com/forum/#!forum/java-config

        Show
        arjan tijms added a comment - A related discussion on the JBoss mailing list: http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001522.html It also looks like the Java EE configuration as proposed by e.g. http://www.jfokus.se/jfokus13/preso/jf13_JavaEEConfiguration.pdf is not actually happening. Instead there's a Java configuration JSR proposal, but for now if I understand it correctly it seems to focus more on Java SE and injection and not really on Java EE deployment descriptors (but maybe I misunderstood). See https://groups.google.com/forum/#!forum/java-config
        Hide
        atsticks added a comment - - edited

        Hi all, I have talked with Mike Keith at JavaOne 2013. Mike told me, that he will not be able to lead the config JSR. Nevertheless, we are on the way preparing such a JSR, so it should happen The JSR will run under the EE umbrella, but since it should also cover deployment aspects, it must quite probably also be executable before CDI and other resources are available. So the configuration service must be capable of running on the system context already. From a runtime perspective (despite security manager being active, and some other aspects), this matches quite well with a pure SE environment. Also I highly recommend separating concerns to have better control on the complexity and to be able to focus the JSR from the start (having more effective discussions).
        Summarizing I currently think we need:

        • a basic configuration service, with a configurable meta model, that is defining the base configuration services available. It will out of the box support system and environment properties, program arguments as well as reading property (and XML property) files from any resolvable resources.
        • the basic service will also have to provide extension points to add functionality, e.g. by some adapter, operator and query patterns.
        • the EE part then should define, how the configuration service should be setup and deployed in a EE container (e.g. shared on system level, or within the ear/war context).
        • And it should define, in collaboration with the other EE specs, how descriptors can be provided/extended/overriden using the new capabilities available(or descriptor parameters, and also other resources). There are different possibilities how to achieve this and I assume we will have some discussions how this should be done best.

        So the aspects described in this ticket will be definitively in focus for the upcoming JSR

        Regards,
        Anatole

        Show
        atsticks added a comment - - edited Hi all, I have talked with Mike Keith at JavaOne 2013. Mike told me, that he will not be able to lead the config JSR. Nevertheless, we are on the way preparing such a JSR, so it should happen The JSR will run under the EE umbrella, but since it should also cover deployment aspects, it must quite probably also be executable before CDI and other resources are available. So the configuration service must be capable of running on the system context already. From a runtime perspective (despite security manager being active, and some other aspects), this matches quite well with a pure SE environment. Also I highly recommend separating concerns to have better control on the complexity and to be able to focus the JSR from the start (having more effective discussions). Summarizing I currently think we need: a basic configuration service, with a configurable meta model , that is defining the base configuration services available. It will out of the box support system and environment properties, program arguments as well as reading property (and XML property) files from any resolvable resources. the basic service will also have to provide extension points to add functionality, e.g. by some adapter, operator and query patterns . the EE part then should define, how the configuration service should be setup and deployed in a EE container (e.g. shared on system level, or within the ear/war context). And it should define, in collaboration with the other EE specs, how descriptors can be provided/extended/overriden using the new capabilities available (or descriptor parameters, and also other resources). There are different possibilities how to achieve this and I assume we will have some discussions how this should be done best. So the aspects described in this ticket will be definitively in focus for the upcoming JSR Regards, Anatole

          People

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

            Dates

            • Created:
              Updated: