Hi Lexi,
Thanks very much for the quick response. Do you know what that flag actually
does? Looking at the code for the episode plugin, that flag is always set.
Is how it works documented anywhere? Additionally, if that flag really
causes the behaviour you describe, why does the second example in my issue
work when core is still imported and used extensively?
I actually just tried my example that's currently failing in two branches of
our project. The code was branched very recently, and all code related to
JAXB is identical. The code works in one and fails in the other - both with
the same episode files. Essentially we've found this problem to simply be
extremely sensitive - changing some random apparently unrelated thing causes
it to work or break.
Any more ideas as to what might be happening or what I might be able to do
to work around it?
Thanks again,
Colin
2008/6/6 Aleksei Valikov <valikov_at_gmx.net>:
> Hi.
>
> > 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,
>
> Your sample starts working if I remove <schemaBindings map="false"/>
> from the core.episode file.
> I believe that if the namespace is not mapped, simple type
> customizations are not processed therefore XJC complains about
> javaType.
> Hope this helps.
>
> Bye.
> /lexi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>