JPA today mandates that clients access getters and setters.
On 28 mai 07, at 05:37, Max Rydahl Andersen wrote:
Field field = myClass.getField("myField");
Object value = field.get(proxy);
value is always null because CGLIB does not fill the superclass
fields.
well - it shouldn't and you c
Field field = myClass.getField("myField");
Object value = field.get(proxy);
value is always null because CGLIB does not fill the superclass fields.
well - it shouldn't and you couldn't rely on it even if it did since it
might not be the right concrete type.
But I can see that it's kind'a
Field field = myClass.getField("myField");
Object value = field.get(proxy);
value is always null because CGLIB does not fill the superclass fields.
ClassMetadata is very invasive in my code, I'd rather avoid that
solution, most of my code is JPA compliant today.
I'll stay with the HibernateP
This is what I want to return one way or an other... or CGLIB should
fill up the superclass fields.
I don't understand ;)
The parameter to Hibernate.initialize(x) is the *entity* right, not a
*value* of that object ?
And field access etc. works on that object.
ClassMetaData.getPropertyV
This is what I want to return one way or an other... or CGLIB should
fill up the superclass fields.
On 24 mai 07, at 01:02, Max Rydahl Andersen wrote:
afaik ( ( HibernateProxy ) value ).getHibernateLazyInitializer
().getImplementation() haven't changed almost since beginning of
times.
But
afaik ( ( HibernateProxy ) value
).getHibernateLazyInitializer().getImplementation() haven't changed almost
since beginning of times.
But exposing it on the Hibernate class API would be wrong IMO since the
return value would be the underlying object instead of the proxy, or
do I misunderst
I know that Max :)
I do not expose it to the user, it's just how HSearch internally deal
with it during the transparent indexation process, so I do not break
the == operation from a user point of view. Note that we expose that
to the user anyway through load/initialize/get, I'm just begging
why are you ever in need of touching the field values directly ?
Accessing and potentially exposing the underlying object of a proxied
entity should be strictly prohibted
since otherwise you easily end up with breaking ==
/max
For Hibernate Search I came to a problem.
When a user choose fie
