You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Mark Slater (JIRA)" <ji...@apache.org> on 2006/02/15 11:54:09 UTC
[jira] Created: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
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
Priority: Minor
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
[jira] Commented: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Mark Slater (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Mark Slater (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-318?page=comments#action_12366608 ]
Mark Slater commented on JCR-318:
---------------------------------
I'm still new to this, but as I understand it, the BindableRepository object is what is bound to the JNDI context, not the RepositoryImpl inside. Why not add a "restart" function to BindableRepository? It could be essentially the same as the current init() function. That's the same process that RegistryHelper.registerRepository() would trigger, but doesn't try to replace the BindableRepository object in the JNDI. Unless there's a reason not to do it that way, I'll try to code it up and submit a patch in the next few days or so.
> 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
[jira] Updated: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-318?page=all ]
Jukka Zitting updated JCR-318:
------------------------------
Fix Version: 1.0
> 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
[jira] Assigned: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-318?page=all ]
Stefan Guggisberg reassigned JCR-318:
-------------------------------------
Assign To: Stefan Guggisberg
> 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
>
> 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
[jira] Resolved: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-318?page=all ]
Stefan Guggisberg resolved JCR-318:
-----------------------------------
Resolution: Invalid
when a Repository instance has been shutdown it has been disposed
and can't be reused anymore.
if you want to 'restart' a repository you can just create a new Repository
instance, e.g. by calling RegistryHelper.registerRepository() again.
> 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
[jira] Commented: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-318?page=comments#action_12366667 ]
Stefan Guggisberg commented on JCR-318:
---------------------------------------
an application that retrieves the Repository instance through JNDI should not be able to shutdown the repository. the code that registered the Repository instance is responsible for shutting it down. the same applies for "restart".
call RegistryHelper.registerRepository() to register a new Repository instance.
call RegistryHelper.unregisterRepository() to shut down the Repository instance and remove the registry entry.
you can repeat this cycle as often as you want.
> 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
[jira] Commented: (JCR-318) RepositoryHelper.unregisterRepository()
does not allow the repository to be automatically restarted.
Posted by "Mark Slater (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-318?page=comments#action_12366590 ]
Mark Slater commented on JCR-318:
---------------------------------
There's two problems with that. First, we're talking about a repository configured through JNDI in the context of the webapp. So the parameters to registerRepository(), configFilePath and repHomeDir, would have to coded in both the application and the context... which defeats the purpose of putting them in the context in the first place.
But maybe more important, calling registerRepository() doesn't work. I modified my test app (see JCR-319) to catch the IllegalStateException thrown by trying to log into the "ownedRepository" (a JNDI configured embedded repository) and called RegistryHelper.registerRepository() with all the same parameters stored in the Context Resource tag. I tried both true and false for the overwrite parameter. In both cases, I got the following exception:
javax.naming.NamingException: Context is read only
at org.apache.naming.NamingContext.checkWritable(NamingContext.java:902)
at org.apache.naming.NamingContext.bind(NamingContext.java:830)
at org.apache.naming.NamingContext.rebind(NamingContext.java:207)
at org.apache.naming.NamingContext.rebind(NamingContext.java:222)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository(RegistryHelper.java:89)
at org.apache.jackrabbit.deployment_test.JackrabbitTest.doGet(JackrabbitTest.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:613)
> 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