users@jaxb.java.net

Re: Use of jaxb:class/_at_implClass

From: Joseph Fialli <joseph.fialli_at_sun.com>
Date: Thu, 18 Sep 2003 11:19:12 -0400

Kohsuke Kawaguchi wrote:

>>Hi, Kohsuke,
>>
>>sorry for replying late. First of all, thanks for your answers, but I must
>>admit, that I still cannot follow:
>>
>>Kohsuke Kawaguchi wrote:
>>
>>
>>
>>>So the compiler is trying to create the following relationship
>>>
>>> MyClassImpl -> (your) SomeClass -> SomeClass (which is usually
>>> generated as MyClassTypeImpl but you changed i by class/_at_name.)
>>>
>>>
>>Sorry for not working this out myself. May I still ask for the general idea,
>>though? Assuming that my SomeClass is indeed generated by some external
>>tool, it is unlikely that I can make it derive from a class generated by JAXB.
>>
>>
>
>Good point. You are right. I personally agree that there's a portability
>issue around implClass.
>
>Either you have to implement your class from scratch (which is
>impossible to do unless you tie your code to a particular JAXB
>implementation).
>

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.

> or you have to extend your class from the generated
>one (which is also impossible to do unless you tie your code to ... )
>
>
>
The practice of extending the schema-derived implementation class with a
specified implClass that added application
specific methods is a workaround for the fact that the JAXB 1.0 spec did
not provide a
way to accomplish this. JAXB 2.0 will provide a way to introduce
application behavior
methods that will supercede the implClass workaround for injecting
object methods into
schema derived JAXB instances.

>
>
>
>>>If you want to change the implClass of element, attach your annotation
>>>to the element.
>>>
>>>
>>Quoting 6.7.3.4:
>>
>> A <class> declaration is allowed in the annotation element of the
>> global element declaration. However, the implClass attribute is
>> not allowed.
>>
>>My interpretation is that attaching the annotation to the element is
>>forbidden. Not that I understand why ... but perhaps you are saying me that
>>this works anyways? :-)
>>
>>
>
>Ahhh, you are right. Hmm. I'll ask the spec team to answer your question.
>
>
>
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.

-Joe

>
>regards,
>--
>Kohsuke Kawaguchi
>Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net