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: remove JackrabbitRepository.shutdown()
Date Thu, 17 Apr 2008 16:05:36 GMT

On Thu, Apr 17, 2008 at 10:58 AM, Thomas Mueller
<thomas.tom.mueller@gmail.com> wrote:
>  > IMHO we should be targeting server
>  >  deployments as the default model
>  What exactly do you mean with "server deployment"?

Model 2 or model 3. Basically any deployment where the client is not
in control of the repository lifecycle.

> The main problem for me is the poor performance when Jackrabbit
> is accessed remotely (over RMI). Do we have a plan to solve this?

Model 2 deployments don't have that issue.

Also, there is no technical reason why remoting couldn't be reasonably
fast, it's just that so far we haven't really focused on that. I think
that's something we need to fix, and putting more emphasis on model 3
deployments will  naturally highlight the issue and hopefully attract
related contributions.

>  >  >  remote repositories (can it?)
> >     Repository repository = new TransientRepository();
>  >     RemoteAdapterFactory factory = new ServerAdapterFactory();
>  >     RemoteRepository remote = factory.getRemoteRepository(repository);
>  >     Naming.bind("//localhost/jackrabbit", remote);
>  That's even more implementation specific code to write. It should be as easy as:
>  [...]
>  Repository rep = RepositoryFactory.open(url);
>  Like that the application does not need to be re-compiled when using
>  another connection mode or repository implementation.

Ah, I thought you were asking for a way to expose an embedded
TransientRepository through RMI. There's no need for
TransientRepository or anything from jackrabbit-core when you just
need to access a remote repository:

    ClientRepositoryFactory factory = new ClientRepositoryFactory();
    Repository repository = factory.getRepository("//localhost/jackrabbit");

It'll also be no problem to implement JSR 283 repository acquisition
support for RMI.

>  >  >  - The repository is closed (shut down) if the first login fails,
>  >  >  unlike other repositories
>  >
>  >  Is that a problem? If there's no session open, does the repository be up?
>  It's a usability issue. If the first login fails the application has
>  to re-create the TransientRepository object before it can be used
>  again.

Oh, that's certainly a bug then. A failed initial login will shutdown
the underlying repository, but the next login attempt should just
restart it under the hood. There should be no need to reconstruct the
TransientRepository instance.

>  >  >  - It doesn't solve the Javadoc problem (the class has public methods
>  >  >  that should not be called)
>  >
>  >  Why is this a problem? We can improve the documentation if needed.
>  I use autocomplete in the IDE or the Javadoc HTML documentation
>  instead of or in addition to reading the documentation. When a
>  developer is forced to use RepositoryImpl (in order to call shutdown)
>  as in
>  RepositoryImpl repo = ...
>  and then he types:
>  repo.
>  He will get the list of public methods. This list includes methods he
>  shouldn't call - shouldn't ever call - for example:
>  getItemStateCacheFactory, loggedOut, loggingOut, onEvent. The same
>  when he reads the Javadoc HTML documentation.
>  The factory method (currently RepositoryImpl.create) shouldn't be
>  declared to return RepositoryImpl. It should return
>  JackrabbitRepository. That way, a developer will only see the methods
>  he is allowed to call.

That's IMHO a minor nit. You can avoid that with:

    JackrabbitRepository repository = RepositoryImpl.create(...);

Also, an application that embeds RepositoryImpl, only needs to call
shutdown() once. Is it a big problem that when making this call you
see extra stuff in IDE autocomplete and the javadocs? We can certainly
change that if you think it's a problem.


Jukka Zitting

View raw message