[wildfly-dev] Pretty-printing XML validation errors

[Tomaž Cerar]

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.
Another problem is also that it relies on XSD which are not always 100%
correct, which should be fixed (but that is another problem)

There are also ideas about implementing non xml backend for storage of our
configuration.
type of storage for the backend shouldn't really matter as users should be
interacting via API / CLI not by manually modifying the file.

--
tomaz


On Wed, Jul 20, 2016 at 1:28 AM, Toby Crawley <tcrawley at redhat.com> wrote:

> On Tue, Jul 19, 2016 at 4:07 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
> > Comments in-line, except for something I just thought of.
> >
> > All exception and log messages produced will likely need to follow
> > WildFly’s/EAP's i18n standards. Message prefixed with a code, text
> produced
> > in a way in an i18n manner with a reasonable way to get localized text
> into
> > the software.
>
> Ah, good point. It shouldn't be difficult to add localized text to the
> output, the biggest cost there would be the time to translate the
> messages, but I'm not familiar with how i18n is done in our projects.
> For the message code, we could print the original exception message at
> the bottom or top of the validation block. That would then use the
> same code as we provide now, and would provide the same message we use
> now with every error. Would that satisfy the message code requirement?
>
> >>
> >> On Jul 19, 2016, at 2:38 PM, Toby Crawley <tcrawley at redhat.com> wrote:
> >>
> >>> On Tue, Jul 19, 2016 at 3:15 PM, Brian Stansberry
> >>> <brian.stansberry at redhat.com> wrote:
> >>>
> >>> The only big concern I have about this is that we’ll get this behavior
> for
> >>> some failures but not all. And I don’t want to go down the path of
> trying to
> >>> force every parser to work in a manner such that we consistently get
> this.
> >>>
> >>
> >> I haven't looked at it too deeply, but it may be straightforward to
> >> alter staxmapper to allow providing an exception generator that would
> >> allow catching more of the cases that the parsers miss.
> >>
> >
> > I’m not sure how big of a problem staxmapper-thrown exceptions are. (I
> > haven’t really thought.)
>
> That's just the first place I saw errors from outside of ParseUtils,
> but I haven't yet started playing with attribute values.
>
> >
> > What I was thinking more about when I wrote my previous post was parsers
> not
> > using ParseUtils, or sometimes not using it.
> >
> > Also, a lot of XmlStreamException cases are generated from
> implementations
> > of org.jboss.as.controller.AttributeDefinition, e.g.
> >
> >
> https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/SimpleAttributeDefinition.java#L140
> >
> > Parsers are encouraged to invoke methods on AttributeDefinition to
> validate
> > attribute values. Perhaps though those are better left alone, as the
> > validators are meant to produce useful exception messages.
> >
>
> If we let these fall back to just pointing out the error location with
> the original message, this may be ok (assuming by "the alidators are
> meant to produce useful exception messages" you mean the messages
> produced by the AttributeDefinitions).
>
> <snip>
>
> >>> A minor concern is how big the added dependencies are. (I don’t know.)
> We
> >>> want to keep WildFly Core small in footprint.
> >>>
> >>
> >> Right now, the only dependencies vdx (31k) has are commons-lang (which
> >> is already a module in WildFly, but not core-feature-pack),
> >> xmlschema-walker (100k), and xmlschema-core (168k). For the rest of
> >> the work, I don't currently see needing any more dependencies.
> >>
> >
> > Thanks. So about 583K including 284K for commons-lang. The current
> > wildly-core-dist-3.0.0.Alpha3.zip is about 16.9MB, so this is fairly
> > substantial.
> >
>
> I'm only using commons-lang for a Levenshtein distance implementation
> - that could certainly be pulled in, and we could drop the 284k for
> commons-lang. It certainly would be nice to keep core under 17MB
> though.
>
> - Toby
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160720/2cba7c2d/attachment.html