Project

General

Profile

Smart props - DONE » History » Revision 11

Revision 10 (Henning Blohm, 05.03.2017 22:14) → Revision 11/14 (Henning Blohm, 05.03.2017 22:16)

h1. Smart Props (#1697) 

 The goal of this concept is to provide facilities to simplify sharing of component configuration, making use of system and environment variables while still being able to query resolved component configuration efficiently and with minimal resource usage. 

 h2. Latest Design 

 In order to maximize compatibility and flexibility the following design has been chosen: 

 Component properties can be marked with a processing style. To do so, the property name is qualified with an appended, colon separated style descriptor. For example, 

 <pre> 
 someProp\:JEXL3="This is a JEXL3 string" 
 </pre> 

 marks the property "someProp" as being of style <em>JEXL3</em>.  

 <b>Note #1:</b> Colons need to be escaped using a backslash to be part of the name. 

 Running into an expression like this, z2 will hand it off to an IComponentDescriptorProcessor for evaluation. In this particular case it would be the included JEXL3 processor. 

 <b>Note #2:</b> There is still a uniqueness requirement. The same property name ("someProp" in this case) may not be used with more than one style qualifier. 

 h3. The plain style 

 There is a defaulting style "plain". That is, declaring a property  

 <pre>x=...</pre> 

 is equivalent to  

 <pre> 
 x\:plain=... 
 </pre> 

 h3. The JEXL3 style 

 A built-in processor is based on the "Apache Commons JEXL library":http://commons.apache.org/proper/commons-jexl. 

 JEXL offers a simple and versatile expression language. See "here":http://commons.apache.org/proper/commons-jexl/reference/syntax.html for a syntax reference.  

 The JEXL3 style offers some implicit variables so that you can easily access system properties, environment variables, and other components.  

 Example expressions: 

 Set path based on user's home folder: 
 <pre> 
 importPath\:JEXL3=system['user.home']+"/import" 
 </pre> 

 Copy a database configuration: 
 <pre> 
 ds.prop.user\:JEXL3=components.getComponent("environment/mainDB").getProperty("ds.prop.password") 
 ds.prop.password\:JEXL3=components.getComponent("environment/mainDB").getProperty("ds.prop.user") 
 ds.prop.url\:JEXL3=components.getComponent("environment/mainDB").getProperty("ds.prop.url") 
 </pre> 

 Copy a database configuration: 
 <pre> 
 ds.prop.user\:JEXL3=components.getComponent("environment/mainDB").getProperty("ds.prop.password") 
 ds.prop.password\:JEXL3=components.getComponent("environment/mainDB").getProperty("ds.prop.user") 
 ds.prop.url\:JEXL3=components.getComponent("environment/mainDB").getProperty("ds.prop.url") 
 </pre> 

 String with expressions: 
 <pre> 
 message\:JEXL3=`Sorry. We do not serve users called "${system['user.name']}" at ${env.JAVA_HOME}` 
 </pre> 

 Conditional expressions: 
 <pre> 
 osChoice\:JEXL3=system["os.name"].startsWith("Linux")? "We are running on a Linux OS" : "We are running on something else" 
 </pre> 




 ---- 


 h2. Previous work: Design Draft 

 {children} 



 What we aim for is an extended _properties_ format that allows declarative inclusion of other component's configuration and the use of some expression language style substitution of variables. In other words, we strive for the use of a template processing language. 

 The prospective candidate is the "Java Unified Expression Language":https://en.wikipedia.org/wiki/Unified_Expression_Language based on the implementation "JUEL":http://juel.sourceforge.net/ 

 <b>Update:</b> As JUEL seems to be pretty dead and support is not clear, currently Java Expression Language ("JEXL":http://commons.apache.org/proper/commons-jexl/) is the preferred candidate.  

 Built-in implicit contexts include  

 * system properties,  
 * environment variables,  
 * other component properties (_lookup(<name>)_),  
 * the component name,  
 * the module name. 

 Example: A repository declaration could look like this: 

 <pre> 
 com.zfabrik.component.type=com.zfabrik.svncr 

 svncr.url=${system['svn.repoBaseUrl']}${system.branch}/base 
 svncr.user=${system['svn.user']} 
 svncr.passwordr=${system['svn.password']} 
 </pre> 

 h2. Resolution Flow 

 In principle, expressions could be resolved early, during local component repository index load, or late, during component descriptor evaluation. 

 h3. Early Evaluation 

 This approach has the advantage that component queries would already take resolved component properties into account. Using this method, even system state participations or the visibility as component as such could be controlled via expressions. 

 We strive for early evaluation.  

 h2. Processing Scope 

 Allowing template processing means that we do not only process the value part of component properties, but instead the complete component descriptor as a text fragment. A sufficiently powerful expression language might as well introduce properties as desired. 


 h2. Possible extensions 

 To extend this further, component declarations may indicate their template style via some "Shebang":http://de.wikipedia.org/wiki/Shebang, the default being *java.util.Properties*. 

 For example: 

 <pre> 
 #!com.zfabrik.components/velocityConfig 
 # 
 com.zfabrik.component.type=com.zfabrik.java 

 #parse('mymodule/spring_template') 

 java.privateReferences=,\ 
   ${java_private_references},\ 
   someotherref 
 </pre>