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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate max(a)hibernate.org http://hibernate.org JBoss a division of Red Hat max.andersen(a)jboss.com

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> ---- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> max(a)hibernate.org >> http://hibernate.org >> >> JBoss a division of Red Hat >> max.andersen(a)jboss.com > -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate max(a)hibernate.org http://hibernate.org JBoss a division of Red Hat max.andersen(a)jboss.com

> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >>>> >>>> ---- >>>> Max Rydahl Andersen >>>> callto://max.rydahl.andersen >>>> >>>> Hibernate >>>> max(a)hibernate.org >>>> http://hibernate.org >>>> >>>> JBoss a division of Red Hat >>>> max.andersen(a)jboss.com >>> >> >> >> >> ---- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> max(a)hibernate.org >> http://hibernate.org >> >> JBoss a division of Red Hat >> max.andersen(a)jboss.com > -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate max(a)hibernate.org http://hibernate.org JBoss a division of Red Hat max.andersen(a)jboss.com

> 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(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>> >>>>>> >>>>>> ---- >>>>>> Max Rydahl Andersen >>>>>> callto://max.rydahl.andersen >>>>>> >>>>>> Hibernate >>>>>> max(a)hibernate.org >>>>>> http://hibernate.org >>>>>> >>>>>> JBoss a division of Red Hat >>>>>> max.andersen(a)jboss.com >>>>> >>>> >>>> >>>> >>>> ---- >>>> Max Rydahl Andersen >>>> callto://max.rydahl.andersen >>>> >>>> Hibernate >>>> max(a)hibernate.org >>>> http://hibernate.org >>>> >>>> JBoss a division of Red Hat >>>> max.andersen(a)jboss.com >>> >> >> >> >> ---- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> max(a)hibernate.org >> http://hibernate.org >> >> JBoss a division of Red Hat >> max.andersen(a)jboss.com > -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate max(a)hibernate.org http://hibernate.org JBoss a division of Red Hat max.andersen(a)jboss.com