Hi Andy,
This is similar to the detach listener issue. All the other listeners
are specified to be called "around" the corresponding callbacks. The
lack of text describing the listener/callback ordering is a bug in
the spec.
Here's the proposed update.
<spec>
package javax.jdo.listener;
public interface AttachLifecycleListener
extends InstanceLifecycleListener {
A12.15-13 [void preAttach(InstanceLifecycleEvent event);
}
This method is called before a detached instance is attached. The
source instance is the detached instance].
A12.15-14 [void postAttach(InstanceLifecycleEvent event);
}
This method is called after a detached instance is attached. The
source instance is the corresponding persistent instance in the
cache; the target instance is the detached instance.]
</spec>
<proposed>
package javax.jdo.listener;
public interface AttachLifecycleListener
extends InstanceLifecycleListener {
A12.15-13 [void preAttach(InstanceLifecycleEvent event);
}
This method is called before a detached instance is attached. The
source instance is the detached instance. This method is called
before the corresponding jdoPreAttach on the detached instance].
A12.15-14 [void postAttach(InstanceLifecycleEvent event);
}
This method is called after a detached instance is attached. The
source instance is the corresponding persistent instance in the
cache; the target instance is the detached instance. This method is
called after the corresponding jdoPostAttach on the persistent
instance.]
</proposed>
Thanks,
Craig
On Oct 22, 2005, at 1:07 AM, Andy Jefferson (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JDO-186?page=all ]
Andy Jefferson reassigned JDO-186:
----------------------------------
Assign To: Craig Russell (was: Andy Jefferson)
Actually was an issue in InstanceCallbacks and not
InstanceLifecycleListener. JPOX CVS now uses the objects the other
way around on the postAttach and that part of the test passes. The
issue about
[java] Sequence verification failed for PRE_ATTACH_CALLBACK;
expected: <2> actual: <0>
[java]
[java] Sequence verification failed for POST_ATTACH_LISTENER;
expected: <3> actual: <2>
remains. This seems to be down to the TCK test assuming something
about ordering. What is the issue here ?
Attach lifecycle listeners are incorrectly implemented
------------------------------------------------------
Key: JDO-186
URL: http://issues.apache.org/jira/browse/JDO-186
Project: JDO
Type: Bug
Components: tck20
Environment: JPOX
Reporter: Craig Russell
Assignee: Craig Russell
The InstanceLifecycleListenerAttach test case fails with these
errors.
[java] testAttach
(org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAt
tach)junit.framework.AssertionFailedError: Assertion A12.15-13
(TestInstanceLifecycleListener) failed:
[java] Assertion A12.15-14 (TestInstanceLifecycleListener)
failed: in postAttach, source object should be persistent.
[java] Assertion A12.15-14 (TestInstanceLifecycleListener)
failed: in postAttach, target expected
<org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAt
[EMAIL PROTECTED]>, actual <null>
[java]
[java] Sequence verification failed for PRE_ATTACH_CALLBACK;
expected: <2> actual: <0>
[java]
[java] Sequence verification failed for POST_ATTACH_LISTENER;
expected: <3> actual: <2>
[java]
[java] at
org.apache.jdo.tck.api.instancecallbacks.AbstractInstanceLifecycleLis
tener$InstanceLifecycleListenerImpl.verifyCallbacks
(AbstractInstanceLifecycleListener.java:464)
[java] at
org.apache.jdo.tck.api.instancecallbacks.InstanceLifecycleListenerAtt
ach.testAttach(InstanceLifecycleListenerAttach.java:111)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jdo.tck.JDO_Test.runBare
(JDO_Test.java:204)
[java] at org.apache.jdo.tck.util.BatchTestRunner.start
(BatchTestRunner.java:120)
[java] at org.apache.jdo.tck.util.BatchTestRunner.main
(BatchTestRunner.java:95)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
