Hi Jérôme,,
I saw this was trapped awaiting administrator approval and set it free
(the size limit for the list had been exceeded by this message; I've now
increased the size limit from 20KB to 50KB).
Here are some examples of errors which would fail only on the second
validation check:
* Bound classes which are not in the classpath
* pre-get/pre-set/post-set/factory method which don't exist
* Fields that don't exist
* Value with get-method but no field or set-method
Basically, anything that's a usage error rather than a structural error
in the XML.
- Dennis
Jérôme BERNARD wrote:
Okay, I'm able to parse successfully the exception and extract the
location of the error.
In order to test, can you give me an exemple of an error which would
fail only on the second validation check (the one with the
ValidationContext), so that my code would be able to deal with errors
in both validation levels.
Regards,
Jérôme.
2005/12/13, Dennis Sosnoski <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
Ah. There are actually two levels of validation being done. The
first is
during the actual unmarshalling of the binding definition, where
you're
missing a required element or have an unknown one present. Structural
errors of this type are handled by the basic unmarshalling code, which
doesn't have much in the way of hooks to support extracting
information.
The validation that uses the ValidationContext is a much more detailed
check of the binding definition - but you never get to that point
if you
have a structural error during unmarshalling.
I'll look into changing this in 1.1 so that you at least get the
position information for the error in some easy way. For right now
the
best you can do is to parse it out of the JiBXException error message
(ugly, but shouldn't be too difficult). In 2.0 I'm hoping to use a
more
flexible approach for unmarshalling which will allow continuing on
after
an error.
- Dennis
Jérôme BERNARD wrote:
> I'm getting more and more confused...
>
> What I'm doing is calling the BindingElement.validateBinding()
method
> and do expect to have a JiBXException (I'm testing the case when
there
> is an error in the binding file). I'm doing this before running the
> Compile task so that I can have precise reporting of where the
binding
> is wrong.
>
> I do have a JiBXException thrown but the ValidationContext do
not have
> any problem!
> So it's kind of like I'm being said "eh! there's an error, but I
won't
> tell you which one!" :-)
>
> What is even "funnier" is that the ouput of the stacktrace give
me a
> nice error message and describes the location of the error. It sound
> like if there is a JiBXException thrown somewhere, the
> ValidationContext is not filled properly before throwing the
exception
> upper in the stack of code.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
jibx-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
