jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Test question: NodeTest.testRemoveInvalidItemStateException()
Date Thu, 07 Jul 2005 09:01:42 GMT
Hi Maxim,

I agree with you that the test case is too restrictive. The test case 
should try a save and then fail if no InvalidItemStateException is thrown:


Index: NodeTest.java
===================================================================
--- NodeTest.java	(revision 209033)
+++ NodeTest.java	(working copy)
@@ -555,6 +555,7 @@
              // try to remove already deleted node with session 2
              try {
                  defaultTestNodeSession2.remove();
+                testSession.save();
                  fail("Removing a node already deleted by other session 
should throw an InvalidItemStateException!");
              } catch (InvalidItemStateException e) {
                  //ok, works as expected


WDYT?

regards
  marcel


Maxim wrote:
> Hello jackrabbit-dev.
> 
> In the org.apache.jackrabbit.test.api.NodeTest test case
> there is a test method:
> 
>     /**
>      * Removes a node using {@link javax.jcr.Node#remove()} with session 1,
>      * afterwards it tries the same with session 2. <br/><br/> This should
throw
>      * an {@link InvalidItemStateException}.
>      */
>     public void testRemoveInvalidItemStateException() throws RepositoryException {
> 
> This test requires Item.remove() method
> to throw InvalidItemStateException
> if this node was already removed from other session.
> 
> However the specification for Item.remove() method lists only the
> following exceptions explicitly (besides generic RepositoryException):
> - ReferentialIntegrityException
> - AccessDeniedException
> - ConstraintViolationException
> - VersionException
> - LockException
> 
> For Jackrabbit repository implementation it may be perfectly
> acceptable to throw InvalidItemStateException on remove()
> (as this does not violate the specification).
> 
> But this test is part of TCK, and so it essentially requires all other
> compliant implementations to behave the same way. This seems to be way
> too restrictive and is not followed from the specification.
> 
> Usual policy for most Level 2 Item and Node methods is to modify only
> pending changes state stored in the current Session, and persistent
> storage is queried and updated only on save().
> 
> Any comments will be highly appreciated.
> 
> Thank you.
> 

Mime
View raw message