jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: remove JackrabbitRepository.shutdown()
Date Mon, 21 Apr 2008 09:04:31 GMT

>  there is no technical reason why remoting couldn't be reasonably
>  fast

I agree. Because there is an overhead for each TCP/IP roundtrip,
remote access can never be as fast as when running Jackrabbit in the
same virtual machine, except if requests are very coarse grained.

>  That's IMHO a minor nit. You can avoid that with:
>     JackrabbitRepository repository = RepositoryImpl.create(...);

The recommended factory method should be declared to return
JackrabbitRepository (or maybe a new interface). However I'm not sure
if the recommended factory method should be RepositoryImpl.create.
It's inconsistent to get a remote repository object using "new
ClientRepositoryFactory().getRepository(String)" but a embedded
repository using "RepositoryImpl.create(RepositoryConfig)". It would
be better to have only one factory for Jackrabbit, and only one way to
get a repository object, for example:

JackrabbitRepositoryFactory.open(String url)

This 'service provider' approach is used by the following APIs:
- JDBC (java.sql.DriverManager.getConnection)
- Security (for example java.security.MessageDigest.getInstance)
- Cryptography (javax.crypto.Cipher.getInstance)
- Sound (for example javax.sound.sampled.AudioSystem.getAudioInputStream)
- Java Naming Services (javax.naming.spi.NamingManager.	getInitialContext)
- Java Image I/O (for example javax.imageio.ImageIO.read)
- New IO (java.nio.channels, java.nio.charset)
- Input Methods (java.awt.im)
- ... and various other places

When using the 'service provider' appraoch, interfaces are used. It is
not required to hardcode any implementation classes.

>  an application that embeds RepositoryImpl ... needs to call shutdown() ...
> Is it a big problem that when making this call you
>  see extra stuff in IDE autocomplete and the javadocs?

You see those 'forbidden but public' methods whenever you call
anything on RepositoryImpl. Developers shouldn't see any method that
they must not call. It's just one of many problems you get when you
force developers to use RepositoryImpl directly. It's a potential
problem an can be easily avoided by using an interface.


View raw message