Hi, Jukka, it seems that you don't understand what I mean.
> Simply by instantiating the appropriate implementation class, for > example like this: > > RepositoryManager manager = new RepositoryManagerImpl(config); That's not acceptable, as it's not JCR 2.0 API compliant. Again, the JCR API 2.0 compliant way to create a repository is: RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); Repository rep = factory.getRepository(parameters); >From here, it's possible to get the RepositoryManager (RepositoryManager, an interface, _not_ RepositoryManagerImpl, a specific class) using: [A], [B] or [C] as I wrote above. If this is a problem, why? > The server is in any case implementation-specific, No, it is not. I don't understand why the standard JCR 2.0 way can't be used. Please tell me. Why can't the 'server' / 'listener' be started when you get the repository (see above). > so using a concrete class is no problem. Again, it _is_ a problem. I repeat what I wrote at the beginning: We should use interfaces and no 'hard coded' classes. There are two reasons: 1) with interfaces, we can add 'wrappers' or 'proxies' around an implementation such as a logging layer, a virtual repository that can combine multiple repositories into one, or a remoting layer. 2) with interfaces, applications can be written in an implementation-independent way, so that the exact same code (without having to recompile) can run against many implementations. One example is a generic JCR browser tool. > Using a decorator like a logging wrapper is trivial: Don't use "trivial" or "simply", please. > RepositoryManager manager = > new LoggingRepositoryManager(new RepositoryManagerImpl(config)); This is Jackrabbit-specific. That means the logging wrapper, as well as the application, would need to know about a specific CLASS of Jackrabbit. Not an Interface, a CLASS. I think that's not acceptable. Regards, Thomas
