Hi ! Good news : I've migrated to 2.1.0 and the problem I had with move disappeared :-)
I just discovered something that looks like a strange behaviour to me and I would like to check whether it is expected or not. With jcr2spi the cache seems to be handled per session. Here is a sequence to illustrate it : 1. Create jcrSession1 2. Create jcrSession2 3. Add a node n with jcrSession1 4. ItemExists(n) with jcrSession2 returns false 5. Add a node n with jcrSession2 ==> Exception ItemExists If I swap point 2. and 3. (i.e. I create jcrSession2 after adding the node n with jcrSession1) everything works fine. Is there a reason I don't know to handle the cache at the session level and not at the repository proxy level ? And beside that, is there a way to invalidate the cache of a session (apart from closing and reopening a session) ? Thanks for your help John 2010/5/4 John Tranier <[email protected]>: > Hi Angela, > I guess it's a better option to upgrade to 2.1 for accessing the repository > in WebDav. > I will try that. > Thank you for your answers. > John > > 2010/5/4 Angela Schreiber <[email protected]> >> >> hi john >> >>> Concerning the problem 2 (move), here is an example : >>> >>> jcrSession.move( >>> fichierNode.path, >>> fichierNode.parent.path + '/' + 'newName') >>> >>> fichierNode.setProperty( JcrConstants.ELIOT_DATE_MODIFICATION, >>> Calendar.getInstance() ) >>> >>> jcrSession.save() => throws javax.jcr.PathNotFoundException: <old path> >>> >>> The problem is solved when I update the property before the move. >> >> depending on the nature of your "fichierNode" this >> could be the same as JCR-2472, which has been fixed for 2.1 >> >>> For the problem 1, I give you a short description followed by my concrete >>> code. >>> I have 2 mixin types, let's say A and B, with B that inherits A. >>> When I add the type A, and then the type B I get an exception >>> javax.jcr.nodetype.ConstraintViolationException: >>> no matching property definition found for ... >>> It works when I save the session after adding the type A. >> >>> *jcrSession.save() => Without that save it works with the Repository >>> from core, but not with a webdav connection* >> >> not sure, but the reason for this might be that in jcr2spi mixin types >> are only effective on a given node *after* save() [1]. >> in this part jcr2spi works different than jackrabbit-core since >> jcr2spi doesn't not have the ability to create autocreated items >> such as e.g. defined by mix:referenceable and mix:versionable and >> may not be able to detect conflicts arising from adding the mixin >> type. this is therefore delegated to the SPI implementation. >> >> regards >> angela >> >> [1] see section "10.10 Node Type Assignment" of the specification >> and the following quote from the javadoc of Node#addMixin: >> "Semantically, the new node type may take effect immediately, >> on dispatch or on persist." >> >> >> > >
