hi, i really think we need a management API/Class that controls creation and destruction of the repository. currently this is "hidden" in the RepositoryImpl. so other infrastructure applications (other than "TransientRepository") can make use of that. after all, it's not the job or the responsibility of a client (local or RMI) to shutdown the repo, but of the embedding container.
i would see something like (better names welcome): RepositoryManagement mgmgt = new JackrabbitRepositoryMgmt(); Repository mgmt.createRepository(....) .... mgmt.shutdown(Repository rep) the important thing is, that the repo can only be shutdown by the same mgmt object that created it. this ensures that no arbitrary client can destroy the repo. WDYT? -- toby On 4/28/08, Thomas Müller <[EMAIL PROTECTED]> wrote: > Hi, > > What about the other points? I repeat them here and I hope I get an > answer on them as well: > > > - Developers can write applications against an interface. > > > - Developers can use Javadocs. Also, the autocomplete feature in the > IDE would list relevant methods. > > - Access right checking can be implemented where required, improving > security. It is no longer possible to shut down a repository without > privileges. > > > > > - It is possible to write applications that work with Jackrabbit and > > > other implementations (for example Day CRX). > > > > 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. As you know, the TransientRepository > _should_ shut down the repository automatically when the last session > is closed. However this doesn't work currently, see bug > https://issues.apache.org/jira/browse/JCR-1551 - how come nobody found > out? I don't know, but one answer would be because people don't > actually use TransientRepository. What else do they use instead? Maybe > the use RepositoryImpl directly. > > > > 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. > If you use JCRLog, you can't get the RepositoryImpl object because you > get a proxy object. > > > > 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? > > > > > - JCRLog can work. When no interface is used, log files are incomplete > > > and re-running the log file fails. > > > > Does JCRLog need to cover the shutdown case? > > > Yes, of course it does. I have already explained why, but I can repeat > it here: When no interface is used, log files are incomplete and > re-running the log file fails. An application that uses JCRLog > wouldn't even compile if it uses RepositoryImpl.shutdown directly. > > > [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. > > > > IMHO it only needs to cover the JCR API, and > > potentially the extensions in jackrabbit-api. > > > Why should there be a method that is not covered by an interface in > the Jackrabbit API? > > 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? > > Regards, > > Thomas >
