Configuration Errors

[dmlloyd]

I think we should start brainstorming better ways to handle and present configuration errors in the various .xml descriptors that we have.

In other words, it should be possible (somehow) for my service's start method to relate an error back to a specific line in a specific configuration file in a specific deployment unit, if there is such a line that relates to the error.

So if I have a service which binds an socket, and that bind fails, it should be possible for me (as the service author) to present an error message like this:

Could not bind requested address: address already in use (specified in META-INF/network-beans.xml:49 in foo-bar.jar in bla-bzzt.ear in server/default/deploy/)

This implies that every bit of metadata that I assemble should be capable of having complete location information associated with it. Even better if we came up with a format-agnostic mechanism (in other words, not specific to XML) so that deployment types whose metadata is specified via properties or something else can make use of it as well.

What do you guys think? Is this desirable as a feature? Any great ideas on how to actually do it?

[trustin]

If the configuration is not processed concurrently (is it even possible?), the easiest way to implement this feature could be using ThreadLocal.

[dmlloyd]

I don't see how that might help though - the binding occurs with JAXB so by the time a deployer gets ahold of the data, it's already in an object model, so any location info would have already been lost.

[trustin]

Ah, we are using JAXB. I thought we are something like SAX. Sorry about the noise.

Then, what about improving JBoss JAXB itself to maintain a complete map that maps an object property to the location of the XML file? For example:

Location l = map.getLocation(object, "bindAddress");
String path = l.getPath();
int lineno = l.getLineNumber();
int column = l.getColumn();
..

This map and location information could be written generic enough so that it can be used with different configuration file formats, as long as the configuration parser (JAXB implementation in the case above) puts the appropriate information when it processes the configuration file.

I hope my idea makes sense this time. :)