2:55 p.m.
On Jul 20, 2016, at 5:49 PM, Aleksandar Kostadinov
<akostadi(a)redhat.com> wrote:
Brian Stansberry wrote on 07/20/16 20:23:
>
>> On Jul 20, 2016, at 8:59 AM, Aleksandar Kostadinov
>> <akostadi(a)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