3:41 a.m.
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.
I propose a simple bit of metadata "allow-expressions" -> true|false for
this. It's one line of code to the AttributeDefinition class to add this.
More problematic, on the console side the console UI will need to
recognize expressions and deal with them. Properly display the
expression to the user, allow the user to type in a expression, provide
some UI for letting the user find out what the expression resolves to
any given server.
On 8/23/11 9:42 AM, Robb Greathouse wrote:
Hi,
We are putting JBoss 5.1.1 into the Amazon EC2 cloud. There are some peculiarities of
how EC2 wants to configure instances that we are running into.
EC2 wants to use a standard AMI - basically a standard image that anyone wanting to use
JBoss would use. They would then customize this image by passing parameters via a single
user-data file.
While the user could ssh into the instance once it is started and manually change the
settings; this is not considered user friendly.
Ideally, we would like to be able to pass any configuration variable via user-data.
These would include database settings, clustering settings, etc.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat