One of the reasons of these objects being proxied is that their change can mark the owning persistent entity as dirty.
Pinaki Poddar 972.834.2865 >-----Original Message----- >From: Evan Ireland [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 04, 2007 3:29 PM >To: [email protected] >Subject: RE: Cloning Calendar proxies > >Just curious, why are Calendar objects being proxied in the >first place? > >> -----Original Message----- >> From: Kevin Sutter [mailto:[EMAIL PROTECTED] >> Sent: Friday, 5 October 2007 9:01 a.m. >> To: [email protected] >> Subject: Cloning Calendar proxies >> >> Hi, >> It seems that the IBM JDK is cloning a Calendar object when >performing >> the >> .equals() method. If I call .equals() on one of our Calendar proxy >> objects, the underlying implementation seems to be cloning >the object >> before determining the equality. While using this cloned >object, one >> of the setter methods is called. Since this is a cloned Calendar >> proxy, we do some processing to access the associated StateManager. >> But, that requires access to a Broker and there is no Broker >instance >> associated with this cloned object and we end up throwing an >> IllegalStateException. Due to that exception, the .equals() always >> returns false. >> >> So, before I start experimenting with various fix strategies, I'm >> looking for some guidance from the original developers... >> >> o Should we override the clone() method? And, if we do, >should we be >> returning a non-proxy version of a Calendar object? Or, should we >> ensure that a fully populated Calendar proxy object get returned? >> >> o Or, should we think about overriding the .equals method on the >> Calendar proxies? I'm not too thrilled with this since then >we'll be >> attempting to implement the javadoc for these object types. >> >> Whatever we determine will probably apply to all of our proxy object >> types, even though we're only hitting this problem with the Calendar >> proxy due to the IBM JDK. >> >> Thoughts or suggestions? >> Kevin >> > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
