It has to do with the xml parser that xmlbeans uses. My recollections
from the xmlbeans lists is that while it may be possible to configure
xmlbeans v1 with a line-number-aware parser, v2 includes one by
default. I believe the only thing needed for moving to v2 is modifying
the maven xmlbeans plugin to work with some slightly changed "control"
classes.
david jencks
On Nov 18, 2004, at 4:07 PM, Jeremy Boynes wrote:
[EMAIL PROTECTED] wrote:
I tried deploying a JMS resource plan and got an error. The amount
of error output produced seems excessive. It looks like the plan was
output to the terminal three times in the error information.
Is it necessary to output so much information, including a stack
trace? I would have expected just a few lines of error output that
hopefully points to the offending line of the plan. Would it be
feasible to have a deploter option that could turn on more detailed
debugging information, that is off by default?
Some users may be using a terminal with a limited scroll buffer and
may lose part of the output.
I have included the command and output I received below..
<deleted as it is, well, excessive :-) >
It looks like the multiple copies come from the unwinding of the
nested exceptions - it looks like XMLBeans is including the document
in the root cause's message and it is getting propagated up.
Given that validation errors are likely to be commonplace, I'm curious
to know if there is a way of capturing more detailed information as
the document is being parsed, including the location of the offending
text. If we can capture that we can return that as a special sub-class
of DeploymentException that would allow a tool to produce more
meaningful error messages.
Does anyone know if XMLBeans can do this?
--
Jeremy
