[hibernate-dev] hiberate-commons-annotations and locating annotations

Emmanuel Bernard emmanuel at hibernate.org
Fri Aug 30 10:06:33 EDT 2013


Yes I get that but JPAOverriddenAnnotationReader is only about reading
the XML and converting it into annotations.

I understand that implementing the rules based on the annotations is
more complex than annotation override.

On Fri 2013-08-30  8:44, Steve Ebersole wrote:
> Its not that easy.  This is not as simple as AttributeOverride.  The
> rules here are much more complex (or convoluted, depending on your
> perspective).  An AttributeOverride always overrides.  The is just
> not the case here with converters.  Plus how AttributeOverride works
> does not need to vary from one use case to another (basics,
> composites, plurals).
> 
> 
> On Fri 30 Aug 2013 07:47:36 AM CDT, Emmanuel Bernard wrote:
> >On Fri 2013-08-30  6:27, Steve Ebersole wrote:
> >>
> >>On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
> >>>>
> >>>>
> >>>>2) The 'declaringClassName' passed in to SimpleValueBinder#setType
> >>>>is Sub. So maybe we can leverage that. But
> >>>>org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
> >>>>(the main caller of this method) has explicit handle for null-ness
> >>>>so that makes me nervous.
> >>>>
> >>>>Given the differing rules for resolving converter to use for basic
> >>>>types, collections and composites and the fact that these
> >>>>distinctions are already handled in the PropertyHolder hierarchy, I
> >>>>think it would be better to handle those distinctions there. Either
> >>>>adding a separate method to inject the converter to use (making sure
> >>>>it is called before setType, ugh) or changing the signature of
> >>>>setType to accept the converter to use.
> >>>>PropertyBinder#makePropertyAndValue would then use
> >>>>PropertyHolder#resolveAttributeConverter to pass what it needs to
> >>>>pass.
> >>>>
> >>>>WDYT?
> >>>
> >>>
> >>>Yes that makes sense to consolidate this logic in PropertyHolder. But I
> >>>have to admit I failed to find an elegant algorithm and data structure
> >>>to resolve the convert use cases you have described. All involved some
> >>>back reading of annotations etc :(
> >>
> >>Depends what you mean "back-reading".  I planned on sifting through
> >>the annotations as "resolve" is called.
> >>
> >>>
> >>>BTW is it possible to have the illegal case by mean of mixing XML and
> >>>annotation. ie you have the @Convert on the property and the disable
> >>>facility at the class level in XML. Does the same rule apply?
> >>>Because for sure the XML and the annotation are treated equally by
> >>>commons annotation.
> >><quote>
> >>The convert subelement is additive to any Convert or Converts
> >>annotations on the entity. It
> >>overrides any Convert annotation for the same attribute name. If a
> >>convert subelement is present,
> >>and attributes or subelements of that convert subelement are not
> >>explicitly specified, their default
> >>values are applied
> >></quote>
> >>
> >>My reading of that on your use-case is that we really should apply
> >>the XML-defined converter.  But hiberate-commons-annotations simply
> >>does not give us the information needed to be able to do that
> >>properly.
> >
> >You can do that, you would code the logic in JPAOverriddenAnnotationReader in ORM Core.
> >Check getAttributeOverrides / mergeAttributeOverrides as an example of
> >how to read Java annotation, the XML "annotations" and merge the two as
> >you please.


More information about the hibernate-dev mailing list