So at some time a 2010 we split CoreDeploymentInfo[1] into three scoped 
objects, BeanContext, ModuleContext and AppContext.  Each of these contexts 
objects has:

 - a set of Properties so we can track options at each level
 - a chained Options object to allow for property inheritance
 - a typed map for storing live objects similar to 
SystemInstance.get().getComponent(..)

Effectively, this made each of those objects as powerful as the SystemInstance.

What was lacking was the ability completely configure properties at each level. 
 Config ability was added for BeanContext via openejb-jar.xml and EjbModule 
also via openejb-jar.xml, but not for any other module type such as WebModule 
and not for an application as a whole.

As we're growing and adding new configuration options all the time, it became 
clear this code needed to be finished so we can quickly add configuration 
options without having to pave a completely new path each time.

So now a full path is paved.

 - TOMEE-387 - Support for META-INF/application.properties file and overriding
 - TOMEE-386 - Support for META-INF/module.properties file and overriding 
 - TOMEE-385 - Complete application properties scoping

In short, values in META-INF/application.properties files will end up in 
AppContext.getProperties().  Values in META-INF/module.properties files will 
end up in ModuleContext.getProperties().

There is extensive overriding capability as well.

Values in the application.properties file can be overridden via system 
properties with the following format: 

 <property>=<value> 

Also: 

 <appName>.<property>=<value> 


Values in the module.properties file can be overridden via system properties 
with the following format: 

 <property>=<value> 

Also: 

 <moduleName>.<property>=<value> 

Also: 

 <appName>.<moduleName>.<property>=<value> 


When the more generic form is used in system properties, such as 
"<property>=<value>", it applies to all apps and modules that use that 
property.  When a more specific name is used in system properties, such as  
"<appName>.<property>=<value>", it applies to all apps with that name.

The most specific will win.

Properties are not case sensitive, so using the wrong capitalization is no 
problem.  The part of the path that contains the appName or moduleName 
currently is case sensitive (it's a little expensive to do that so didn't add 
it, but we could).


-David

[1]: http://svn.apache.org/viewvc?view=revision&revision=957532

Reply via email to