[ http://issues.apache.org/jira/browse/JCR-318?page=comments#action_12366685 ]
Mark Slater commented on JCR-318: --------------------------------- And that brings us back to the statement in the docs that says: > Limitations: the application should not be redeployed during the same JVM > process to avoid > creating duplicate Jackrabbit instances with the same configuration. In case > you want to redeploy > your application be sure to shutdown the repository when your application is > undeployed. It can > be done by calling RepositoryImpl.shutdown() (e.g. in the destroy() method of > a servlet). --- from http://incubator.apache.org/jackrabbit/doc/deploy/howto-model1.html Lets say there's a web app that configured and accessed its private repository with JNDI using Tomcat's Context approach (i.e. the Reference is only in the web app's Context). A new version of the .war is dropped in and Tomcat redeploys the web app. If the repository was not shut down prior to the redeployment, is it possible for the repository to become corrupted, assuming the new web app also uses JNDI to access the repository? If the repository can't become corrupted in that situation, I think the docs need to be changed to avoid confusion... everything else on that page talks about a JNDI referenced repository. If the repository can become corrupted in that situation, then the docs are correct and RegistryHelper. unregisterRepository() should be called. Which leads to the problems (NamingException and duplicate configuration in JNDI and source code) I reported earlier when the web app tries to use RegistryHelper.registerRepository(). > RepositoryHelper.unregisterRepository() does not allow the repository to be > automatically restarted. > ---------------------------------------------------------------------------------------------------- > > Key: JCR-318 > URL: http://issues.apache.org/jira/browse/JCR-318 > Project: Jackrabbit > Type: Bug > Components: core > Versions: 0.9 > Environment: Tomcat 5.5.x, JNDI > Reporter: Mark Slater > Assignee: Stefan Guggisberg > Priority: Minor > Fix For: 1.0 > > Using JNDI to create a model 1 (embedded) repository as suggested in the > documentation > (http://incubator.apache.org/jackrabbit/doc/deploy/howto-model1.html) returns > a BindableRepository instance to the web app. The same documentation page > strongly recommends the webapp calls RepositoryImpl.shutdown() in the > servlet's destroy() method. However, since BindableRepository is restricted > to its package, there is no way for the webapp to access the RepositoryImpl. > The RepositoryHelper class provides a unregisterRepository() method which can > perform the shutdown. Unfortunately, the method does not allow the repository > to be restarted later on, forcing a full restart of Tomcat. The exception > thrown when trying to access a repository shut down in this manner in a > re-deployed webapp is: > java.lang.IllegalStateException: repository instance has been shut down > > org.apache.jackrabbit.core.RepositoryImpl.sanityCheck(RepositoryImpl.java:481) > > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1005) > > org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1080) > > org.apache.jackrabbit.core.jndi.BindableRepository.login(BindableRepository.java:174) > > org.apache.jackrabbit.deployment_test.JackrabbitTest.testRepository(JackrabbitTest.java:212) > > org.apache.jackrabbit.deployment_test.JackrabbitTest.doGet(JackrabbitTest.java:80) > javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > It may be useful to merge the transient capabilities of TransientRepository > into BindableRepository, perhaps making it a factory configuration option. I > imagine there's a performance hit to opening a repository, in a shared > deployment environment, where the lifecycle is controlled by the application > server, it would probably be best to not have the repository be transient. -- 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
