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