On Jul 20, 2016, at 5:49 PM, Aleksandar Kostadinov <akostadi@redhat.com> wrote:

Brian Stansberry wrote on 07/20/16 20:23:

On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov
<akostadi@redhat.com <mailto:akostadi@redhat.com>> wrote:

Tomaž Cerar wrote on 07/20/16 16:38:
Most of my concerns about this ware already raised by Brian (l18n, extra
size of distro, inconsistencies between subsystems, ...)

Also on top of this, having something like that would glorify
configuration of server via XML,
which is something we are trying to discourage  in favor of CLI /
mgmt api.

Excuse my ignorance if this is already taken care of. But last time I
looked, using whatever management API was not very nice for container
runtime. i.e. configuration changed through API was not persisted.
I am wondering if this is already fixed somehow or is at least somebody
considering it as an important use case (I think it should).

Persisting server configuration changes made via the supported
management APIs back to the config file has been done in AS 7.0 and
later. Its a fundamental requirement.

I should have explained better. The config is saved on container. But container being stateless loses changes on restart. At least for OpenShift v2 that has been an issue.


Thanks; I figured I was missing something. :)

Shame on me I didn't look at OpenShift v3 integration. I'm not sure how it is handled there. Perhaps I should have done my homework before hijacking the thread. Sorry about that. Hopefully I can check wildfly on v3 next week.

Jason has already replied with what I was going to say about ways to prepare the config other than editing xml. I’ll just follow up a bit on what he said by mentioning that I presented at a meeting of the folks who prepare middleware images for use on OpenShift and showed them the offline CLI, which they were interested in since it eases scripting of configuration. I don’t know how much it’s been adapted since then though.

I recognize that end users are going to want to edit xml, and that’s fine, people can use techniques that best fit their preferences. I think it’s mistaken though for *tools* to be based on manipulating our xml configs. We work hard to ensure long term compatibility in our management APIs, but we have no such guarantees about our xml formats. We encourage normal users to prefer our management APIs over xml for the same reason, but an individual having to check the xsd again if our format changes is a smaller problem than a tool having to be rewritten.

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat