Hi, On Mon, Apr 28, 2008 at 3:29 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: > What about the other points? I repeat them here and I hope I get an > answer on them as well:
Your other points are good, no concerns about them. > > But how many applications really need to shutdown the repository in > > the generic case? > > All applications that call shutdown. Felix's sling/jcrapp for example. > A backup tool. A test case. All of your examples are implementation-specific. Is there a generic JCR application (i.e. one with only a dependency to jcr-1.0.jar plus potentially also jackrabbit-api), that needs JackrabbitRepository.shutdown()? > As you know, the TransientRepository _should_ shut down the repository > automatically when the last session is closed. It's a bug if it doesn't. > However this doesn't work currently, see bug > https://issues.apache.org/jira/browse/JCR-1551 The repository is closed at the last logout(). The shutdown delay is caused by a static instance variable that holds a few threads for an extended period of time after the shutdown, but that doesn't for example prevent some other process from opening the repository. > how come nobody found out? Probably because most Jackrabbit apps are long-lived, and even if the application itself is closed (for example a webapp is undeployed) the JVM is still running so the extra thread doesn't show up. > > You need to do that *only* if you embed the > > repository, in which case you already are bound to a single > > implementation. > > No, you are not bound to a single implementation. If you use Spring or > Google Guice or another factory to create the repository, you are not. Then your configuration is bound to the implementation. More notably, in such cases it's the IoC container that should be in charge of the repository lifecycle, and since the repository startup configuration is Jackrabbit-specific I don't see why the shutdown part needs to be generic. > > IMHO, if we want to make the repository more manageable, I'd opt for a > > JMX MBean. > > What's the point of adding complexity? Why exactly you like to avoid > shutdown in an interface? I have no concerns about shutdown being in an interface as such, I just object to putting it in a client-level interface. For example the idea of a separate RepositoryManager interface that covers both repository startup and shutdown is IMHO much better. > > [JCRLog] It doesn't cover repository startup. > > Of course it does. It must cover that aspect, otherwise it wouldn't be > useful. Have a look at the JCRLog implementation and the samples. Sorry, doesn't cover the startup in a repository-independent manner. Since JCRLog already has a dependency to jackrabbit-core and uses specific class references (TransientRepository) to start up a repository, why should it have a generic mechanism for shutting the repository down? > I fail to see in your mail why it is better to _not_ have an > interface. Could you please explain why you rather not have this > interface please? Again, no objections against an interface as such. My main point is that such an interface shouldn't be something that you'd cast a Repository object to. Somewhat on the same lines as Toby, how about something like this: public interface RepositoryMBean { void startRepository() throws RepositoryException; void stopRepository() throws RepositoryException; boolean isRunning(); Repository getRepository(); } A normal Java application can use this interface to control an embedded repository (but note that it still needs a dependency to the implementation class): RepositoryMBean bean = new RepositoryMBeanImpl(/* config */); bean.startRepository(); try { doSomething(bean.getRepository()); } finally { bean.stopRepository(); } Note that there is no need to worry about access control or things like whether a given repository instance was created by this management object. If a client has a reference to the management object, then it has full control over the repository. For example the doSomething() method in the above example would have no way to shutdown the repository, even by casting the repository instance to whatever interface or implementation class. And since the interface follows the JMX conventions for MBeans, it's very easy to expose the management interface to generic JMX management tools like jconsole, or even any SNMP-aware network and server monitoring tools. BR, Jukka Zitting
