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.
Here is a sample stack trace that will help you understand my problem (I'm working with a binding file where there is a typo and the attribute is spelled "valu" instead of "value"):
org.jibx.runtime.JiBXException : Expected "mapping" end tag, found "valu" end tag (line 10, col 39, in C:/jbernard/projects/test/test-jibx-plugin/src/main/resources/binding-Amazon.xml)
at org.jibx.runtime.impl.UnmarshallingContext.throwEndTagNameError (Unknown Source)
at org.jibx.runtime.impl.UnmarshallingContext.parsePastCurrentEndTag(Unknown Source)
at org.jibx.runtime.impl.UnmarshallingContext.parsePastEndTag(Unknown Source)
at org.jibx.binding.def.BindingBuilder.unmarshalMapping (BindingBuilder.java:1565)
at org.jibx.binding.def.BindingBuilder.unmarshalMappings(BindingBuilder.java:950)
at org.jibx.binding.def.BindingBuilder.unmarshalBindingDefinition(BindingBuilder.java:1735)
at org.jibx.binding.Utility.loadBinding(Utility.java:308)
at org.jibx.binding.Utility.loadFileBinding(Utility.java:388)
at org.jibx.binding.Compile.compile(Compile.java:296)
at org.kalixia.intellij.jibx.BindingCompilerCompileTask$2.compute (BindingCompilerCompileTask.java:154)
at org.kalixia.intellij.jibx.BindingCompilerCompileTask$2.compute(BindingCompilerCompileTask.java:77)
at com.intellij.openapi.application.impl.ApplicationImpl$7.run(ApplicationImpl.java :1)
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:343)
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:348)
at org.kalixia.intellij.jibx.BindingCompilerCompileTask.execute(BindingCompilerCompileTask.java:75)
at com.intellij.compiler.impl.CompileDriver.a(CompileDriver.java:763)
at com.intellij.compiler.impl.CompileDriver.a (CompileDriver.java:470)
at com.intellij.compiler.impl.CompileDriver.a(CompileDriver.java:307)
at com.intellij.compiler.impl.CompileDriver.access$400(CompileDriver.java:427)
at com.intellij.compiler.impl.CompileDriver$4$1.run (CompileDriver.java:5)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.runProcess(ProgressManagerImpl.java:49)
at com.intellij.compiler.impl.CompileDriver$4.run(CompileDriver.java:1)
I need to extract the location of the error and hoped to find it in the ValidationContext...
Regards,
Jérôme.
2005/12/9, Dennis Sosnoski <[EMAIL PROTECTED]>:
Jérôme BERNARD wrote:
>2005/11/26, Dennis Sosnoski <[EMAIL PROTECTED]>:
>
>[...]
>
>
>>The actual binding definition validation handling is built into the
>>org.jibx.binding.model.BindingElement class, in the validateBinding()
>>method. This actually prints out the errors to System.out, but the
>>methods it uses are all public and could be used directly for other
>>types of reporting.
>>
>>
>
>I'm having problems trying to hook in BindingElement.validateBinding().
>Basically the problem is BindingElement.validateBinding() calls
> BindingElement.readBinding() which throws JiBXException and do not
>"populate" the ValidationContext.
>
>Am I missing something obvious??
>
>
I suspect the part you're missing is that the binding model itself uses
JiBX data binding, so the binding needs to be compiled whenever you
regenerate the binding model classes - but you can't run the binding
compiler normally without the binding model. There's a special command
line switch that makes the binding compiler skip the binding validation
step, added to allow the binding model binding to be compiled. This is
the "-s" switch. You can look at the "compile-bind" target in the main
JiBX build.xml (in the build directory) to see this in use.
This can be a nuisance when working with an IDE, since any time you
modify one of the binding model classes you need to recompile the
binding. I use a separate build-binding.xml Ant script to handle this
from within Eclipse; that way I can just right click on the
build-binding.xml file, select Run as/Ant task, and have the binding
compiled. I'll check this file in before I send this message (I'm
composing the message on a plane, so can't do either the check in or the
send right now).
- Dennis
-------------------------------------------------------
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&opclick
_______________________________________________
jibx-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jibx-devs
