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
>
