Thomas Jones-Low wrote:
Dennis Sosnoski wrote:
The class attribute is only used with a <mapping> element. The current code doesn't check for unknown attributes, so it won't complain if you add in something that's not relevant. That's the case for your class attribute on the <structure> element. If you remove this attribute everything should work the same.
You are correct. It works without the class="Address" element. Which implies JiBX is smart enough to decipher the class of the field element, and instantiate it correctly. But if the Address class requires special processing, it won't work correctly.
I'm not sure what you mean by this, unless you're referring to cases where the type of the field doesn't match the type of the object actually referred (a java.lang.Object field that you know always references an Address object, for instance). If that's the case, you can use the type="" attribute to override the static type of the field.
... This approach should work if you structure the binding properly, which would be:
<structure field="primary" map-as="Address"/> <collection field="secondary" usage="optional"> <structure name="secondary" using="ADDRESS"/> </collection>
Nope, this fails with during the compile with:
[java] org.jibx.runtime.JiBXException: Reference to structure ADDRESS has object of type java.lang.Object rather than required Address [java] at org.jibx.binding.def.StructureReference.setLinkages(StructureReference.java:120)
Whoops, my miss. You'll also need an item-type="" on the <collection> or a type="" on the <structure> to say that you're working with an Address - I think either one should work. At least the exception message here tells you what's wrong, though now that I think about it reporting these types of errors with an exception (rather than a simple error message) is kind of overkill - it's probably more intimidating for new users when they see an exception.
As for the "correct" way, JiBX actually gives you multiple alternatives in most cases. The binding further up is fine; I think you should also be able to define the Address class with a <mapping abstract="true"...> which doesn't specify a name, then fill in the name on the references to it:
<structure field="primary" name="primary" map-as="Address"/> <collection field="secondary" usage="optional"> <structure name="secondary" map-as="Address"/> </collection>
This also fails during the bind with the following error:
[java] org.jibx.runtime.JiBXException: Name not allowed when using mapping reference at tag "structure"(line 4, col 35, in bind.xml)
[java] at org.jibx.runtime.impl.UnmarshallingContext.throwStartTagException(UnmarshallingContext.java:2725)
Yes, looking at the code I still have an overly-strict check in place for this case - it really should only treat this as an error when you use an abstract mapping that defines a name. You should be able to get around this by using a <structure> wrapper to add the name, but I won't confuse the issue with more suggestions.
What all this brings out is the whole reason I'm restructuring before an official production release. I think the current beta 3c codebase is stable enough for use in production, but there are too many quirks in the binding compile that catch even me at times (though I find this happening much more often when I'm responding to emails than when I'm writing my own bindings - it's a little more difficult to keep track of what's going on in an email).
- Dennis
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
jibx-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jibx-users
