Hi all,
I've had a problem reported in the JAXB issue tracker (
https://jaxb.dev.java.net/issues/show_bug.cgi?id=484) for a while now, but
in desperation I'm posting here as well. I finally managed to isolate a test
case, see the files in the tar attached to the issue. The problem is the
javaType customisation on core:ID (in core.xsd).
We have a large project where the data layer is almost totally based on
JAXB. We have multiple levels of schemas, and use xs:import and extensions
heavily. Occasionally we have a problem where JAXB will refuse to run,
saying that it cannot honour a customisation, usually from a base schema
when compiling a sub-schema.
To reproduce:
xjc.sh core.xsd -d output -p
generated.core.com.mycorp.model.common.datatypes
This compiles just the base schema, and works correctly.
xjc.sh core.xsd card.xsd -extension -b core.episode -d output -p
generated.card.com.mycorp.model.common.datatypes
This demonstrates the base file being imported with the corresponding
episode. This also works.
xjc.sh core.xsd iso8583.xsd testcase.xsd -extension -b core.episode -b
iso8583.episode -d output -p
generated.testcase.com.mycorp.model.common.datatypes
This case should be identical to the above, but breaks with the error below:
[ERROR] compiler was unable to honor this javaType customization. It is
attached to a wrong place, or its inconsistent with other bindings.
line 66 of file:/Users/colin/dev/platform/common/testcase/core.xsd
[ERROR] (the above customization is attached to the following location in
the schema)
line 61 of file:/Users/colin/dev/platform/common/testcase/core.xsd
So the same file (core.xsd) works in some situations, but not in others.
This is what we've seen - very minor (apparently trivial) changes can break
our compilation, usually at the worst moments, of course. It normally
happens with imports, but not always. We're doing some fairly funky stuff
with JAXB - we call it directly from Java and use plugins heavily - and this
seems to break more frequently than the command line tool, but the above
example breaks consistently with 2.1.5, 2.1.6 and 2.1.7 on the command line.
This happens to us very frequently, but is very difficult to reproduce, and
is becoming a show-stopping bug - we'll have to look at implementing our own
mapping layer shortly unless we can solve this. Has anyone seen anything
like this? I'd love to be shown to be doing something stupid at this
point...
Thanks for any help,
Colin