On Jul 4, 2012, at 5:44 PM, Steve Ebersole wrote:
Yes, SimpleValueBinder#setType is one of the places I was looking at.
Though it would seem to me that SimpleValueBinder#fillSimpleValue might be more
appropriate based on what I am trying to accomplish; that is the method where
SimpleValue#setTypeUsingReflection is called which is the process I am trying to
"hook into"[1].
SimpleValueBinder#fillSimpleValue is also called from within a second pass which means
that at least the first round of processing is complete. It should be safe to assume at
this point that the hierarchy was processed at this point of time.
But as you said, setType() gets an XProperty reference;
fillSimpleValue() does not.
You can always create your own XClass/Property (or keep a reference from when setType is
called)
As background, this is for the new JPA 2.1 AttributeConverter
feature. In my opinion, the best way to treat this is as a hook into this "Type
determination" process. If there is an AttributeConverter in effect for a given
attribute we will essentially create a new (Basic)Type instance for it on-the-fly.
However, AttributeConverters can come into play at many levels, which is what I am trying
to work through atm. The highest precedence is when attributes are explicitly marked with
an @Convert annotation that names the AttributeConverter class. Thats easy enough as I
have access to that (in setType at least) through the XProperty. Next in precedence is
@Convert annotations on the entity owning the attribute, or any of its mapped/entity
superclassses. Finally, we need to look at "global" AttributeConverter
definitions. Its this second level of precedence that I am concerned about specifically
because I need to know that the owner and all of its superclasses are available as
XClasses.
That's pretty much similar to the complexity you have to go through to determine the
access type for attributes (field vs property). You can have @AccessType on the attribute,
the class or superclass. And then of course you have to look at the placement of the @Id
attribute to determine the default. Anyways, similar from a processing point. What I
wanted to say was that here is one of the points where Jandex shines and where it is imo
much nicer to work with a annotation repository. It opens up other ways of writing the
code, because now I
can just ask the repository for any @Convert annotation. This circles back to our
discussion con vs pro commons annotation.
--Hardy