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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 31 October 2007 10:00 a.m.
To: [email protected]
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:[EMAIL PROTECTED]
Sent: Wednesday, 31 October 2007 2:38 a.m.
To: [email protected]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: Sunday, 28 October 2007 9:22 a.m.
To: [email protected]
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
