after quite a bit of rewarding (since i found the problem -- it would
have been an effort for me to convince myself that it was "at least a
valuable learning experience" if i hadn't -- i'm terribly immature
about things like that), i've found that the reason my valid objects
were getting invalid validation results is because the constructor for
ValidatorImpl doesn't call
DatatypeConverter.setDatatypeConverter(
com.sun.xml.bind.DatatypeConverterImpl )
as do the (Un)MarshallerImpl classes.
from the javadoc, it appears that the spec doesn't require that
providers initialize the system before the first validation -- only
before the first (un)marshalling. for that reason, i'm not sure if i'm
making a feature request for the upcoming 2.0 version's spec, or if i
should file a bug about this current ri's behavior. in any event, i'm
rolling with a customized runtime right now, in which the ValidatorImpl
constructor behaves much like those of MarshallerImpl and
UnmarshallerImpl.
is there any interest in making this a part of the standard way things
work? if there's a need for a use case, here it is (and the reason i
ended up finding all of this out): i have a swing app which my users
use to fill in various values. unbeknownst to them, the values are
actually turned into a jaxb object. when they hit save, they're
marshalling, but i want to validate first, or course. thus, i'm
creating jaxb objects from scratch, and calling validate before ever
trying to marshal or unmarshal.
interestingly enough, this problem was hidden for so long because i'd
been in the habit of marshalling the objects to my logger, just to
eyeball them, before ever calling validation. once i removed the log
statements -- poof! -- no more (NullPointerException-free) validation.
jon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net