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/27 21:51:50 UTC
[jira] Created: (OPENJPA-422) Calendar objects contained in a
detached Entity still have a "live" StateManagerImpl
Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
------------------------------------------------------------------------------------
Key: OPENJPA-422
URL: https://issues.apache.org/jira/browse/OPENJPA-422
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 1.0.0
Reporter: Kevin Sutter
Assignee: Kevin Sutter
Fix For: 1.0.1, 1.1.0
When Entities are detached, normally the StateManagerImpl instance associated with this Entity is replaced with a DetachedStateManager. Not only with the Entity itself, but also with the proxied attributes (Date, Calendar, Collection, and Map types). But, somehow the Calendar object type was forgotten in the code for this processing. So, the Calendar proxy type was left with a "live" StateManagerImpl instance. If the owning Broker (EntityManager) for this Entity was closed, then the use of this "live" StateManagerImpl would end up with an IllegalStateException. And, even if the owning Broker (EntityManager) was still open, this "live" StateManagerImpl should not have been tracking the state since the enclosing Entity was detached.
A simple one-line update to DetachManager$DetachFieldManager.reproxy() method will now process the Calendar proxies as well as the other proxies it was already doing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Patrick Linskey <pl...@gmail.com>.
Hi,
I agree that this is a bug.
-Patrick
On Oct 30, 2007 2:00 PM, Craig L Russell <Cr...@sun.com> wrote:
> Hi Evan,
>
> On Oct 30, 2007, at 12:35 PM, Evan Ireland wrote:
>
> > Kevin,
> >
> > JPA 1.0 section 3.2.3 Synchronization to the Database
> >
> > ...
> >
> > An update to the state of an entity includes both the assignment
> > of a new value to a persistent property or field of the entity
> > as well as the modification of a mutable value of a persistent
> > property or field.
> >
> > If you have to call the setter method again in order for the
> > change to be detected, surely this would not be spec-compliant.
> >
> > Should we report this as a bug?
>
> Yes, please report it as a bug, and include a trivial test case. We
> can then resolve it on the jira discussion.
>
> I wonder if there is a TCK test for this?
>
> One way to handle this kind of thing is to define an OpenJPA flag
> like "AutoDetectArrayChanges" which has a negative performance impact
> because it requires OpenJPA to compare the before-image and after-
> image of all xxx[ ] field values at flush or commit time. If the flag
> is false, then the only array types that are detected are those in
> which the field is replaced (even by itself). The default could be
> spec-compliant (true) or non-spec-compliant. The TCK might have to
> run with the flag set to slow, depending on whether there even is a
> TCK test.
>
> Craig
>
> >
> >> -----Original Message-----
> >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> >> Sent: Wednesday, 31 October 2007 2:38 a.m.
> >> To: dev@openjpa.apache.org
> >> Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
> >> contained in a detached Entity still have a "live" StateManagerImpl
> >>
> >> Evan,
> >>
> >> On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
> >>>
> >>> Since you appear to be familiar with the proxying stuff, I
> >> wonder if
> >>> you can say, for persistent attributes of type "byte[]"
> >> which cannot
> >>> be proxied, but are mutable, how does OpenJPA handle that case?
> >>
> >>
> >> As one big blob of data... :-) If you modify the
> >> individual byte array
> >> contents, then you will have to re-set the array into your
> >> persistence field in order for the change to be detected.
> >>
> >> OpenJPA also provides the ability to define a customized type
> >> plugin which might allow you to define and detect a byte[]
> >> modification, but I'm not totally familiar with this aspect
> >> to know if it would help your situation or not.
> >>
> >> Kevin
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> >>>> Sent: Sunday, 28 October 2007 9:22 a.m.
> >>>> To: dev@openjpa.apache.org
> >>>> Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> >> contained
> >>>> in a detached Entity still have a "live" StateManagerImpl
> >>>>
> >>>>
> >>>> [
> >>>> https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> >>>> assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >>>>
> >>>> Kevin Sutter resolved OPENJPA-422.
> >>>> ----------------------------------
> >>>>
> >>>> Resolution: Fixed
> >>>>
> >>>> Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> >>>>
> >>>>> Calendar objects contained in a detached Entity still
> >> have a "live"
> >>>>> StateManagerImpl
> >>>>>
> >>>>
> >> --------------------------------------------------------------------
> >>>> --
> >>>>> --------------
> >>>>>
> >>>>> Key: OPENJPA-422
> >>>>> URL:
> >>>> https://issues.apache.org/jira/browse/OPENJPA-422
> >>>>> Project: OpenJPA
> >>>>> Issue Type: Bug
> >>>>> Components: kernel
> >>>>> Affects Versions: 1.0.0
> >>>>> Reporter: Kevin Sutter
> >>>>> Assignee: Kevin Sutter
> >>>>> Fix For: 1.0.1, 1.1.0
> >>>>>
> >>>>>
> >>>>> When Entities are detached, normally the StateManagerImpl
> >>>> instance associated with this Entity is replaced with a
> >>>> DetachedStateManager. Not only with the Entity itself, but also
> >>>> with the proxied attributes (Date, Calendar, Collection, and Map
> >>>> types). But, somehow the Calendar object type was
> >> forgotten in the
> >>>> code for this processing. So, the Calendar proxy type
> >> was left with
> >>>> a "live" StateManagerImpl instance.
> >>>> If the owning Broker (EntityManager) for this Entity was closed,
> >>>> then the use of this "live" StateManagerImpl would end up with an
> >>>> IllegalStateException. And, even if the owning Broker
> >>>> (EntityManager) was still open, this "live"
> >>>> StateManagerImpl should not have been tracking the state
> >> since the
> >>>> enclosing Entity was detached.
> >>>>> A simple one-line update to
> >>>> DetachManager$DetachFieldManager.reproxy() method will
> >> now process
> >>>> the Calendar proxies as well as the other proxies it was already
> >>>> doing.
> >>>>
> >>>> --
> >>>> 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!
>
>
--
Patrick Linskey
202 669 5907
Re: Byte array handling is probably not spec compliant - was RE:
[jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity
still have a "live" StateManagerImpl
Posted by "Lance J. Andersen" <La...@Sun.COM>.
that is correct, the default configuration must be compatible to the
spec regardless of whether there is a test in the TCK for a given assertion
regards
lance
Evan Ireland wrote:
> Craig,
>
> I don't believe that non-spec-compliant behaviour is
> permitted in the "default" configuration of any Java EE
> technology.
>
>
>> -----Original Message-----
>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>> Sent: Wednesday, 31 October 2007 10:00 a.m.
>> To: dev@openjpa.apache.org
>> Subject: Re: Byte array handling is probably not spec
>> compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar
>> objects contained in a detached Entity still have a "live"
>> StateManagerImpl
>>
>> Hi Evan,
>>
>> On Oct 30, 2007, at 12:35 PM, Evan Ireland wrote:
>>
>>
>>> Kevin,
>>>
>>> JPA 1.0 section 3.2.3 Synchronization to the Database
>>>
>>> ...
>>>
>>> An update to the state of an entity includes both the assignment
>>> of a new value to a persistent property or field of the entity
>>> as well as the modification of a mutable value of a persistent
>>> property or field.
>>>
>>> If you have to call the setter method again in order for
>>>
>> the change to
>>
>>> be detected, surely this would not be spec-compliant.
>>>
>>> Should we report this as a bug?
>>>
>> Yes, please report it as a bug, and include a trivial test
>> case. We can then resolve it on the jira discussion.
>>
>> I wonder if there is a TCK test for this?
>>
>> One way to handle this kind of thing is to define an OpenJPA
>> flag like "AutoDetectArrayChanges" which has a negative
>> performance impact because it requires OpenJPA to compare the
>> before-image and after- image of all xxx[ ] field values at
>> flush or commit time. If the flag is false, then the only
>> array types that are detected are those in which the field is
>> replaced (even by itself). The default could be
>> spec-compliant (true) or non-spec-compliant. The TCK might
>> have to run with the flag set to slow, depending on whether
>> there even is a TCK test.
>>
>> Craig
>>
>>>> -----Original Message-----
>>>> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>>>> Sent: Wednesday, 31 October 2007 2:38 a.m.
>>>> To: dev@openjpa.apache.org
>>>> Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
>>>> contained in a detached Entity still have a "live" StateManagerImpl
>>>>
>>>> Evan,
>>>>
>>>> On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
>>>>
>>>>> Since you appear to be familiar with the proxying stuff, I
>>>>>
>>>> wonder if
>>>>
>>>>> you can say, for persistent attributes of type "byte[]"
>>>>>
>>>> which cannot
>>>>
>>>>> be proxied, but are mutable, how does OpenJPA handle that case?
>>>>>
>>>> As one big blob of data... :-) If you modify the
>>>> individual byte array
>>>> contents, then you will have to re-set the array into your
>>>> persistence field in order for the change to be detected.
>>>>
>>>> OpenJPA also provides the ability to define a customized
>>>>
>> type plugin
>>
>>>> which might allow you to define and detect a byte[]
>>>>
>> modification, but
>>
>>>> I'm not totally familiar with this aspect to know if it would help
>>>> your situation or not.
>>>>
>>>> Kevin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>>
>>>>>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
>>>>>> Sent: Sunday, 28 October 2007 9:22 a.m.
>>>>>> To: dev@openjpa.apache.org
>>>>>> Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
>>>>>>
>>>> contained
>>>>
>>>>>> in a detached Entity still have a "live" StateManagerImpl
>>>>>>
>>>>>>
>>>>>> [
>>>>>> https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
>>>>>> assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>>>>>
>>>>>> Kevin Sutter resolved OPENJPA-422.
>>>>>> ----------------------------------
>>>>>>
>>>>>> Resolution: Fixed
>>>>>>
>>>>>> Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
>>>>>>
>>>>>>
>>>>>>> Calendar objects contained in a detached Entity still
>>>>>>>
>>>> have a "live"
>>>>
>>>>>>> StateManagerImpl
>>>>>>>
>>>>>>>
>> --------------------------------------------------------------------
>>
>>>>>> --
>>>>>>
>>>>>>> --------------
>>>>>>>
>>>>>>> Key: OPENJPA-422
>>>>>>> URL:
>>>>>>>
>>>>>> https://issues.apache.org/jira/browse/OPENJPA-422
>>>>>>
>>>>>>> Project: OpenJPA
>>>>>>> Issue Type: Bug
>>>>>>> Components: kernel
>>>>>>> Affects Versions: 1.0.0
>>>>>>> Reporter: Kevin Sutter
>>>>>>> Assignee: Kevin Sutter
>>>>>>> Fix For: 1.0.1, 1.1.0
>>>>>>>
>>>>>>>
>>>>>>> When Entities are detached, normally the StateManagerImpl
>>>>>>>
>>>>>> instance associated with this Entity is replaced with a
>>>>>> DetachedStateManager. Not only with the Entity itself, but also
>>>>>> with the proxied attributes (Date, Calendar, Collection, and Map
>>>>>> types). But, somehow the Calendar object type was
>>>>>>
>>>> forgotten in the
>>>>
>>>>>> code for this processing. So, the Calendar proxy type
>>>>>>
>>>> was left with
>>>>
>>>>>> a "live" StateManagerImpl instance.
>>>>>> If the owning Broker (EntityManager) for this Entity was closed,
>>>>>> then the use of this "live" StateManagerImpl would end
>>>>>>
>> up with an
>>
>>>>>> IllegalStateException. And, even if the owning Broker
>>>>>> (EntityManager) was still open, this "live"
>>>>>> StateManagerImpl should not have been tracking the state
>>>>>>
>>>> since the
>>>>
>>>>>> enclosing Entity was detached.
>>>>>>
>>>>>>> A simple one-line update to
>>>>>>>
>>>>>> DetachManager$DetachFieldManager.reproxy() method will
>>>>>>
>>>> now process
>>>>
>>>>>> the Calendar proxies as well as the other proxies it was already
>>>>>> doing.
>>>>>>
>>>>>> --
>>>>>> 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: Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Evan Ireland <ei...@sybase.com>.
Craig,
I don't believe that non-spec-compliant behaviour is
permitted in the "default" configuration of any Java EE
technology.
> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Wednesday, 31 October 2007 10:00 a.m.
> To: dev@openjpa.apache.org
> Subject: Re: Byte array handling is probably not spec
> compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar
> objects contained in a detached Entity still have a "live"
> StateManagerImpl
>
> Hi Evan,
>
> On Oct 30, 2007, at 12:35 PM, Evan Ireland wrote:
>
> > Kevin,
> >
> > JPA 1.0 section 3.2.3 Synchronization to the Database
> >
> > ...
> >
> > An update to the state of an entity includes both the assignment
> > of a new value to a persistent property or field of the entity
> > as well as the modification of a mutable value of a persistent
> > property or field.
> >
> > If you have to call the setter method again in order for
> the change to
> > be detected, surely this would not be spec-compliant.
> >
> > Should we report this as a bug?
>
> Yes, please report it as a bug, and include a trivial test
> case. We can then resolve it on the jira discussion.
>
> I wonder if there is a TCK test for this?
>
> One way to handle this kind of thing is to define an OpenJPA
> flag like "AutoDetectArrayChanges" which has a negative
> performance impact because it requires OpenJPA to compare the
> before-image and after- image of all xxx[ ] field values at
> flush or commit time. If the flag is false, then the only
> array types that are detected are those in which the field is
> replaced (even by itself). The default could be
> spec-compliant (true) or non-spec-compliant. The TCK might
> have to run with the flag set to slow, depending on whether
> there even is a TCK test.
>
> Craig
> >
> >> -----Original Message-----
> >> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> >> Sent: Wednesday, 31 October 2007 2:38 a.m.
> >> To: dev@openjpa.apache.org
> >> Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
> >> contained in a detached Entity still have a "live" StateManagerImpl
> >>
> >> Evan,
> >>
> >> On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
> >>>
> >>> Since you appear to be familiar with the proxying stuff, I
> >> wonder if
> >>> you can say, for persistent attributes of type "byte[]"
> >> which cannot
> >>> be proxied, but are mutable, how does OpenJPA handle that case?
> >>
> >>
> >> As one big blob of data... :-) If you modify the
> >> individual byte array
> >> contents, then you will have to re-set the array into your
> >> persistence field in order for the change to be detected.
> >>
> >> OpenJPA also provides the ability to define a customized
> type plugin
> >> which might allow you to define and detect a byte[]
> modification, but
> >> I'm not totally familiar with this aspect to know if it would help
> >> your situation or not.
> >>
> >> Kevin
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> >>>> Sent: Sunday, 28 October 2007 9:22 a.m.
> >>>> To: dev@openjpa.apache.org
> >>>> Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> >> contained
> >>>> in a detached Entity still have a "live" StateManagerImpl
> >>>>
> >>>>
> >>>> [
> >>>> https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> >>>> assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >>>>
> >>>> Kevin Sutter resolved OPENJPA-422.
> >>>> ----------------------------------
> >>>>
> >>>> Resolution: Fixed
> >>>>
> >>>> Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> >>>>
> >>>>> Calendar objects contained in a detached Entity still
> >> have a "live"
> >>>>> StateManagerImpl
> >>>>>
> >>>>
> >>
> --------------------------------------------------------------------
> >>>> --
> >>>>> --------------
> >>>>>
> >>>>> Key: OPENJPA-422
> >>>>> URL:
> >>>> https://issues.apache.org/jira/browse/OPENJPA-422
> >>>>> Project: OpenJPA
> >>>>> Issue Type: Bug
> >>>>> Components: kernel
> >>>>> Affects Versions: 1.0.0
> >>>>> Reporter: Kevin Sutter
> >>>>> Assignee: Kevin Sutter
> >>>>> Fix For: 1.0.1, 1.1.0
> >>>>>
> >>>>>
> >>>>> When Entities are detached, normally the StateManagerImpl
> >>>> instance associated with this Entity is replaced with a
> >>>> DetachedStateManager. Not only with the Entity itself, but also
> >>>> with the proxied attributes (Date, Calendar, Collection, and Map
> >>>> types). But, somehow the Calendar object type was
> >> forgotten in the
> >>>> code for this processing. So, the Calendar proxy type
> >> was left with
> >>>> a "live" StateManagerImpl instance.
> >>>> If the owning Broker (EntityManager) for this Entity was closed,
> >>>> then the use of this "live" StateManagerImpl would end
> up with an
> >>>> IllegalStateException. And, even if the owning Broker
> >>>> (EntityManager) was still open, this "live"
> >>>> StateManagerImpl should not have been tracking the state
> >> since the
> >>>> enclosing Entity was detached.
> >>>>> A simple one-line update to
> >>>> DetachManager$DetachFieldManager.reproxy() method will
> >> now process
> >>>> the Calendar proxies as well as the other proxies it was already
> >>>> doing.
> >>>>
> >>>> --
> >>>> 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: Byte array handling is probably not spec compliant - was RE:
[jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity
still have a "live" StateManagerImpl
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Evan,
On Oct 30, 2007, at 12:35 PM, Evan Ireland wrote:
> Kevin,
>
> JPA 1.0 section 3.2.3 Synchronization to the Database
>
> ...
>
> An update to the state of an entity includes both the assignment
> of a new value to a persistent property or field of the entity
> as well as the modification of a mutable value of a persistent
> property or field.
>
> If you have to call the setter method again in order for the
> change to be detected, surely this would not be spec-compliant.
>
> Should we report this as a bug?
Yes, please report it as a bug, and include a trivial test case. We
can then resolve it on the jira discussion.
I wonder if there is a TCK test for this?
One way to handle this kind of thing is to define an OpenJPA flag
like "AutoDetectArrayChanges" which has a negative performance impact
because it requires OpenJPA to compare the before-image and after-
image of all xxx[ ] field values at flush or commit time. If the flag
is false, then the only array types that are detected are those in
which the field is replaced (even by itself). The default could be
spec-compliant (true) or non-spec-compliant. The TCK might have to
run with the flag set to slow, depending on whether there even is a
TCK test.
Craig
>
>> -----Original Message-----
>> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> Sent: Wednesday, 31 October 2007 2:38 a.m.
>> To: dev@openjpa.apache.org
>> Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
>> contained in a detached Entity still have a "live" StateManagerImpl
>>
>> Evan,
>>
>> On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
>>>
>>> Since you appear to be familiar with the proxying stuff, I
>> wonder if
>>> you can say, for persistent attributes of type "byte[]"
>> which cannot
>>> be proxied, but are mutable, how does OpenJPA handle that case?
>>
>>
>> As one big blob of data... :-) If you modify the
>> individual byte array
>> contents, then you will have to re-set the array into your
>> persistence field in order for the change to be detected.
>>
>> OpenJPA also provides the ability to define a customized type
>> plugin which might allow you to define and detect a byte[]
>> modification, but I'm not totally familiar with this aspect
>> to know if it would help your situation or not.
>>
>> Kevin
>>
>>
>>
>>
>>> -----Original Message-----
>>>> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
>>>> Sent: Sunday, 28 October 2007 9:22 a.m.
>>>> To: dev@openjpa.apache.org
>>>> Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
>> contained
>>>> in a detached Entity still have a "live" StateManagerImpl
>>>>
>>>>
>>>> [
>>>> https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
>>>> assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>>>
>>>> Kevin Sutter resolved OPENJPA-422.
>>>> ----------------------------------
>>>>
>>>> Resolution: Fixed
>>>>
>>>> Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
>>>>
>>>>> Calendar objects contained in a detached Entity still
>> have a "live"
>>>>> StateManagerImpl
>>>>>
>>>>
>> --------------------------------------------------------------------
>>>> --
>>>>> --------------
>>>>>
>>>>> Key: OPENJPA-422
>>>>> URL:
>>>> https://issues.apache.org/jira/browse/OPENJPA-422
>>>>> Project: OpenJPA
>>>>> Issue Type: Bug
>>>>> Components: kernel
>>>>> Affects Versions: 1.0.0
>>>>> Reporter: Kevin Sutter
>>>>> Assignee: Kevin Sutter
>>>>> Fix For: 1.0.1, 1.1.0
>>>>>
>>>>>
>>>>> When Entities are detached, normally the StateManagerImpl
>>>> instance associated with this Entity is replaced with a
>>>> DetachedStateManager. Not only with the Entity itself, but also
>>>> with the proxied attributes (Date, Calendar, Collection, and Map
>>>> types). But, somehow the Calendar object type was
>> forgotten in the
>>>> code for this processing. So, the Calendar proxy type
>> was left with
>>>> a "live" StateManagerImpl instance.
>>>> If the owning Broker (EntityManager) for this Entity was closed,
>>>> then the use of this "live" StateManagerImpl would end up with an
>>>> IllegalStateException. And, even if the owning Broker
>>>> (EntityManager) was still open, this "live"
>>>> StateManagerImpl should not have been tracking the state
>> since the
>>>> enclosing Entity was detached.
>>>>> A simple one-line update to
>>>> DetachManager$DetachFieldManager.reproxy() method will
>> now process
>>>> the Calendar proxies as well as the other proxies it was already
>>>> doing.
>>>>
>>>> --
>>>> 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: Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Evan Ireland <ei...@sybase.com>.
Kevin,
You wrote:
> No, because byte[], Byte[], char[], and Character[] are considered
immutable types.
According to Linda DeMichel, they should be considered mutable.
(I just checked)
(And also according to me, I was on the expert group too :-)
Patrick, can we have your take on thie too?
Thanks.
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Wednesday, 31 October 2007 8:50 a.m.
> To: dev@openjpa.apache.org
> Subject: Re: Byte array handling is probably not spec
> compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar
> objects contained in a detached Entity still have a "live"
> StateManagerImpl
>
> Evan,
>
> On 10/30/07, Evan Ireland <ei...@sybase.com> wrote:
> >
> > Kevin,
> >
> > JPA 1.0 section 3.2.3 Synchronization to the Database
> >
> > ...
> >
> > An update to the state of an entity includes both the assignment
> > of a new value to a persistent property or field of the entity
> > as well as the modification of a mutable value of a persistent
> > property or field.
> >
> > If you have to call the setter method again in order for
> the change to
> > be detected, surely this would not be spec-compliant.
> >
> > Should we report this as a bug?
>
>
> No, because byte[], Byte[], char[], and Character[] are
> considered immutable types.
>
> Kevin
>
> > -----Original Message-----
> > > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> > > Sent: Wednesday, 31 October 2007 2:38 a.m.
> > > To: dev@openjpa.apache.org
> > > Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
> > > contained in a detached Entity still have a "live"
> StateManagerImpl
> > >
> > > Evan,
> > >
> > > On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
> > > >
> > > > Since you appear to be familiar with the proxying stuff, I
> > > wonder if
> > > > you can say, for persistent attributes of type "byte[]"
> > > which cannot
> > > > be proxied, but are mutable, how does OpenJPA handle that case?
> > >
> > >
> > > As one big blob of data... :-) If you modify the
> > > individual byte array
> > > contents, then you will have to re-set the array into your
> > > persistence field in order for the change to be detected.
> > >
> > > OpenJPA also provides the ability to define a customized
> type plugin
> > > which might allow you to define and detect a byte[] modification,
> > > but I'm not totally familiar with this aspect to know if it would
> > > help your situation or not.
> > >
> > > Kevin
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > > From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> > > > > Sent: Sunday, 28 October 2007 9:22 a.m.
> > > > > To: dev@openjpa.apache.org
> > > > > Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> > > contained
> > > > > in a detached Entity still have a "live" StateManagerImpl
> > > > >
> > > > >
> > > > > [
> > > > > https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> > > > > assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > > > >
> > > > > Kevin Sutter resolved OPENJPA-422.
> > > > > ----------------------------------
> > > > >
> > > > > Resolution: Fixed
> > > > >
> > > > > Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> > > > >
> > > > > > Calendar objects contained in a detached Entity still
> > > have a "live"
> > > > > > StateManagerImpl
> > > > > >
> > > > >
> > >
> --------------------------------------------------------------------
> > > > > --
> > > > > > --------------
> > > > > >
> > > > > > Key: OPENJPA-422
> > > > > > URL:
> > > > > https://issues.apache.org/jira/browse/OPENJPA-422
> > > > > > Project: OpenJPA
> > > > > > Issue Type: Bug
> > > > > > Components: kernel
> > > > > > Affects Versions: 1.0.0
> > > > > > Reporter: Kevin Sutter
> > > > > > Assignee: Kevin Sutter
> > > > > > Fix For: 1.0.1, 1.1.0
> > > > > >
> > > > > >
> > > > > > When Entities are detached, normally the StateManagerImpl
> > > > > instance associated with this Entity is replaced with a
> > > > > DetachedStateManager. Not only with the Entity
> itself, but also
> > > > > with the proxied attributes (Date, Calendar,
> Collection, and Map
> > > > > types). But, somehow the Calendar object type was
> > > forgotten in the
> > > > > code for this processing. So, the Calendar proxy type
> > > was left with
> > > > > a "live" StateManagerImpl instance.
> > > > > If the owning Broker (EntityManager) for this Entity
> was closed,
> > > > > then the use of this "live" StateManagerImpl would
> end up with
> > > > > an IllegalStateException. And, even if the owning Broker
> > > > > (EntityManager) was still open, this "live"
> > > > > StateManagerImpl should not have been tracking the state
> > > since the
> > > > > enclosing Entity was detached.
> > > > > > A simple one-line update to
> > > > > DetachManager$DetachFieldManager.reproxy() method will
> > > now process
> > > > > the Calendar proxies as well as the other proxies it
> was already
> > > > > doing.
> > > > >
> > > > > --
> > > > > This message is automatically generated by JIRA.
> > > > > -
> > > > > You can reply to this email to add a comment to the
> issue online.
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Kevin Sutter <kw...@gmail.com>.
Evan,
On 10/30/07, Evan Ireland <ei...@sybase.com> wrote:
>
> Kevin,
>
> JPA 1.0 section 3.2.3 Synchronization to the Database
>
> ...
>
> An update to the state of an entity includes both the assignment
> of a new value to a persistent property or field of the entity
> as well as the modification of a mutable value of a persistent
> property or field.
>
> If you have to call the setter method again in order for the
> change to be detected, surely this would not be spec-compliant.
>
> Should we report this as a bug?
No, because byte[], Byte[], char[], and Character[] are considered immutable
types.
Kevin
> -----Original Message-----
> > From: Kevin Sutter [mailto:kwsutter@gmail.com]
> > Sent: Wednesday, 31 October 2007 2:38 a.m.
> > To: dev@openjpa.apache.org
> > Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
> > contained in a detached Entity still have a "live" StateManagerImpl
> >
> > Evan,
> >
> > On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
> > >
> > > Since you appear to be familiar with the proxying stuff, I
> > wonder if
> > > you can say, for persistent attributes of type "byte[]"
> > which cannot
> > > be proxied, but are mutable, how does OpenJPA handle that case?
> >
> >
> > As one big blob of data... :-) If you modify the
> > individual byte array
> > contents, then you will have to re-set the array into your
> > persistence field in order for the change to be detected.
> >
> > OpenJPA also provides the ability to define a customized type
> > plugin which might allow you to define and detect a byte[]
> > modification, but I'm not totally familiar with this aspect
> > to know if it would help your situation or not.
> >
> > Kevin
> >
> >
> >
> >
> > > -----Original Message-----
> > > > From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> > > > Sent: Sunday, 28 October 2007 9:22 a.m.
> > > > To: dev@openjpa.apache.org
> > > > Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> > contained
> > > > in a detached Entity still have a "live" StateManagerImpl
> > > >
> > > >
> > > > [
> > > > https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> > > > assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > > >
> > > > Kevin Sutter resolved OPENJPA-422.
> > > > ----------------------------------
> > > >
> > > > Resolution: Fixed
> > > >
> > > > Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> > > >
> > > > > Calendar objects contained in a detached Entity still
> > have a "live"
> > > > > StateManagerImpl
> > > > >
> > > >
> > --------------------------------------------------------------------
> > > > --
> > > > > --------------
> > > > >
> > > > > Key: OPENJPA-422
> > > > > URL:
> > > > https://issues.apache.org/jira/browse/OPENJPA-422
> > > > > Project: OpenJPA
> > > > > Issue Type: Bug
> > > > > Components: kernel
> > > > > Affects Versions: 1.0.0
> > > > > Reporter: Kevin Sutter
> > > > > Assignee: Kevin Sutter
> > > > > Fix For: 1.0.1, 1.1.0
> > > > >
> > > > >
> > > > > When Entities are detached, normally the StateManagerImpl
> > > > instance associated with this Entity is replaced with a
> > > > DetachedStateManager. Not only with the Entity itself, but also
> > > > with the proxied attributes (Date, Calendar, Collection, and Map
> > > > types). But, somehow the Calendar object type was
> > forgotten in the
> > > > code for this processing. So, the Calendar proxy type
> > was left with
> > > > a "live" StateManagerImpl instance.
> > > > If the owning Broker (EntityManager) for this Entity was closed,
> > > > then the use of this "live" StateManagerImpl would end up with an
> > > > IllegalStateException. And, even if the owning Broker
> > > > (EntityManager) was still open, this "live"
> > > > StateManagerImpl should not have been tracking the state
> > since the
> > > > enclosing Entity was detached.
> > > > > A simple one-line update to
> > > > DetachManager$DetachFieldManager.reproxy() method will
> > now process
> > > > the Calendar proxies as well as the other proxies it was already
> > > > doing.
> > > >
> > > > --
> > > > This message is automatically generated by JIRA.
> > > > -
> > > > You can reply to this email to add a comment to the issue online.
> > > >
> > > >
> > >
> > >
> >
>
>
Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Evan Ireland <ei...@sybase.com>.
Kevin,
JPA 1.0 section 3.2.3 Synchronization to the Database
...
An update to the state of an entity includes both the assignment
of a new value to a persistent property or field of the entity
as well as the modification of a mutable value of a persistent
property or field.
If you have to call the setter method again in order for the
change to be detected, surely this would not be spec-compliant.
Should we report this as a bug?
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Wednesday, 31 October 2007 2:38 a.m.
> To: dev@openjpa.apache.org
> Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects
> contained in a detached Entity still have a "live" StateManagerImpl
>
> Evan,
>
> On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
> >
> > Since you appear to be familiar with the proxying stuff, I
> wonder if
> > you can say, for persistent attributes of type "byte[]"
> which cannot
> > be proxied, but are mutable, how does OpenJPA handle that case?
>
>
> As one big blob of data... :-) If you modify the
> individual byte array
> contents, then you will have to re-set the array into your
> persistence field in order for the change to be detected.
>
> OpenJPA also provides the ability to define a customized type
> plugin which might allow you to define and detect a byte[]
> modification, but I'm not totally familiar with this aspect
> to know if it would help your situation or not.
>
> Kevin
>
>
>
>
> > -----Original Message-----
> > > From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> > > Sent: Sunday, 28 October 2007 9:22 a.m.
> > > To: dev@openjpa.apache.org
> > > Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> contained
> > > in a detached Entity still have a "live" StateManagerImpl
> > >
> > >
> > > [
> > > https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> > > assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > >
> > > Kevin Sutter resolved OPENJPA-422.
> > > ----------------------------------
> > >
> > > Resolution: Fixed
> > >
> > > Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> > >
> > > > Calendar objects contained in a detached Entity still
> have a "live"
> > > > StateManagerImpl
> > > >
> > >
> --------------------------------------------------------------------
> > > --
> > > > --------------
> > > >
> > > > Key: OPENJPA-422
> > > > URL:
> > > https://issues.apache.org/jira/browse/OPENJPA-422
> > > > Project: OpenJPA
> > > > Issue Type: Bug
> > > > Components: kernel
> > > > Affects Versions: 1.0.0
> > > > Reporter: Kevin Sutter
> > > > Assignee: Kevin Sutter
> > > > Fix For: 1.0.1, 1.1.0
> > > >
> > > >
> > > > When Entities are detached, normally the StateManagerImpl
> > > instance associated with this Entity is replaced with a
> > > DetachedStateManager. Not only with the Entity itself, but also
> > > with the proxied attributes (Date, Calendar, Collection, and Map
> > > types). But, somehow the Calendar object type was
> forgotten in the
> > > code for this processing. So, the Calendar proxy type
> was left with
> > > a "live" StateManagerImpl instance.
> > > If the owning Broker (EntityManager) for this Entity was closed,
> > > then the use of this "live" StateManagerImpl would end up with an
> > > IllegalStateException. And, even if the owning Broker
> > > (EntityManager) was still open, this "live"
> > > StateManagerImpl should not have been tracking the state
> since the
> > > enclosing Entity was detached.
> > > > A simple one-line update to
> > > DetachManager$DetachFieldManager.reproxy() method will
> now process
> > > the Calendar proxies as well as the other proxies it was already
> > > doing.
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > You can reply to this email to add a comment to the issue online.
> > >
> > >
> >
> >
>
Re: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Kevin Sutter <kw...@gmail.com>.
Evan,
On 10/28/07, Evan Ireland <ei...@sybase.com> wrote:
>
> Since you appear to be familiar with the proxying stuff, I
> wonder if you can say, for persistent attributes of type
> "byte[]" which cannot be proxied, but are mutable,
> how does OpenJPA handle that case?
As one big blob of data... :-) If you modify the individual byte array
contents, then you will have to re-set the array into your persistence field
in order for the change to be detected.
OpenJPA also provides the ability to define a customized type plugin which
might allow you to define and detect a byte[] modification, but I'm not
totally familiar with this aspect to know if it would help your situation or
not.
Kevin
> -----Original Message-----
> > From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> > Sent: Sunday, 28 October 2007 9:22 a.m.
> > To: dev@openjpa.apache.org
> > Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> > contained in a detached Entity still have a "live" StateManagerImpl
> >
> >
> > [
> > https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> > assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Kevin Sutter resolved OPENJPA-422.
> > ----------------------------------
> >
> > Resolution: Fixed
> >
> > Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> >
> > > Calendar objects contained in a detached Entity still have a "live"
> > > StateManagerImpl
> > >
> > ----------------------------------------------------------------------
> > > --------------
> > >
> > > Key: OPENJPA-422
> > > URL:
> > https://issues.apache.org/jira/browse/OPENJPA-422
> > > Project: OpenJPA
> > > Issue Type: Bug
> > > Components: kernel
> > > Affects Versions: 1.0.0
> > > Reporter: Kevin Sutter
> > > Assignee: Kevin Sutter
> > > Fix For: 1.0.1, 1.1.0
> > >
> > >
> > > When Entities are detached, normally the StateManagerImpl
> > instance associated with this Entity is replaced with a
> > DetachedStateManager. Not only with the Entity itself, but
> > also with the proxied attributes (Date, Calendar, Collection,
> > and Map types). But, somehow the Calendar object type was
> > forgotten in the code for this processing. So, the Calendar
> > proxy type was left with a "live" StateManagerImpl instance.
> > If the owning Broker (EntityManager) for this Entity was
> > closed, then the use of this "live" StateManagerImpl would
> > end up with an IllegalStateException. And, even if the
> > owning Broker (EntityManager) was still open, this "live"
> > StateManagerImpl should not have been tracking the state
> > since the enclosing Entity was detached.
> > > A simple one-line update to
> > DetachManager$DetachFieldManager.reproxy() method will now
> > process the Calendar proxies as well as the other proxies it
> > was already doing.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
>
RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Posted by Evan Ireland <ei...@sybase.com>.
Kevin,
Since you appear to be familiar with the proxying stuff, I
wonder if you can say, for persistent attributes of type
"byte[]" which cannot be proxied, but are mutable,
how does OpenJPA handle that case?
> -----Original Message-----
> From: Kevin Sutter (JIRA) [mailto:jira@apache.org]
> Sent: Sunday, 28 October 2007 9:22 a.m.
> To: dev@openjpa.apache.org
> Subject: [jira] Resolved: (OPENJPA-422) Calendar objects
> contained in a detached Entity still have a "live" StateManagerImpl
>
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl
> assian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Kevin Sutter resolved OPENJPA-422.
> ----------------------------------
>
> Resolution: Fixed
>
> Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
>
> > Calendar objects contained in a detached Entity still have a "live"
> > StateManagerImpl
> >
> ----------------------------------------------------------------------
> > --------------
> >
> > Key: OPENJPA-422
> > URL:
> https://issues.apache.org/jira/browse/OPENJPA-422
> > Project: OpenJPA
> > Issue Type: Bug
> > Components: kernel
> > Affects Versions: 1.0.0
> > Reporter: Kevin Sutter
> > Assignee: Kevin Sutter
> > Fix For: 1.0.1, 1.1.0
> >
> >
> > When Entities are detached, normally the StateManagerImpl
> instance associated with this Entity is replaced with a
> DetachedStateManager. Not only with the Entity itself, but
> also with the proxied attributes (Date, Calendar, Collection,
> and Map types). But, somehow the Calendar object type was
> forgotten in the code for this processing. So, the Calendar
> proxy type was left with a "live" StateManagerImpl instance.
> If the owning Broker (EntityManager) for this Entity was
> closed, then the use of this "live" StateManagerImpl would
> end up with an IllegalStateException. And, even if the
> owning Broker (EntityManager) was still open, this "live"
> StateManagerImpl should not have been tracking the state
> since the enclosing Entity was detached.
> > A simple one-line update to
> DetachManager$DetachFieldManager.reproxy() method will now
> process the Calendar proxies as well as the other proxies it
> was already doing.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Resolved: (OPENJPA-422) Calendar objects contained in a
detached Entity still have a "live" StateManagerImpl
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Sutter resolved OPENJPA-422.
----------------------------------
Resolution: Fixed
Resolved for 1.0.1 and 1.1.0 via svn revision 589207.
> Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
> ------------------------------------------------------------------------------------
>
> Key: OPENJPA-422
> URL: https://issues.apache.org/jira/browse/OPENJPA-422
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
>
> When Entities are detached, normally the StateManagerImpl instance associated with this Entity is replaced with a DetachedStateManager. Not only with the Entity itself, but also with the proxied attributes (Date, Calendar, Collection, and Map types). But, somehow the Calendar object type was forgotten in the code for this processing. So, the Calendar proxy type was left with a "live" StateManagerImpl instance. If the owning Broker (EntityManager) for this Entity was closed, then the use of this "live" StateManagerImpl would end up with an IllegalStateException. And, even if the owning Broker (EntityManager) was still open, this "live" StateManagerImpl should not have been tracking the state since the enclosing Entity was detached.
> A simple one-line update to DetachManager$DetachFieldManager.reproxy() method will now process the Calendar proxies as well as the other proxies it was already doing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.