[jboss-as7-dev] Passing Cloud Configuration.

[Brian Stansberry]

On 8/23/11 3:27 PM, Jason T. Greene wrote:
> On 8/23/11 1:41 PM, Brian Stansberry wrote:
>> Short response:
>>
>> To handle externalized configuration requirements like this, we added
>> expression support to the core AS management layer. My expectation was
>> custom scripts that launch the AS would read some external configuration
>> like your user-data and would set system properties.
>>
>> But the core support that's there is a necessary but insufficient piece
>> to allowing a particular configuration attribute accept an expression.
>> Doing the other bits will require a fair amount of work (see below),
>> work that should be prioritized. So it would be helpful to know what
>> specific things are most critical for you -- at a finer grained level
>> than "datasources", "clustering".
>>
>> The rest of this is to organize a discussion about moving forward on
>> making more config attributes support expressions.
>>
>> Long response:
>>
>> The jboss-dmr library that we use to store configuration information in
>> the AS and for creating operation requests and responses supports an
>> expression notion. That is, a configuration attribute that normally
>> stores some primitive type can also store an expression
>>
>> "max-threads" -> 10
>> "max-threads" -> expression ${pool.max.threads}
>>
>> The expression can be resolved at runtime; the jboss-dmr class will
>> attempt to resolve it by doing a system property lookup.
>>
>> This basic support doesn't do much for you though; it just *makes it
>> possible* to support an expression in a config attribute. It's necessary
>> but insufficient. And we haven't really done the necessary other steps
>> for many attrbutes.
>>
>> To actually make the expression useful, a subsystem would need to:
>>
>> 1) Properly parse the expression from xml. Don't barf when you see<pool
>> max-threads="${pool.max.threads}"/> because you're expecting an int.
>> 2) Similarly, don't barf if an operation request passes an expression as
>> the param value.
>> 2) Store the expression in the runtime configuration model. Don't lose
>> the fact it's an expression by resolving it and storing 10.
>> 3) Resolve the expression and validate that the resolved value is valid
>> before passing the resolved value into any runtime services. That is,
>> don't try and pass ${pool.max.threads} to your thread pool impl.
>> 4) Properly marshal the expression back to xml. Don't write<pool
>> max-threads="10"/> and lose the expression if the server is restarted.
>>
>> I wrote a class (AttributeDefinition) a month back that makes all of the
>> above much easier; it's used heavily in the messaging subsystem now.
>>
>> 5) Add metadata to the attribute's description indicating that an
>> expression is a legal value. This allows tools like the console to
>> understand that they need to account for ${pool.max.threads} instead of
>> an int in their UI.
>
> 6. Figure out how/if you can validate any of this in schema.
>
>
Sounds like a nasty task. In past discussions we'd accepted that 
documents with expressions would not be valid against the schema.

It would be fairly straightforward to create a tool that can accept a 
document with expressions along with key/value pairs for all the 
properties, parse it, resolve the expressions, emit a resolved doc and 
validate that. But I don't really see much point in that, since parsing 
it proves we can parse it.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat