Hi.
>> I would suggest that annotations are parsed into DOM nodes,
>> class instantiation is a bit of overkill.
>
> OK. That's good to know. That's even easier.
In any case, if add-on prefers object structures, it is free to
unmarshall DOM of the annotation.
>> jaxb:property and jaxb:class solve the same problem for JAXB, don't
>> they? The same approach could be used for custom annotations.
>
> Because JAXB annotations are processed by the front-end, technically
> they aren't propagated to the backend. In that sense it's not exactly
> "the same".
I meant the concept used to distinguish between ClassItem and FieldItem.
> I guess one simple approach would be for the JAXB RI to designate one
> schema component for a class and one schema component for a property.
Exactly.
> Then it can provide access to annotations on those components. Hopefully
> having something would make it easy for us to talk about it.
I can't wait to migrate
<xsd:attribute name="id" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<jaxb:property>
<jaxb:javadoc>
@hyperjaxb.hibernate.id unsaved-value="null"
generator-class="uuid.hex"
</jaxb:javadoc>
</jaxb:property>
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
into something like
<xsd:attribute name="id" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<jaxb:propertyAnnotation>
<hj:id unsaved-value="null" generator-class="uuid.hex"/>
</jaxb:propertyAnnotation>
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
and use DOM interfaces instead of XDocletsa/qDox solution.
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