[jboss-as7-dev] Passing Cloud Configuration.

[Jason T. Greene]

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.


-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat