<div dir="ltr"><div><div><div><div><div>Most of my concerns about this ware already raised by Brian (l18n, extra size of distro, inconsistencies between subsystems, ...)<br></div><br>Also on top of this, having something like that would glorify configuration of server via XML, <br>which is something we are trying to discourage in favor of CLI / mgmt api.<br></div>Another problem is also that it relies on XSD which are not always 100% correct, which should be fixed (but that is another problem)<br><br></div>There are also ideas about implementing non xml backend for storage of our configuration. <br></div><div>type of storage for the backend shouldn't really matter as users should be interacting via API / CLI not by manually modifying the file.<br><br>--<br></div><div>tomaz<br></div></div><div><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 20, 2016 at 1:28 AM, Toby Crawley <span dir="ltr"><<a href="mailto:tcrawley@redhat.com" target="_blank">tcrawley@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry<br>
<<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br>
> Comments in-line, except for something I just thought of.<br>
><br>
> All exception and log messages produced will likely need to follow<br>
> WildFly’s/EAP's i18n standards. Message prefixed with a code, text produced<br>
> in a way in an i18n manner with a reasonable way to get localized text into<br>
> the software.<br>
<br>
</span>Ah, good point. It shouldn't be difficult to add localized text to the<br>
output, the biggest cost there would be the time to translate the<br>
messages, but I'm not familiar with how i18n is done in our projects.<br>
For the message code, we could print the original exception message at<br>
the bottom or top of the validation block. That would then use the<br>
same code as we provide now, and would provide the same message we use<br>
now with every error. Would that satisfy the message code requirement?<br>
<span class=""><br>
>><br>
>> On Jul 19, 2016, at 2:38 PM, Toby Crawley <<a href="mailto:tcrawley@redhat.com">tcrawley@redhat.com</a>> wrote:<br>
>><br>
>>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry<br>
>>> <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br>
>>><br>
>>> The only big concern I have about this is that we’ll get this behavior for<br>
>>> some failures but not all. And I don’t want to go down the path of trying to<br>
>>> force every parser to work in a manner such that we consistently get this.<br>
>>><br>
>><br>
>> I haven't looked at it too deeply, but it may be straightforward to<br>
>> alter staxmapper to allow providing an exception generator that would<br>
>> allow catching more of the cases that the parsers miss.<br>
>><br>
><br>
> I’m not sure how big of a problem staxmapper-thrown exceptions are. (I<br>
> haven’t really thought.)<br>
<br>
</span>That's just the first place I saw errors from outside of ParseUtils,<br>
but I haven't yet started playing with attribute values.<br>
<span class=""><br>
><br>
> What I was thinking more about when I wrote my previous post was parsers not<br>
> using ParseUtils, or sometimes not using it.<br>
><br>
> Also, a lot of XmlStreamException cases are generated from implementations<br>
> of org.jboss.as.controller.AttributeDefinition, e.g.<br>
><br>
> <a href="https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140" rel="noreferrer" target="_blank">https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140</a><br>
><br>
> Parsers are encouraged to invoke methods on AttributeDefinition to validate<br>
> attribute values. Perhaps though those are better left alone, as the<br>
> validators are meant to produce useful exception messages.<br>
><br>
<br>
</span>If we let these fall back to just pointing out the error location with<br>
the original message, this may be ok (assuming by "the alidators are<br>
meant to produce useful exception messages" you mean the messages<br>
produced by the AttributeDefinitions).<br>
<br>
<snip><br>
<span class=""><br>
>>> A minor concern is how big the added dependencies are. (I don’t know.) We<br>
>>> want to keep WildFly Core small in footprint.<br>
>>><br>
>><br>
>> Right now, the only dependencies vdx (31k) has are commons-lang (which<br>
>> is already a module in WildFly, but not core-feature-pack),<br>
>> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of<br>
>> the work, I don't currently see needing any more dependencies.<br>
>><br>
><br>
> Thanks. So about 583K including 284K for commons-lang. The current<br>
> wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly<br>
> substantial.<br>
><br>
<br>
</span>I'm only using commons-lang for a Levenshtein distance implementation<br>
- that could certainly be pulled in, and we could drop the 284k for<br>
commons-lang. It certainly would be nice to keep core under 17MB<br>
though.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Toby<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></div></div></blockquote></div><br></div>