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.