[ 
https://issues.apache.org/jira/browse/JCR-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845793#action_12845793
 ] 

angela commented on JCR-2450:
-----------------------------

> Use "mvn package" to generate the WAR file to reproduce the problem. 

thanks for the package. i generated the war file from as indicated above.
deploying in tomcat failed with NPE due to some missing libraries. so i tried 
it in our own servlet engine and
found the following:

- deploy war
- access the jackrabbit webapp 
  -> prompt for creating or specifying the repository 
  -> create new one
- as result i got a jackrabbit repository with the simple security 
configuration instead of the one you wish to have.
  -> obviously no users as the simple configuration doesn't provide any user 
management
- changed the security configuration to use the one you specified in your 
repository.xml but NOT changing
  the persistence manager implemenation.
- consequently the default users were created and i added another testuser.
  -> check: user was there
- stop the server
- restart the server
  -> all users were still present.

regarding the error messages you found:

> When I start Tomcat the first time, I see a log entry concerning the node 
> mentioned above.
> 11.03.2010 09:54:43 *DEBUG* ItemManager: invalidated item 
> cafebabe-cafe-babe-cafe-babecafebabe (ItemManager.java, line 991)
> 11.03.2010 09:54:43 *DEBUG* ItemManager: removing item 
> cafebabe-cafe-babe-cafe-babecafebabe from cache (ItemManager.java, line 935) 

this is the root node... and basically i shouldn't be a problem if it is 
removed from the cache.

so, to get this to an end:
- i don't manage to get inconsistent user content by restarting the repository.
- BUT: i didn't use the mysql persistence manager for the reasons mentioned 
above.

michael, could you
- exclude this potential error source by using a different persistence manager 
for test purpose ?

then i would like to get an idea if the user you created was ever persisted:
- can you test if the user-node is present in workspace it is expected to be?
and to exclude the possibility that something went wrong with the 2 workspace:
- can you change the configuration to use but a single workspace (specify the 
security workspace to be
  the same as the default)?









> UserManager inconsistency
> -------------------------
>
>                 Key: JCR-2450
>                 URL: https://issues.apache.org/jira/browse/JCR-2450
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, security
>    Affects Versions: 1.6.0, 2.0-beta4
>         Environment: Ubuntu 9.04 64bit, Tomcat 6.0.20, Jackrabbit 1.6 and 
> 2.0-beta4
>            Reporter: Michael Stämpfli
>            Priority: Blocker
>         Attachments: jackrabbit-test.zip
>
>
> I used the default class UserManagerImpl to add a user to my jackrabbit (1.6) 
> environment. My application can successfully login to the repository with 
> this user. As soon as I restart Tomcat, the login fails.
> I did some research and found out why. Obviously the user manager cannot find 
> the user, I registered previously, anymore. Using WebDAV I made a connection 
> to the security workspace. When I create a new user, a new node for this user 
> is created in /jcr:root/rep:security/rep:authorizables/rep:users/admin. As 
> soon as I restart Tomcat and login to the security workspace again (using 
> WebDAV), I see that the user node moved to the root node. As a consequence 
> the user cannot login to the repository because the user manager cannot find 
> the user node anymore.
> In jackrabbit 2.0-beta4 I get a similar bug and I assume, that the root cause 
> is the same as above. I log into the repository using the administrator 
> account, which is created automatically with the class UserManagerImpl. When 
> I restart Tomcat and try to login to the repository I get the error: 
> javax.jcr.ItemNotFoundException: failed to build path of 
> 55411ff4-d6c7-410a-a16e-5531e1c7afae: cafebabe-cafe-babe-cafe-babecafebabe 
> has no child entry for 55411ff4-d6c7-410a-a16e-5531e1c7afae

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to