[wildfly-dev] Pretty-printing XML validation errors

[Aleksandar Kostadinov]

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

Offline cli is a nice improvement. The OpenShift Wildfly image might be 
configured to read cli commands from a file in the app repo to apply 
configuration before launching server.

This would not give the ability to reconfigure cluster using management 
console though. Maybe that's not important for container use cases. I 
don't know. Just would be nice somebody to figure out what an *ultimate* 
Wildfly UX in OpenShift means so that core dev team can implement 
necessary features to get there. Just retrofitting to the cloud has less 
chances to attract (I'm not saying we do that).