[hibernate-dev] Hibernate.getImplementation(Object)

[Emmanuel Bernard]

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 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 breaks field access....what does the  
> JPA spec actually mandates ?
> What if the field is a public one ? That would break users logic too.
>
>> ClassMetadata is very invasive in my code, I'd rather avoid that  
>> solution, most of my code is JPA compliant today.
>
> Ok.
>
>> I'll stay with the HibernateProxy casting.
>
> Sounds like the best plan.
>
> /max
>
>> On 24 mai 07, at 10:57, Max Rydahl Andersen wrote:
>>
>>>
>>>> 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.getPropertyValue(x, "propertyName") would give you  
>>> the value (at least after
>>> initialize(x) have been called)
>>>
>>> No reason for magical impl detail api afaik.
>>>
>>> /max
>>>
>>>> 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 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 misunderstand what you want it to return ?
>>>>>
>>>>> /max
>>>>>
>>>>>> 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 for a facilitator.
>>>>>> Currently my code is fairly weak, since Steve can refactor  
>>>>>> anytime  LazyInitializer using an AST parser and a maven POM  
>>>>>> approach, because... you know ;-)
>>>>>> I'm fine is we consider HibernateProxy and LazyInitializer as  
>>>>>> public APIs but it's not the case today, or at least I'm fine  
>>>>>> if we define an extended contract between Search and Core so  
>>>>>> that it won't break between micro versions.
>>>>>>
>>>>>> On 23 mai 07, at 19:24, Max Rydahl Andersen wrote:
>>>>>>
>>>>>>> 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 field access.
>>>>>>>> When I access a previously uninitialized object, and even if  
>>>>>>>> I initialize it (Hibernate.initialize()).
>>>>>>>>
>>>>>>>> The field access End up returning null all the time because  
>>>>>>>> of the way lazy loading is done. I worked around that using  
>>>>>>>> some of the code from Hibernate.initialize()
>>>>>>>>
>>>>>>>> 		if ( value instanceof HibernateProxy ) {
>>>>>>>> 			value = ( ( HibernateProxy )  
>>>>>>>> value ).getHibernateLazyInitializer()
>>>>>>>> 					.getImplementation();
>>>>>>>> 		}
>>>>>>>>
>>>>>>>> But it seems it really should be part of the Hibernate class  
>>>>>>>> contract.
>>>>>>>>
>>>>>>>> I could use
>>>>>>>>
>>>>>>>> 		Hibernate.initialize(value);
>>>>>>>> 		value = session.get( Hibernate.getClass(value),  
>>>>>>>> session.getIdentifier(value) );
>>>>>>>>
>>>>>>>> but at the present time, it's hard for me to access the  
>>>>>>>> session, and conceptually speaking there is no real need for  
>>>>>>>> it.
>>>>>>>>
>>>>>>>> How about exposing this service in Hibernate class either
>>>>>>>>
>>>>>>>> 		value = Hibernate.initialize(value); //changing the return  
>>>>>>>> value
>>>>>>>> or
>>>>>>>> 		value = Hibernate.getImplementation(value);
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----
>>>>>>> Max Rydahl Andersen
>>>>>>> callto://max.rydahl.andersen
>>>>>>>
>>>>>>> Hibernate
>>>>>>> max at hibernate.org
>>>>>>> http://hibernate.org
>>>>>>>
>>>>>>> JBoss a division of Red Hat
>>>>>>> max.andersen at jboss.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----
>>>>> Max Rydahl Andersen
>>>>> callto://max.rydahl.andersen
>>>>>
>>>>> Hibernate
>>>>> max at hibernate.org
>>>>> http://hibernate.org
>>>>>
>>>>> JBoss a division of Red Hat
>>>>> max.andersen at jboss.com
>>>>
>>>
>>>
>>>
>>> ----
>>> Max Rydahl Andersen
>>> callto://max.rydahl.andersen
>>>
>>> Hibernate
>>> max at hibernate.org
>>> http://hibernate.org
>>>
>>> JBoss a division of Red Hat
>>> max.andersen at jboss.com
>>
>
>
>
> -- 
> --
> Max Rydahl Andersen
> callto://max.rydahl.andersen
>
> Hibernate
> max at hibernate.org
> http://hibernate.org
>
> JBoss a division of Red Hat
> max.andersen at jboss.com