Hi, Jukka and me discussed the problem last week in person, and I think we found a solution.
I have posted a new patch at https://issues.apache.org/jira/browse/JCR-1865 This patch should include the Jackrabbit API additions. The implementation is still incomplete, for example org.apache.jackrabbit.core.jndi.RepositoryFactoryImpl doesn't implement JackrabbitRepositoryFactory yet. Also JackrabbitRepository still has a public shutdown() method - we should probably deprecate or remove it. Remove, because this method is insecure (anybody can call it). Regards, Thomas On Tue, Sep 8, 2009 at 5:46 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Tue, Sep 8, 2009 at 5:00 PM, Thomas Müller<[email protected]> wrote: >> Jukka, it seems that you don't understand what I mean. > > Yeah, we're probably talking past each other. :-} > >>> 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. > > This is code that we would write in a component like > jackrabbit-standalone. Are you saying that we shouldn't write > Jackrabbit-specific code in Jackrabbit? :-) > > Your own proposals all included a Class.forName(...).newInstance() > call with a Jackrabbit-specific implementation class. Similarly, if > one really wanted, the above code could be replaced with: > > RepositoryManager manager = > (RepositoryManager) Class.forName(...).newInstance(); > > ... and a change to the RepositoryManager interface to accept > configuration settings after instantiation. > > Personally I don't see the use case where something like that would be needed. > >>> The server is in any case implementation-specific, >> >> No, it is not. > > Sure it is, the code is a part of Jackrabbit. > >> 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). > > Because the RepositoryFactory API was never designed for this. The > getRepository() method is documented to "*establish a connection* to a > repository using the given parameters" (emphasis added). > > We can of course extend the API by defining > JackrabbitRepositoryFactory with the added methods like shutdown() > needed to properly control the repository lifecycle, but that's > already beyond the scope of JCR. > > The reason why I prefer an interface that does *not* extend existing > JCR interfaces is to avoid extra complexity in things like JMX > mappings. If people like that, I certainly wouldn't mind an extra > method like in your proposal [C]. > > Or our implementation class could implement both RepositoryFactory and > RepositoryManager, making the relevant part of your proposal [B] look > like this: > > 5) if (factory instanceof RepositoryManager) > ((RepositoryManager) factory).stop(); > >>> RepositoryManager manager = >>> new LoggingRepositoryManager(new RepositoryManagerImpl(config)); >> >> This is Jackrabbit-specific. > > Where's the Jackrabbit-specific part in: > > public class LoggingRepositoryManager implements RepositoryManager { > > private static final Logger log = > LoggerFactory.getLogger(LoggingRepositoryManager.class); > > private final RepositoryManager manager; > > public LoggingRepositoryManager(RepositoryManager manager) { > this.manager = manager; > } > > public boolean isRunning() { > log.debug("isRunning()"); > return manager.isRunning(); > } > > public boolean start() { > log.debug("start()"); > manager.start(); > } > > public boolean stop() { > log.debug("stop()"); > manager.stop(); > } > > } > > BR, > > Jukka Zitting >
