jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Jackrabbit management API
Date Tue, 08 Sep 2009 15:46:07 GMT
Hi,

On Tue, Sep 8, 2009 at 5:00 PM, Thomas Müller<thomas.mueller@day.com> 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

Mime
View raw message