Hi,
> > For Jukka the embedded use case (Model 1) is completely unimportant.
> :-) Don't put words into my mouth.
I'm sorry, I was mislead by your statement "Jackrabbit is a server not
a library".
> IMHO we should be targeting server
> deployments as the default model
What exactly do you mean with "server deployment"? The main problem
for me is the poor performance when Jackrabbit is accessed remotely
(over RMI). Do we have a plan to solve this?
> > 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("jackrabbit/transient");
or
Repository rep = RepositoryFactory.open("jackrabbit:file:~/repos/test");
or
Repository rep = RepositoryFactory.open("jackrabbit:jndi:jcr/globalRepository");
or
Repository rep = RepositoryFactory.open("jackrabbit:rmi:localhost/jackrabbit");
or
Repository rep =
RepositoryFactory.open("jackrabbit:rmi://localhost/jackrabbit");
or
Repository rep =
RepositoryFactory.open("jackrabbit:jcrlog:jackrabbit/file/~/repos/test");
or more general:
Repository rep = RepositoryFactory.open(url);
Like that the application does not need to be re-compiled when using
another connection mode or repository implementation.
> > - 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. But only when using TransientRepository, and only if the first
login fails. If the second login fails, or when not using
TransientRepository, the application must not re-create the repository
object. For a developer that's strange: it shouldn't matter what login
attempt this is and it shouldn't matter what kind of repository object
this is.
> > - 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.
Regards,
Thomas
