One possibility is that a redirection architecture could use a proxy for EjbObject that potentially fronts for the real Entity Bean. In general, the ejb spec is zealous about insulating the client interface from the container implementation. A work-around is to subclass LinkedList and override contains(), which is admittedly inconvenient. I use value objects rather than EjbObjects to collect a query result in order to protect against this and other oddities. Alex Paransky wrote: > The EJB 2.0 spec specifically states that equals or hashCode functions are > not defined for EJBObject. I don't understand why this decision was made. > > The reason I am asking, is that I just got bitten with an interesting bug. > In one of my functions, I need to execute many finders, and put the result > in to a single Collection. I create a LinkedList for this purpose. But > when the client gets the Collection I return (LinkedList) and tries to use > Collection.contains() API, it fails because LinkedList performs > EJBObject.equals operation instead of EJBObject.isIdentical. > > Which leads to a fact that most operation collections in java.util become > useless, since you can no longer say Collection.contains, or Set.addAll, or > use any operations which perform comparisons. > > Why not implement equals to execute isIdentical, and hashCode to execute > getPrimaryKey().hashCode()? > > Thanks. > -AP_ > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". -- Fred Loney Spirited Software, Inc. [EMAIL PROTECTED] =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
