openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Cloning Calendar proxies
Date Thu, 04 Oct 2007 22:38:27 GMT
Hi Craig,

On 10/4/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> Hi Kevin,
>
> On Oct 4, 2007, at 1:00 PM, Kevin Sutter wrote:
>
> > Hi,
> > It seems that the IBM JDK is cloning a Calendar object when
> > performing the
> > .equals() method.
>
> Why is that?


:-)  Who knows?  I'm not privy to the IBM JDK implementation or why they do
what they do...

> 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.
>
> Seems like the clone should be treated as detached, which implies
> that we implement our own clone() method, something like: load fields
> from database; super.clone(); StateManager = null; return;


I would agree with this approach, but I wanted to get some other opinions
before going down this path.  This would resolve the issue that we're
experiencing as well...

> 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?
>
> I'm not clear what you mean by "fully populated Calendar". Do you
> mean simply instantiated with values from the database? If so, yes.


By "fully populated", I meant attempt to make the StateManager usable.
Basically, do a deep copy for the clone.  But, I like the approach you
mentioned in your earlier comment and just transfer the state of the object,
but null out the StateManager.  This would prevent the access to the Broker
and we'd be happy.

>
> > 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.
>
> Oh oh. Please no.


:-)  Just thought I would throw that idea out there.

Thanks,
Kevin

Craig
> >
> > 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
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message