Hi, I think we agree that we disagree.
For Jukka Jackrabbit is a server, and the embedded use case (Model 1) use case is completely unimportant. For me and Alexander, the embedded use case (Model 1) is important. Not only because of performance, also because of ease-of-use. > Model 2 and 3 clients should not be able shutdown the repository, > as the repository lifecycle is managed by the server. Removing shutdown from the API will not solve this problem as everybody can still call the method. A possible solution is that only the very first session may call shutdown. Let's say there is JackrabbitRepository.shutdown(Session adminSession). When the repository is created the server (the entity that manages the repository) opens a special 'admin session' and keeps it. An application does not have access to it, only the server. If an application calls shutdown with another session (or null) an exception is thrown. The server can still force a shutdown if required. That's just an idea and can still be improved. > As a new Jackrabbit user these complicated ways to create and shutdown > a repository are really annonying, because this is always the *first code* > you will have to write to get it running in your application! So there should > be lots of effort to make it as simple as possible! I fully agree. I don't see how making things harder helps. > And since all model 1 applications in any case have a direct > Jackrabbit dependency, I don't see why we couldn't expect > them to use the direct RepositoryImpl.shutdown() method. Because RepositoryImpl is a class and not an interface. A) C) D) and E). Again A-E for reference: A) programming against interfaces B) The "security" argument is invalid C) How about Javadocs? D) How about other implementations (RMI, CRX)? E) JCRLog is impossible. > Why not use TransientRepository? That's probably the best solution so far. I'm not sure if that works however. Some problems (which may be solvable): - It cannot be used for remote repositories (can it?) - The repository is closed (shut down) if the first login fails, unlike other repositories - It doesn't solve the Javadoc problem (the class has public methods that should not be called) - It's still a class not an interface - No way to force shutdown (unlike with JackrabbitSession.shutdown(Session adminSession)) > why would JCRLog need to cover shutdown? You can't use JCRLog because ((RepositoryImpl)rep).shutdown() throws a ClassCastException. Even if you could solve this somehow, another problem remains. The JCRLog should log all method calls that affect Jackrabbit. By re-playing the log file a repository should be in the same state as before. If shutdown is not logged, you can't do that. Example: an application could call shutdown too early or not at all. Replaying the log file would result in another state, and you wouldn't see the problem. The log file may contain multiple runs of an application (multiple open-close / start-stop). > It's probably more fruitful to debate that goal, as the way we expose > the shutdown mechanism is highly dependent on the expected deployment > model. In my view Model 1 usage is important. Ease-of-use is important (sample apps, Javadoc, wiki,...), and there are technical reasons why shutdown should be part of an interface. For me, Model 2 and 3 are variations of Model 1. In Model 1, the client application starts and stops the repository, while in Model 2 and 3 the 'server' starts and stops it. There is even a Model 4: Mixed Mode. In that case, the application starts the repository and uses it in embedded mode, plus it starts a server so that other processes can connect to it remotely. The main advantages of Model 4 are: high performance for the embedded sessions, while providing remote access. This model is what Alexander is proposing in "simple Repository start interface". > sling/jcrapp This sounds like the 'server' model. My concern is that is internally uses Jackrabbit specific classes directly. P.S. Maybe you want to tweak the name a bit... Somehow it reminds me of Crap4J (http://www.crap4j.org/). Sorry, just joking. Regards, Thomas
