You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Kevin Sutter (JIRA)" <ji...@apache.org> on 2007/10/08 16:14:50 UTC
[jira] Created: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Cloning Calendar proxies doesn't detach from StateManager
---------------------------------------------------------
Key: OPENJPA-396
URL: https://issues.apache.org/jira/browse/OPENJPA-396
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 1.0.0, 1.0.1, 1.1.0
Reporter: Kevin Sutter
Assignee: Kevin Sutter
Fix For: 1.0.1, 1.1.0
This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
Thanks,
Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't detach from StateManager
Posted by Kevin Sutter <kw...@gmail.com>.
Pinaki,
On 10/8/07, Pinaki Poddar <pp...@bea.com> wrote:
>
> Hi Craig/Kevin,
> Assertion 1. One of the critical reasons of proxying SCO is to dirty the
> StateManger corresponding to its owner.
> Assertion 2. This dirty-propagation must be active in remote clients
> i.e. in a detached mode as well, if the user configures it so.
>
> From the above, the actual instance of the SCO that is in the detached
> client must refer to the StateManager of its owning instance.
> That is where my doubt of Kevin's proposed change of nullfying the
> StateManager reference in cloning the SCO Proxy and treating the cloned
> instance as the detached copy of the SCO that the client sees.
>
> At least that is what I had interpreted of Kevin's suggested change.
> Correct me if I am wrong.
Nope, not for this reason.
Or is it just that no OpenJPA code ever calls Proxy.clone(), but is
> still overwritten because some JVM may clone a Calendar instance for
> unexplained reasons?
This is the reason for the change. I can put comments in the clone()
generation code to indicate the reasons for this method. I would not expect
OpenJPA to use this clone() method.
Btw, Proxy.copy() is used to keep a copy for restore upon rollback.
Correct.
Thanks,
Kevin
Pinaki Poddar
> 972.834.2865
>
>
> >-----Original Message-----
> >From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> >Sent: Monday, October 08, 2007 1:48 PM
> >To: dev@openjpa.apache.org
> >Subject: Re: [jira] Commented: (OPENJPA-396) Cloning Calendar
> >proxies doesn't detach from StateManager
> >
> >Hi Pinaki,
> >
> >On Oct 8, 2007, at 11:35 AM, Pinaki Poddar wrote:
> >
> >>> I am proposing to modify
> >>> the generated proxy code to override the clone() method. This
> >>> clone() method will do the necessary copying of data from the
> >>> original object, but then also null out the sm (StateManager) and
> >>> zero out the field attributes. This action detaches the cloned
> >>> object from the StateManager (and associated EntityManager).
> >>
> >> Who will invoke this Proxy.clone()? and when?
> >>
> >This is mostly from memory. If I get it too wrong, then you
> >can take all of my comments on this as a whiff of fresh air.
> >
> >> Are we now having
> >> A) the original user object x
> >
> >No, if you fetch an instance from the database with a field of
> >type Calendar, all you get is a proxy.
> >
> >> B) the proxy of x
> >
> >Yup, this is the value of the field.
> >
> >> C) clone of proxy of x
> >
> >If you clone the proxy, you get a clone. Which should not have
> >anything to do with the original proxy.
> >
> >> D) copy of proxy of x, as generated by Proxy.copy()
> >
> >I don't know of any use for this.
> >>
> >> If the clone with no owning statemanager is the 'detached' SCO, then
> >> how will the change in SCO be tracked in remote client?
> >
> >The bug refers to a strange usage of clone by the IBM VM. ;-)
> >
> >The clone with no owning statemanager should never be the
> >value of any field, whether attached or detached. If a clone
> >is set as the value of a field, then the enhanced putfield
> >method should assign ownership of that clone to the
> >statemanager of the instance whose field is being set. And
> >then the clone is no longer a clone but a bona fide proxy that
> >has an owner.
> >
> >Craig
> >>
> >> Pinaki Poddar
> >> 972.834.2865
> >>
> >>
> >>> -----Original Message-----
> >>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> >>> Sent: Monday, October 08, 2007 12:54 PM
> >>> To: dev@openjpa.apache.org
> >>> Subject: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies
> >>> doesn't detach from StateManager
> >>>
> >>>
> >>> [
> >>> https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atla
> >>> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
> >>> _12533169 ]
> >>>
> >>> Kevin Sutter commented on OPENJPA-396:
> >>> --------------------------------------
> >>>
> >>> [ Show > ]
> >>> Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In the
> >>> generated clone method, after calling super.clone(), why do you not
> >>> simply invoke stateManager = null; pcState = 0; instead of calling
> >>> the setOwner(null, 0) method? Seems like there is
> >additional code in
> >>> setOwner that you want to avoid because there is not yet any
> >>> relationship between the owner and the sco. The effect of calling
> >>> this method from the clone might be to disassociate the
> >original sco.
> >>>
> >>> Craig,
> >>> The original reason is that I couldn't figure out the proper serp
> >>> invocations to just set those two fields. :-) Then, I found the
> >>> setOwner method on the Proxy (also generated code) that did
> >just what
> >>> I was looking for. So, it was more straight-forward to just call
> >>> this method than to repeat the same code.
> >>>
> >>> As far as I can tell, the setOwner has no other side effects.
> >>> I am calling setOwner on the Proxy, not the StateManager. The code
> >>> is generated in the ProxyManagerImpl class (addProxyMethods
> >method).
> >>> And, the javadoc for this method is as follows:
> >>>
> >>> /**
> >>> * Reset the state of the proxy, and set the owning instance of
> >>> the
> >>> * proxy and the name of the field it is assigned to.
> >Set to null
> >>> to
> >>> * indicate that the proxy is no longer managed.
> >>> */
> >>> public void setOwner(OpenJPAStateManager sm, int field);
> >>>
> >>> Kevin
> >>>
> >>>
> >>>> Cloning Calendar proxies doesn't detach from StateManager
> >>>> ---------------------------------------------------------
> >>>>
> >>>> Key: OPENJPA-396
> >>>> URL:
> >>> https://issues.apache.org/jira/browse/OPENJPA-396
> >>>> Project: OpenJPA
> >>>> Issue Type: Bug
> >>>> Components: kernel
> >>>> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> >>>> Reporter: Kevin Sutter
> >>>> Assignee: Kevin Sutter
> >>>> Fix For: 1.0.1, 1.1.0
> >>>>
> >>>> Attachments: OPENJPA-396.patch
> >>>>
> >>>>
> >>>> This problem was first discussed on our dev mailing list:
> >>>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> >>>> Per the discussion on that thread, I am proposing to modify
> >>> the generated proxy code to override the clone() method. This
> >>> clone() method will do the necessary copying of data from the
> >>> original object, but then also null out the sm (StateManager) and
> >>> zero out the field attributes. This action detaches the cloned
> >>> object from the StateManager (and associated EntityManager).
> >>>> Instead of limiting this action to the Calendar proxy, I am
> >>> adding the clone() method implementation to all of our
> >proxy objects
> >>> that we generate. Granted, some of the object types do not
> >directly
> >>> support the clone() method, but that will be detected when or if
> >>> anybody attempts to use the clone() method on these types (compiler
> >>> generated error message).
> >>>> I'll be posting a patch shortly and I plan to commit the
> >>> changes later today (unless there is opposition).
> >>>> Thanks,
> >>>> Kevin
> >>>
> >>> --
> >>> This message is automatically generated by JIRA.
> >>> -
> >>> You can reply to this email to add a comment to the issue online.
> >>>
> >>>
> >>
> >> 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.
> >
> >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!
> >
> >
>
> 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.
>
RE: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't detach from StateManager
Posted by Pinaki Poddar <pp...@bea.com>.
Hi Craig/Kevin,
Assertion 1. One of the critical reasons of proxying SCO is to dirty the
StateManger corresponding to its owner.
Assertion 2. This dirty-propagation must be active in remote clients
i.e. in a detached mode as well, if the user configures it so.
>From the above, the actual instance of the SCO that is in the detached
client must refer to the StateManager of its owning instance.
That is where my doubt of Kevin's proposed change of nullfying the
StateManager reference in cloning the SCO Proxy and treating the cloned
instance as the detached copy of the SCO that the client sees.
At least that is what I had interpreted of Kevin's suggested change.
Correct me if I am wrong.
Or is it just that no OpenJPA code ever calls Proxy.clone(), but is
still overwritten because some JVM may clone a Calendar instance for
unexplained reasons?
Btw, Proxy.copy() is used to keep a copy for restore upon rollback.
Pinaki Poddar
972.834.2865
>-----Original Message-----
>From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>Sent: Monday, October 08, 2007 1:48 PM
>To: dev@openjpa.apache.org
>Subject: Re: [jira] Commented: (OPENJPA-396) Cloning Calendar
>proxies doesn't detach from StateManager
>
>Hi Pinaki,
>
>On Oct 8, 2007, at 11:35 AM, Pinaki Poddar wrote:
>
>>> I am proposing to modify
>>> the generated proxy code to override the clone() method. This
>>> clone() method will do the necessary copying of data from the
>>> original object, but then also null out the sm (StateManager) and
>>> zero out the field attributes. This action detaches the cloned
>>> object from the StateManager (and associated EntityManager).
>>
>> Who will invoke this Proxy.clone()? and when?
>>
>This is mostly from memory. If I get it too wrong, then you
>can take all of my comments on this as a whiff of fresh air.
>
>> Are we now having
>> A) the original user object x
>
>No, if you fetch an instance from the database with a field of
>type Calendar, all you get is a proxy.
>
>> B) the proxy of x
>
>Yup, this is the value of the field.
>
>> C) clone of proxy of x
>
>If you clone the proxy, you get a clone. Which should not have
>anything to do with the original proxy.
>
>> D) copy of proxy of x, as generated by Proxy.copy()
>
>I don't know of any use for this.
>>
>> If the clone with no owning statemanager is the 'detached' SCO, then
>> how will the change in SCO be tracked in remote client?
>
>The bug refers to a strange usage of clone by the IBM VM. ;-)
>
>The clone with no owning statemanager should never be the
>value of any field, whether attached or detached. If a clone
>is set as the value of a field, then the enhanced putfield
>method should assign ownership of that clone to the
>statemanager of the instance whose field is being set. And
>then the clone is no longer a clone but a bona fide proxy that
>has an owner.
>
>Craig
>>
>> Pinaki Poddar
>> 972.834.2865
>>
>>
>>> -----Original Message-----
>>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
>>> Sent: Monday, October 08, 2007 12:54 PM
>>> To: dev@openjpa.apache.org
>>> Subject: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies
>>> doesn't detach from StateManager
>>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atla
>>> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>>> _12533169 ]
>>>
>>> Kevin Sutter commented on OPENJPA-396:
>>> --------------------------------------
>>>
>>> [ Show > ]
>>> Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In the
>>> generated clone method, after calling super.clone(), why do you not
>>> simply invoke stateManager = null; pcState = 0; instead of calling
>>> the setOwner(null, 0) method? Seems like there is
>additional code in
>>> setOwner that you want to avoid because there is not yet any
>>> relationship between the owner and the sco. The effect of calling
>>> this method from the clone might be to disassociate the
>original sco.
>>>
>>> Craig,
>>> The original reason is that I couldn't figure out the proper serp
>>> invocations to just set those two fields. :-) Then, I found the
>>> setOwner method on the Proxy (also generated code) that did
>just what
>>> I was looking for. So, it was more straight-forward to just call
>>> this method than to repeat the same code.
>>>
>>> As far as I can tell, the setOwner has no other side effects.
>>> I am calling setOwner on the Proxy, not the StateManager. The code
>>> is generated in the ProxyManagerImpl class (addProxyMethods
>method).
>>> And, the javadoc for this method is as follows:
>>>
>>> /**
>>> * Reset the state of the proxy, and set the owning instance of
>>> the
>>> * proxy and the name of the field it is assigned to.
>Set to null
>>> to
>>> * indicate that the proxy is no longer managed.
>>> */
>>> public void setOwner(OpenJPAStateManager sm, int field);
>>>
>>> Kevin
>>>
>>>
>>>> Cloning Calendar proxies doesn't detach from StateManager
>>>> ---------------------------------------------------------
>>>>
>>>> Key: OPENJPA-396
>>>> URL:
>>> https://issues.apache.org/jira/browse/OPENJPA-396
>>>> Project: OpenJPA
>>>> Issue Type: Bug
>>>> Components: kernel
>>>> Affects Versions: 1.0.0, 1.0.1, 1.1.0
>>>> Reporter: Kevin Sutter
>>>> Assignee: Kevin Sutter
>>>> Fix For: 1.0.1, 1.1.0
>>>>
>>>> Attachments: OPENJPA-396.patch
>>>>
>>>>
>>>> This problem was first discussed on our dev mailing list:
>>>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
>>>> Per the discussion on that thread, I am proposing to modify
>>> the generated proxy code to override the clone() method. This
>>> clone() method will do the necessary copying of data from the
>>> original object, but then also null out the sm (StateManager) and
>>> zero out the field attributes. This action detaches the cloned
>>> object from the StateManager (and associated EntityManager).
>>>> Instead of limiting this action to the Calendar proxy, I am
>>> adding the clone() method implementation to all of our
>proxy objects
>>> that we generate. Granted, some of the object types do not
>directly
>>> support the clone() method, but that will be detected when or if
>>> anybody attempts to use the clone() method on these types (compiler
>>> generated error message).
>>>> I'll be posting a patch shortly and I plan to commit the
>>> changes later today (unless there is opposition).
>>>> Thanks,
>>>> Kevin
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>> 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.
>
>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!
>
>
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.
Re: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Pinaki,
On Oct 8, 2007, at 11:35 AM, Pinaki Poddar wrote:
>> I am proposing to modify
>> the generated proxy code to override the clone() method. This
>> clone() method will do the necessary copying of data from the
>> original object, but then also null out the sm (StateManager)
>> and zero out the field attributes. This action detaches the
>> cloned object from the StateManager (and associated EntityManager).
>
> Who will invoke this Proxy.clone()? and when?
>
This is mostly from memory. If I get it too wrong, then you can take
all of my comments on this as a whiff of fresh air.
> Are we now having
> A) the original user object x
No, if you fetch an instance from the database with a field of type
Calendar, all you get is a proxy.
> B) the proxy of x
Yup, this is the value of the field.
> C) clone of proxy of x
If you clone the proxy, you get a clone. Which should not have
anything to do with the original proxy.
> D) copy of proxy of x, as generated by Proxy.copy()
I don't know of any use for this.
>
> If the clone with no owning statemanager is the 'detached' SCO,
> then how
> will the change in SCO be tracked in remote client?
The bug refers to a strange usage of clone by the IBM VM. ;-)
The clone with no owning statemanager should never be the value of
any field, whether attached or detached. If a clone is set as the
value of a field, then the enhanced putfield method should assign
ownership of that clone to the statemanager of the instance whose
field is being set. And then the clone is no longer a clone but a
bona fide proxy that has an owner.
Craig
>
> Pinaki Poddar
> 972.834.2865
>
>
>> -----Original Message-----
>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
>> Sent: Monday, October 08, 2007 12:54 PM
>> To: dev@openjpa.apache.org
>> Subject: [jira] Commented: (OPENJPA-396) Cloning Calendar
>> proxies doesn't detach from StateManager
>>
>>
>> [
>> https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atla
>> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>> _12533169 ]
>>
>> Kevin Sutter commented on OPENJPA-396:
>> --------------------------------------
>>
>> [ Show > ]
>> Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In
>> the generated clone method, after calling super.clone(), why
>> do you not simply invoke stateManager = null; pcState = 0;
>> instead of calling the setOwner(null, 0) method? Seems like
>> there is additional code in setOwner that you want to avoid
>> because there is not yet any relationship between the owner
>> and the sco. The effect of calling this method from the clone
>> might be to disassociate the original sco.
>>
>> Craig,
>> The original reason is that I couldn't figure out the proper
>> serp invocations to just set those two fields. :-) Then, I
>> found the setOwner method on the Proxy (also generated code)
>> that did just what I was looking for. So, it was more
>> straight-forward to just call this method than to repeat the same
>> code.
>>
>> As far as I can tell, the setOwner has no other side effects.
>> I am calling setOwner on the Proxy, not the StateManager. The
>> code is generated in the ProxyManagerImpl class
>> (addProxyMethods method). And, the javadoc for this method is
>> as follows:
>>
>> /**
>> * Reset the state of the proxy, and set the owning instance of
>> the
>> * proxy and the name of the field it is assigned to. Set
>> to null to
>> * indicate that the proxy is no longer managed.
>> */
>> public void setOwner(OpenJPAStateManager sm, int field);
>>
>> Kevin
>>
>>
>>> Cloning Calendar proxies doesn't detach from StateManager
>>> ---------------------------------------------------------
>>>
>>> Key: OPENJPA-396
>>> URL:
>> https://issues.apache.org/jira/browse/OPENJPA-396
>>> Project: OpenJPA
>>> Issue Type: Bug
>>> Components: kernel
>>> Affects Versions: 1.0.0, 1.0.1, 1.1.0
>>> Reporter: Kevin Sutter
>>> Assignee: Kevin Sutter
>>> Fix For: 1.0.1, 1.1.0
>>>
>>> Attachments: OPENJPA-396.patch
>>>
>>>
>>> This problem was first discussed on our dev mailing list:
>>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
>>> Per the discussion on that thread, I am proposing to modify
>> the generated proxy code to override the clone() method. This
>> clone() method will do the necessary copying of data from the
>> original object, but then also null out the sm (StateManager)
>> and zero out the field attributes. This action detaches the
>> cloned object from the StateManager (and associated EntityManager).
>>> Instead of limiting this action to the Calendar proxy, I am
>> adding the clone() method implementation to all of our proxy
>> objects that we generate. Granted, some of the object types
>> do not directly support the clone() method, but that will be
>> detected when or if anybody attempts to use the clone() method
>> on these types (compiler generated error message).
>>> I'll be posting a patch shortly and I plan to commit the
>> changes later today (unless there is opposition).
>>> Thanks,
>>> Kevin
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
> 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.
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!
RE: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't detach from StateManager
Posted by Pinaki Poddar <pp...@bea.com>.
>I am proposing to modify
>the generated proxy code to override the clone() method. This
>clone() method will do the necessary copying of data from the
>original object, but then also null out the sm (StateManager)
>and zero out the field attributes. This action detaches the
>cloned object from the StateManager (and associated EntityManager).
Who will invoke this Proxy.clone()? and when?
Are we now having
A) the original user object x
B) the proxy of x
C) clone of proxy of x
D) copy of proxy of x, as generated by Proxy.copy()
If the clone with no owning statemanager is the 'detached' SCO, then how
will the change in SCO be tracked in remote client?
Pinaki Poddar
972.834.2865
>-----Original Message-----
>From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
>Sent: Monday, October 08, 2007 12:54 PM
>To: dev@openjpa.apache.org
>Subject: [jira] Commented: (OPENJPA-396) Cloning Calendar
>proxies doesn't detach from StateManager
>
>
> [
>https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atla
>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>_12533169 ]
>
>Kevin Sutter commented on OPENJPA-396:
>--------------------------------------
>
>[ Show > ]
>Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In
>the generated clone method, after calling super.clone(), why
>do you not simply invoke stateManager = null; pcState = 0;
>instead of calling the setOwner(null, 0) method? Seems like
>there is additional code in setOwner that you want to avoid
>because there is not yet any relationship between the owner
>and the sco. The effect of calling this method from the clone
>might be to disassociate the original sco.
>
>Craig,
>The original reason is that I couldn't figure out the proper
>serp invocations to just set those two fields. :-) Then, I
>found the setOwner method on the Proxy (also generated code)
>that did just what I was looking for. So, it was more
>straight-forward to just call this method than to repeat the same code.
>
>As far as I can tell, the setOwner has no other side effects.
>I am calling setOwner on the Proxy, not the StateManager. The
>code is generated in the ProxyManagerImpl class
>(addProxyMethods method). And, the javadoc for this method is
>as follows:
>
> /**
> * Reset the state of the proxy, and set the owning instance of the
> * proxy and the name of the field it is assigned to. Set
>to null to
> * indicate that the proxy is no longer managed.
> */
> public void setOwner(OpenJPAStateManager sm, int field);
>
>Kevin
>
>
>> Cloning Calendar proxies doesn't detach from StateManager
>> ---------------------------------------------------------
>>
>> Key: OPENJPA-396
>> URL:
>https://issues.apache.org/jira/browse/OPENJPA-396
>> Project: OpenJPA
>> Issue Type: Bug
>> Components: kernel
>> Affects Versions: 1.0.0, 1.0.1, 1.1.0
>> Reporter: Kevin Sutter
>> Assignee: Kevin Sutter
>> Fix For: 1.0.1, 1.1.0
>>
>> Attachments: OPENJPA-396.patch
>>
>>
>> This problem was first discussed on our dev mailing list:
>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
>> Per the discussion on that thread, I am proposing to modify
>the generated proxy code to override the clone() method. This
>clone() method will do the necessary copying of data from the
>original object, but then also null out the sm (StateManager)
>and zero out the field attributes. This action detaches the
>cloned object from the StateManager (and associated EntityManager).
>> Instead of limiting this action to the Calendar proxy, I am
>adding the clone() method implementation to all of our proxy
>objects that we generate. Granted, some of the object types
>do not directly support the clone() method, but that will be
>detected when or if anybody attempts to use the clone() method
>on these types (compiler generated error message).
>> I'll be posting a patch shortly and I plan to commit the
>changes later today (unless there is opposition).
>> Thanks,
>> Kevin
>
>--
>This message is automatically generated by JIRA.
>-
>You can reply to this email to add a comment to the issue online.
>
>
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.
Re: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
Sorry for the distraction.
My concern is really whether the proxy.setOwner is the tail or the dog.
If it is the tail, then I have no problems with it. Some other actor
is doing the work of synchronizing the state of the Entity, its
StateManager, and the owned Proxy. So having the proxy simply take
the value of setOwner and apply it is fine.
If the proxy.setOwner is ever the dog, that's where I have the issue.
If it's the dog, then the implementation might call into the owning
StateManager and ask it to make some state changes. And having the
clone call the StateManager would be wrong, since what you're trying
to do is make sure the clone stays unaware of the StateManager.
Craig
On Oct 8, 2007, at 12:16 PM, Kevin Sutter wrote:
> Craig,
>
>
> On 10/8/07, Craig Russell (JIRA) <ji...@apache.org> wrote:
>>
>>
>> [
>> https://issues.apache.org/jira/browse/OPENJPA-396?
>> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel#action_12533175]
>>
>> Craig Russell commented on OPENJPA-396:
>> ---------------------------------------
>>
>>> As far as I can tell, the setOwner has no other side effects.
>>
>> I hope someone else can comment on this, as it doesn't seem right.
>> You
>> don't want to <allow> any code in the clone to access the
>> StateManager,
>> since the StateManager knows about the original and can't tell
>> from the APIs
>> which proxy is calling it.
>>
>> I think we're asking for trouble, either now or in future if we
>> call this
>> method from the clone.
>
>
> Can you clarify which setOwner you are nervous about? I am calling
> Proxy.setOwner(), not StateManagerImpl.setOwner(). The code for
> Proxy.setOwner() is generated in ProxyManagerImpl.addProxyMethods
> (). The
> only thing that Proxy.setOwner() does is to set the sm and field
> attributes. In the clone() code that I am generating, I am calling
> Proxy.setOwner(null,0).
>
> Hope this helps clarify my usage. I'm still uncertain about your
> concerns.
>
> Thanks,
> Kevin
>
>> Cloning Calendar proxies doesn't detach from StateManager
>>> ---------------------------------------------------------
>>>
>>> Key: OPENJPA-396
>>> URL: https://issues.apache.org/jira/browse/
>>> OPENJPA-396
>>> Project: OpenJPA
>>> Issue Type: Bug
>>> Components: kernel
>>> Affects Versions: 1.0.0, 1.0.1, 1.1.0
>>> Reporter: Kevin Sutter
>>> Assignee: Kevin Sutter
>>> Fix For: 1.0.1, 1.1.0
>>>
>>> Attachments: OPENJPA-396.patch
>>>
>>>
>>> This problem was first discussed on our dev mailing list:
>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
>>> Per the discussion on that thread, I am proposing to modify the
>> generated proxy code to override the clone() method. This clone()
>> method
>> will do the necessary copying of data from the original object,
>> but then
>> also null out the sm (StateManager) and zero out the field
>> attributes. This
>> action detaches the cloned object from the StateManager (and
>> associated
>> EntityManager).
>>> Instead of limiting this action to the Calendar proxy, I am
>>> adding the
>> clone() method implementation to all of our proxy objects that we
>> generate. Granted, some of the object types do not directly
>> support the
>> clone() method, but that will be detected when or if anybody
>> attempts to use
>> the clone() method on these types (compiler generated error message).
>>> I'll be posting a patch shortly and I plan to commit the changes
>>> later
>> today (unless there is opposition).
>>> Thanks,
>>> Kevin
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
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!
Re: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't detach from StateManager
Posted by Kevin Sutter <kw...@gmail.com>.
Craig,
On 10/8/07, Craig Russell (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533175]
>
> Craig Russell commented on OPENJPA-396:
> ---------------------------------------
>
> > As far as I can tell, the setOwner has no other side effects.
>
> I hope someone else can comment on this, as it doesn't seem right. You
> don't want to <allow> any code in the clone to access the StateManager,
> since the StateManager knows about the original and can't tell from the APIs
> which proxy is calling it.
>
> I think we're asking for trouble, either now or in future if we call this
> method from the clone.
Can you clarify which setOwner you are nervous about? I am calling
Proxy.setOwner(), not StateManagerImpl.setOwner(). The code for
Proxy.setOwner() is generated in ProxyManagerImpl.addProxyMethods(). The
only thing that Proxy.setOwner() does is to set the sm and field
attributes. In the clone() code that I am generating, I am calling
Proxy.setOwner(null,0).
Hope this helps clarify my usage. I'm still uncertain about your concerns.
Thanks,
Kevin
> Cloning Calendar proxies doesn't detach from StateManager
> > ---------------------------------------------------------
> >
> > Key: OPENJPA-396
> > URL: https://issues.apache.org/jira/browse/OPENJPA-396
> > Project: OpenJPA
> > Issue Type: Bug
> > Components: kernel
> > Affects Versions: 1.0.0, 1.0.1, 1.1.0
> > Reporter: Kevin Sutter
> > Assignee: Kevin Sutter
> > Fix For: 1.0.1, 1.1.0
> >
> > Attachments: OPENJPA-396.patch
> >
> >
> > This problem was first discussed on our dev mailing list:
> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> > Per the discussion on that thread, I am proposing to modify the
> generated proxy code to override the clone() method. This clone() method
> will do the necessary copying of data from the original object, but then
> also null out the sm (StateManager) and zero out the field attributes. This
> action detaches the cloned object from the StateManager (and associated
> EntityManager).
> > Instead of limiting this action to the Calendar proxy, I am adding the
> clone() method implementation to all of our proxy objects that we
> generate. Granted, some of the object types do not directly support the
> clone() method, but that will be detected when or if anybody attempts to use
> the clone() method on these types (compiler generated error message).
> > I'll be posting a patch shortly and I plan to commit the changes later
> today (unless there is opposition).
> > Thanks,
> > Kevin
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533167 ]
Craig Russell commented on OPENJPA-396:
---------------------------------------
Hi Kevin,
One question. In the generated clone method, after calling super.clone(), why do you not simply invoke stateManager = null; pcState = 0; instead of calling the setOwner(null, 0) method?
Seems like there is additional code in setOwner that you want to avoid because there is not yet any relationship between the owner and the sco. The effect of calling this method from the clone might be to disassociate the original sco.
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533193 ]
Kevin Sutter commented on OPENJPA-396:
--------------------------------------
[ Show » ]
Craig Russell - 08/Oct/07 12:38 PM One other comment: In openjpa-kernel/src/test/java/org/apache/openjpa/util/TestProxyManager.java, + private static void assertSortedSetsEquals(SortedSet s1, SortedSet s2) { ... + assertTrue(s1.equals(s2)); I'm curious what this is testing, after you verified that the comparators are equivalent, the sizes are the same, and the contents are identical. What else is being tested here, except that the equals method is implemented correctly? Is that it?
Correct. The original problem surfaced because of a .equals() invocation between two Calendar objects. So, even though the Javadoc explains what attributes of a given Calendar, Date, Time, etc object are examined for .equals(), I just wanted to ensure that we didn't hit this problem again in the future because some JVM decided to change their implementation.
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Sutter updated OPENJPA-396:
---------------------------------
Attachment: OPENJPA-396.patch
Proposed patch for OpenJPA-396. It was built against the 1.0.x branch, but also seems to work with the trunk (1.1.0).
When testing this patch, I found that TestProxyManager had a couple of problems that needed correcting. After these changes were made, I had to re-factor a few of the "assert" methods so that we were testing for proper equality when copying vs cloning. That's why the patch for TestProxyManager looks larger than expected.
I plan to commit these changes later today unless concerns are raised with the patch.
Thanks,
Kevin
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Sutter resolved OPENJPA-396.
----------------------------------
Resolution: Fixed
Resolved via svn revision #582974 for both the 1.0.1 and 1.1.0 branches.
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533169 ]
Kevin Sutter commented on OPENJPA-396:
--------------------------------------
[ Show » ]
Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In the generated clone method, after calling super.clone(), why do you not simply invoke stateManager = null; pcState = 0; instead of calling the setOwner(null, 0) method? Seems like there is additional code in setOwner that you want to avoid because there is not yet any relationship between the owner and the sco. The effect of calling this method from the clone might be to disassociate the original sco.
Craig,
The original reason is that I couldn't figure out the proper serp invocations to just set those two fields. :-) Then, I found the setOwner method on the Proxy (also generated code) that did just what I was looking for. So, it was more straight-forward to just call this method than to repeat the same code.
As far as I can tell, the setOwner has no other side effects. I am calling setOwner on the Proxy, not the StateManager. The code is generated in the ProxyManagerImpl class (addProxyMethods method). And, the javadoc for this method is as follows:
/**
* Reset the state of the proxy, and set the owning instance of the
* proxy and the name of the field it is assigned to. Set to null to
* indicate that the proxy is no longer managed.
*/
public void setOwner(OpenJPAStateManager sm, int field);
Kevin
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533175 ]
Craig Russell commented on OPENJPA-396:
---------------------------------------
> As far as I can tell, the setOwner has no other side effects.
I hope someone else can comment on this, as it doesn't seem right. You don't want to <allow> any code in the clone to access the StateManager, since the StateManager knows about the original and can't tell from the APIs which proxy is calling it.
I think we're asking for trouble, either now or in future if we call this method from the clone.
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't
detach from StateManager
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533191 ]
Craig Russell commented on OPENJPA-396:
---------------------------------------
One other comment:
In openjpa-kernel/src/test/java/org/apache/openjpa/util/TestProxyManager.java,
+ private static void assertSortedSetsEquals(SortedSet s1, SortedSet s2) {
...
+ assertTrue(s1.equals(s2));
I'm curious what this is testing, after you verified that the comparators are equivalent, the sizes are the same, and the contents are identical. What else is being tested here, except that the equals method is implemented correctly? Is that it?
> Cloning Calendar proxies doesn't detach from StateManager
> ---------------------------------------------------------
>
> Key: OPENJPA-396
> URL: https://issues.apache.org/jira/browse/OPENJPA-396
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-396.patch
>
>
> This problem was first discussed on our dev mailing list: http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
> Per the discussion on that thread, I am proposing to modify the generated proxy code to override the clone() method. This clone() method will do the necessary copying of data from the original object, but then also null out the sm (StateManager) and zero out the field attributes. This action detaches the cloned object from the StateManager (and associated EntityManager).
> Instead of limiting this action to the Calendar proxy, I am adding the clone() method implementation to all of our proxy objects that we generate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to use the clone() method on these types (compiler generated error message).
> I'll be posting a patch shortly and I plan to commit the changes later today (unless there is opposition).
> Thanks,
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.