hashcode, possible bug in IndirectionHandlerDefaultImpl

[Luis Cruz <Lu...@ist.utl.pt>]

Hello,

I have a question regarding OJB's use of hashcodes with regards to
proxies. In the class

   org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl

particularly in the invoke method it states that: "The hashCode
shouldn't change after materialization, so we use the hashCode of the
handler instead of the realSubject's one".

Firstly, as a colleague of mine so graciously pointed out, this comment
appears to be wrong. Isn't the hashcode of the handler used so as not to
materialize the real object just to get the hashcode?

But, that isn't the purpose of my mail... What troubles us is the buggy
behavior we have encountered due to the fact that the hashcodes of 
materialized objects differ from the hashcode of OJB's proxies.

Simply put, all of OJB's dynamic proxies use the hashcode calculated by
the org.apache.ojb.broker.Identity class. If our persistent classes
don't implement a "compatible" hashcode then the hashcode of a proxy
differs from the hashcode of the materialized object. Moreover, this is
the case if we simply don't implement any hashcode in our persistent
classes.

I don't think that implementing a "compatible" hashcode in our
persistent classes is a viable solution, because that would make our
business classes dependent on OJB.

Any comments/thoughts on this are greatly appreciated.

Thanks in advance,
Luis Cruz


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: hashcode, possible bug in IndirectionHandlerDefaultImpl

[Thomas Dudziak <to...@first.gmd.de>]

On Tue, 8 Jun 2004, Luis Cruz wrote:

> 
> Hello,
> 
> I have a question regarding OJB's use of hashcodes with regards to
> proxies. In the class
> 
>    org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
> 
> particularly in the invoke method it states that: "The hashCode
> shouldn't change after materialization, so we use the hashCode of the
> handler instead of the realSubject's one".
> 
> Firstly, as a colleague of mine so graciously pointed out, this comment
> appears to be wrong. Isn't the hashcode of the handler used so as not to
> materialize the real object just to get the hashcode?
> 
> But, that isn't the purpose of my mail... What troubles us is the buggy
> behavior we have encountered due to the fact that the hashcodes of 
> materialized objects differ from the hashcode of OJB's proxies.
> 
> Simply put, all of OJB's dynamic proxies use the hashcode calculated by
> the org.apache.ojb.broker.Identity class. If our persistent classes
> don't implement a "compatible" hashcode then the hashcode of a proxy
> differs from the hashcode of the materialized object. Moreover, this is
> the case if we simply don't implement any hashcode in our persistent
> classes.
> 
> I don't think that implementing a "compatible" hashcode in our
> persistent classes is a viable solution, because that would make our
> business classes dependent on OJB.

You're right, that seems strange (BTW there was something similar for
toString to prevent materialization in log messages).
I changed it in CVS. I don't know whether someone relies on the old
behavior, if so then I'll provide a modified indirection handler impl that
provides the old behavior.

Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org