Monday, May 26, 2014

A Proposal for Java EE Configuration (Follow up)

A Proposal for Java EE Configuration (Follow up)

Given all the feedback and discussions from last week I would come up with the following more concrete feature list, what should be covered IMO. Finally I outline a rough server lifecycle including configuration. As always feedback is welcome!

High Level Features

  • Define mechanisms to​ enable applications being deployed by adding configuration externally (from an application viewpoint). This means it must be theoretically possible to configure an application completely externally. This would include loading and providing existing deployment descriptors and other configuration files to be provided based on external configuration.
  • Define mechanisms to provide deployment descriptors, e.g. by some API or more generic, accessible under certain keys. Alternatively a common configration access point for EE configuration is defined that can be used, by other JSRs.
  • From a DevOps perspective, also additional aspects, today configured outside of an ear/war archive should be considered, such as security setup, data sources, message queues, worker thread pools etc. This is also one of the more interesting areas, where we must see in what kind of runtime environment we are running. If CDI 2.0 would define some shared system level container, this will be the place to be, if not application servers must load EnvironmentManager and ConfigurationManager and provide them as JNDI entries.
  • Application configuration is also very important for portability. A key/value store has shown in a variety of frameworks its strengths, so with another 10+ interfaces this feature should also be included. 
  • Wiring and injection of the effective configuration should be done based on CDI. 

Additional Details

  • Environments are hierarchic, meaning environment settings from lower levels, e.g. startup are also visible in inheriting contexts, but may be overriden. Environments also define the basic hierarchy levels for configuration.
  • At a current runtime point exact one environment is active.
  • An environment provides a Stage, which is predefined. Additional custom stages can be realized by adding additional properties to the environment. An SPI allow to add additional values to an environment.
  • Configuration (parts) can be active/non active based on the current environment.
  • All configured String values support EL syntax to be used for wildcards and cross-references and dynamic replacements.
  • Default values can be deployed along the code by adding configuration to a configuration.xml loaded deployed with the code on the classpath.
  • Application Configuration basically is modelled along the environment hierarchy and thus runtime dependent, whereas deployment configuration is identified by the requested target state.

Portable and Externalizable Application Configuration

  • A common application.xml file (name and location to be discussed) will be defined, which summarizes all/most configuration aspects as of today. 
  • Similarly a programmatic Java API is defined that allows to configure an application, modelling the same features as the application.xml. An instance of such an object can be injected as a configuring resource into the CDI container (e.g. ApplicationConfiguration). From a user's persepctive this can be an implementation based on the application.xml (default) or provided by any other mechanism (including external ones).
  • Configuration may be accessed using a restful service API, that is not active by default.

Out of Scope

  • Versioning of Configuration may be addressed later.
  • The key/value API will be minimal (mostly API only and injection into managed beans). As an advantage most of existing configuration mechanisms could be used to implement the backend needed. Standardizing this mechanism fully for SE will be out of scope for this JSR and might be solved in another separate JSR.

A possible Server Lifecycle

1) Server startup:

  • the shared system (CDI 2.0 ?) container is starting up. This maybe a CDI based container (preferred) or an application server specific one.
  • the configuration JSR root components are loaded as part of the system container and made accessible via JNDI, mainly

    • EnvironmentManager
    • ConfigurationManager

  • If the system container is built on CDI the following aspects are injectable:
    • EnvironmentManager
    • ConfigurationManager
    • (Current) Environment
    • (Current) Stage
    • (Current) Configuration
  • When the current server configuration has been loaded, a config loaded event should be triggered, containing also a reference to the current system Configuration. This event can be used to configure early server resources.

2) Ear/War startup:

  • For each ear (and/or for each war):
  • load "application" CDI context, consider the configuration provided from the system container to configure application CDI.
  • Trigger a config preload event, that the application Configuration will be loaded now.
  • Trigger a config loaded event, that the application Configuration has been loaded and now is available (containing the current Configuration).
All features, including application configuration are fully based/extending CDI. JNDI entries for EnvironmentManager, ConfigurationManager are still the same (access restrictions are to be discussed). If we have some kind of shared a CDI context on system level of the container, we could fully build the configuration system based on CDI.


  1. Thanks a lot! You made a new blog entry to answer my question; I really appreciate your time and effort.
    java training in chennai |
    java training institutes in chennai

  2. I found your blog while searching for the updates, I am happy to be here. Very useful content and also easily understandable providing..
    Believe me I did wrote an post about tutorials for beginners with reference of your blog. 

    Selenium training in bangalore
    Selenium training in Chennai
    Selenium training in Bangalore
    Selenium training in Pune
    Selenium Online training

  3. Post is very useful. Thank you, this useful information.

    Get Best SAP HR HCM Training in Bangalore from Real Time Industry Experts with 100% Placement Assistance in MNC Companies. Book your Free Demo with Softgen Infotech.

  4. Thank you for sharing such a nice post!

    Looking for SAP S4 HANA Simple Logistics Training in Bangalore , learn from eTechno Soft Solutions SAP S4 HANA Simple Logistics Training on online training and classroom training. Join today!

  5. Thank you for sharing such a nice post!

    Looking for Best Training Institute in Bangalore , India. Softgen Infotech is the best one to offers 85+ computer training courses including IT Software Course in Bangalore , India. Also, it provides placement assistance service in Bangalore for IT.

  6. Thanks for one marvelous posting! I enjoyed reading it; you are a great author. I will make sure to bookmark your blog and may come back someday. I want to encourage that you continue your great posts.Prathima Infotech training center bangalore

  7. Thanks for sharing this blog. This very important and informative blog. content

  8. This comment has been removed by the author.