Joseph Fialli wrote:
> The original intent for implClass customization was to allow an external
> tool that was not
> the JAXB implementation that generated schema derived interfaces, be able
> to generate the implementation classes. Such a tool could be a UML modeler
> that generates source code. ImplClass customization was a hook for this
> functionality alone.
>
> Given that JAXB 1.0 did not specify a portable binding framework, we knew
> that the specified implClasses could not be portable from the very
> beginning. The functionality was provided
> to meet a requirement identified by the expert group, namely, the ability
> to specify a generated implementation class not generated by the original
> JAXB implementation. Since there is no portable binding framework,
> the JAXB 1.0 specification could not real discuss how one would generate
> an implClass, this is an implementation specific detail.
I can very well see the reasons for the dependency. In fact I got it omitted
in JaxMe just by a comparatively slow mechanism basically like
if (object instanceof FooElem) {
...
} else if (object instanceof BarElem) {
...
}
which is definitely unlucky and can be solved much better by applying a
run time dependency. (In my case an abstract method returning a QName with
the element name and target namespace.)
However, IMO the run time dependency could also be resolved by a class
derived from the bean class.
> A JAXB element instance provides the functionality of statically
> associating an xml tag name with
> an instance of a JAXB content interface. (To avoid accessors that
> manipulated QNames,
> accessors for the xml tag name are not provided as public methods, they
> are only used
> by binding framework runtime.) The other optional operations on Element
> are isNil() and setNillable.
> Since all JAXB elements are of some Java datatype, it seemed sufficient
> to only allow implClass
> replacement on the Java datatypes representing XSD complex types used by
> the element instances and
> not the elements themselves. The complexity of having two kinds of
> implClasses, ones that
> replaced content interfaces and ones that replaced elements, did not
> seem worth the complexity.
I did think a lot about that in the last weeks, because I attempted this
approach with no success. (Indeed the RI is also differing from your view.)
My current conclusion is, the assumption that the element doesn't need an
implementation should be discarded. IMO one should view the complex type as
an abstract class, the abstract method being getQName(). This method is
worth for addition to the Element interface. IMO this would also allow to
relax a lot of runtime dependencies, because the return code can well be
used as a key for a (run time dependent) Map with additional information.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net