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