Hi,
On Thu, Apr 17, 2008 at 10:58 AM, Thomas Mueller
<[EMAIL PROTECTED]> 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.
BR,
Jukka Zitting
