jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: Jackrabbit management API
Date Mon, 14 Sep 2009 07:51:10 GMT
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 <jukka.zitting@gmail.com> wrote:
> 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