jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Slater (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-318) RepositoryHelper.unregisterRepository() does not allow the repository to be automatically restarted.
Date Thu, 16 Feb 2006 09:34:01 GMT
    [ 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
> ----------------------------------------------------------------------------------------------------
>          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:
For more information on JIRA, see:

View raw message