Robert Greene wrote:
> Hi All.
Robert,
Thank you for your input on JAXB. I have worked on the specification
and will answer your questions as they relate to the specification.
>
> Another point regarding use with existing UML models and their generated
> classes.
>
> It seems that JAXB forces the implementation classes into a package that
> gets the suffix /impl added to it..... forcing the package name to
> include impl.
The specification specifies the a Java interface is generated to represent
XML Schema complex type. It is implementation specific, thus an artifact
of the JAXB Reference Implemenetation, what the name of the
"implementation class" of a schema derived interface is. In fact,
a portable JAXB application should never even explicitly reference
the generated implementation classes. The JAXB API allows users to
just manipulate instances of the interfaces, w/o knowing their JAXB
implementation specific "implementation class names".
> Even if we solve the existing problem ( previous e-mail
> on Complex types ) that forces a predetermined inheritance model, the
> implementation classes are the ones that need to conform to the existing
> code.
The problems you are running up against are because you are
attempting to use JAXB in a manner that it was not specified
to support in v1.0. It was considered out of scope for JAXB v1.0
to support binding
existing JavaBean classes to XML Schema complex types. This
is explicitly stated in the Section 1.3, "Non-Goals" of the
specification. Thus, you are correct in identifying that the
specification does not make it easy to accomplish what you
are trying to do, namely bind existing JavaBean classes to
an exising XML Schema.
This capability will be investigated for a future release, but
it is not a primary use case for the current release. V1.0 release
assumes a use case where one has one or more XML Schemas and one wants to
access XML content constrained by these schemas from schema-derived
Java representations.
-Joe Fialli, Sun Microsystems
> If you want separate packages between the interfaces and the
> implementation classes so you can avoid name collisions or for some
> other reason, you should place the interface classes in a seperate
> package and let the implementation classes conform to the complete
> mapping you are allowed to specify in the binding annotations.
>
> It does not make much sense to allow a package specification in the
> binding annotations which is not the resulting package of the
> implementation classes.
>
> Has anyone worked around this issue? Any idea if this is going to be
> changed in the final release?
>
> Thanks,
> -Robert
>
> --
> Robert Charles Greene
> Versant Corporation
> Director, Systems Engineering
> Office: (510) 789-1627
> Cell: (510) 207-5783
--