[ 
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

Reply via email to