On 7/4/14, 5:51 AM, Darran Lofthouse wrote:
On 03/07/14 17:24, Stuart Douglas wrote:
> - The ability to customise the default config (not sure how this will
> work yet. A yuck solution would be xslt, but no one likes that. A nicer
> solution could be some kind of CLI script that is run on first boot).
I think we should avoid XML manipulation as much as we can, really it is
just our chosen approach to persist the servers config - there is
nothing to stop us from changing to something different so persistence
format could even become something selected when creating a distribution.
CLI commands could be very nice, the tool could even run the server in
admin mode to execute them and there have been various discussions on
running the server in the CLI or the CLI in the server.
Could this also be a time to consider all configuration for the server
starting from CLI commands? I believe our current approach is an
evolution from where we used to just have fully defined configurations
in the codebase, assembling XML fragments enabled re-use. But now that
tooling to create a distribution is being considered again maybe 100% if
the configuration could come from defined management ops.
I like the idea of that a lot, but I'm concerned about it becoming a
blocking priority. How adaptable is the stuff we already have for
building configs for this usage, at least as a temporary solution? It
has some of the basic elements, i.e. chunks of config associated with a
name (one that often smells like a capability name) that get included if
relevant.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat