2:29 a.m.
I am working in the org.hibernate.cfg.annotations.SimpleValueBinder
class. I need to be able to search for an annotation that exists either
on the property or on the entity that defines that property (or on one
of that entity's super-classes). I have no idea how to achieve this
with hibernate-commons-annotations.
As far as I can tell you need to manually get the Class reference in
order to be able to get the XClass reference? Is that correct?
Also, at what point, if any, during SimpleValueBinder processing can I
be certain that the owning entity class and its super-classes have been
processed?
--
steve(a)hibernate.org
http://hibernate.org
10:12 a.m.
On Jul 4, 2012, at 2:29 AM, Steve Ebersole wrote:
I am working in the org.hibernate.cfg.annotations.SimpleValueBinder
class. I need to be able to search for an annotation that exists either
on the property or on the entity that defines that property (or on one
of that entity's super-classes). I have no idea how to achieve this
with hibernate-commons-annotations.
As far as I can tell you need to manually get the Class reference in
order to be able to get the XClass reference? Is that correct?
If you don't have the XClass (or Class) yet you need indeed first get a Class
reference and then via the ReflectionManager (mappings#getReflectionManager())
get the XClass. Then you use the XClass api.
Also, at what point, if any, during SimpleValueBinder processing can
I
be certain that the owning entity class and its super-classes have been
processed?
I am not sure you can. I think the class is more of a container on which you set
properties and then at some stage you call #make(). Do you need to do this annotation
processing at a specific point in time?
Maybe you could do the processing in SimpleValueBinder#setType. There you are already
dealing with XProperty and there is a fair amount of annotation processing going on.
Not sure whether this is suitable in your case.
--Hardy
5:44 p.m.
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]. But as you said, setType()
gets an XProperty reference; fillSimpleValue() does not.
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.
[1] This is based on one of those non-documented assumptions that the
old o.h.mapping model makes where SimpleValue#setTypeUsingReflection is
used as the final call in attempts to set the value's typing
information. Its used as the trigger to SimpleValue that it now has
all the information it it going to get in terms of Type determination...
On Wed 04 Jul 2012 03:12:06 AM CDT, Hardy Ferentschik wrote:
On Jul 4, 2012, at 2:29 AM, Steve Ebersole wrote:
> I am working in the org.hibernate.cfg.annotations.SimpleValueBinder
> class. I need to be able to search for an annotation that exists either
> on the property or on the entity that defines that property (or on one
> of that entity's super-classes). I have no idea how to achieve this
> with hibernate-commons-annotations.
>
> As far as I can tell you need to manually get the Class reference in
> order to be able to get the XClass reference? Is that correct?
If you don't have the XClass (or Class) yet you need indeed first get a Class
reference and then via the ReflectionManager (mappings#getReflectionManager())
get the XClass. Then you use the XClass api.
> Also, at what point, if any, during SimpleValueBinder processing can I
> be certain that the owning entity class and its super-classes have been
> processed?
I am not sure you can. I think the class is more of a container on which you set
properties and then at some stage you call #make(). Do you need to do this annotation
processing at a specific point in time?
Maybe you could do the processing in SimpleValueBinder#setType. There you are already
dealing with XProperty and there is a fair amount of annotation processing going on.
Not sure whether this is suitable in your case.
--Hardy
--
steve(a)hibernate.org
http://hibernate.org
10:51 a.m.
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
9:17 p.m.
Thanks Hardy,
I think I got all that portion done.
The next part is very daunting as now I have to work with
Ejb3Configuration *and* JPAOverriddenAnnotationReader! Fun, fun.
On Thu 05 Jul 2012 03:51:28 AM CDT, Hardy Ferentschik wrote:
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 XC
lasses.
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
--
steve(a)hibernate.org
http://hibernate.org
9:19 p.m.
On Jul 5, 2012, at 9:17 PM, Steve Ebersole wrote:
I think I got all that portion done.
sweet
The next part is very daunting as now I have to work with Ejb3Configuration *and*
JPAOverriddenAnnotationReader! Fun, fun.
enjoy :-) I think I would be more scared of Ejb3Configuration :-)
4312
days inactive
4313
days old
5 comments
2 participants
participants (2)
-
Hardy Ferentschik -
Steve Ebersole