> Similarly, runtime on-demand validation cannot report element
> names and so on. We modified the RI so that in the next release
> the error message will have some indication of element/attribute
> names, but it's just meant to be a part of error messages. If
> you search the archive, you will find details of this issue.
It's good news that the next RI release will support this.
> I'm curious, what's the use cases behind the element names.
> Suppose you can get the name of the element which is closest
> to the error, what are you planning to do with it?
As the poster of the original message requesting this feature,
I thought I'd explain my use-case scenario and why I'd like
the ability to know this.
I am involved in a large project where several disparate systems
communicate with each other using XML. The XML is very tightly
specified, and different development teams from different
companies write different pieces of the overall project code.
Upon receiving a piece of the XML each component within the
system needs to validate it against the spec. In the past
this has all been coded manually, but now I'm hoping that JAXB
can remove a lot of this burden.
When a piece of XML fails validation, we generate an error
report for the appropriate support person to investigate.
With the present functionality we can only tell them that
something is wrong with the XML (this could be one element in
an XML file that's several megabytes) which means that either
it's a manual task for someone, or else we'll have to write
another tool to just perform validation, which reduces the
benefit of JAXB.
Therefore the more information that can be gained from a
validation error the better.
In my case, it's even worse because I can't allow the
unmarshaller to do validation due to the "trimmed string"
problem I posted excessively about previously - therefore
I can't even determine the line number that caused the error.
Marcus