you are completely right about mentioning this 'mess'. we wanted to
contribute the stuff as soon possible, and we did not want to create a
zillion of artifacts. additionally, we wanted to provide a easy
deployment through a .war that contains the necessary servlets to
start a server without registering it via jca or similar.
> We already talked about the first artifact jcr-webdav which depends
> on jackrabbit impl. A jcr-helpers.jar would resolve that dependency.
correct.
> Then there is the jcr-client which contains 2 packages:
> org.apache.jackrabbit.client and
> org.apache.jackrabbit.webdav.client.methods
> In the second package there are also some dependencies that
> references the jackrabbit impl. the common package would solve them.
right.
> In the first package there is a servlet called
> RepositoryAccessServlet which also references some impl classes but
> also the RMI jar which makes the client jar dependent on the RMI one
> even if you for example want to run webdav with no RMI.
well, not quite true. it has a compile-time dependency on the rmi but
not a runtime one.
so you can use the servlet without having the jcr-rmi.jar in the classpath
> As a side
> note the jcr-rmi.jar has no depenceny on the impl and can be used as
> it :).
> So the RepositoryAccessServlet is used to lookup the repository
> either through JNDI or RMI but it also add some methods like login or
> credential lookup...IMO the servlet should not be in the client jar
> (and only located in the webapp)
..or a jackrabbit-j2ee.jar or similar
> The jcr-server also contains several servlets, the first one being
> RepositoryStartupServlet. IMO that servlet should not be there
> especially that it is responsible to instantiate the Repository like
> in the following method:
> protected Repository createRepository(InputSource is, File homedir)
> throws RepositoryException {
> RepositoryConfig config = RepositoryConfig.create(is,
> homedir.getAbsolutePath());
> return RepositoryImpl.create(config);
> }
>
> Which makes it completely dependent on jackrabbit. More over it is
> dependent of the core impl and on the RMI. Also the init parameters
> are clearly made for jackrabbit:
>
> /** initial param name for the repository config location */
> public final static String INIT_PARAM_REPOSITORY_CONFIG =
> "repository-config";
>
> /** initial param name for the repository home directory */
> public final static String INIT_PARAM_REPOSITORY_HOME =
> "repository-home";
>
> /** initial param name for the repository name */
> public final static String INIT_PARAM_REPOSITORY_NAME =
> "repository-name";
>
> /** initial param name for the rmi port */
> public final static String INIT_PARAM_RMI_PORT = "rmi-port";
>
right. this could also go into the jackrabbit-j2ee.jar
> Then you have 2 other servlets one for a simple webDAV implementation
> and one for a more complex one (btw should the 2 implementation place
> in the same artifact?). One servlet is named JCRWebdavServerServlet
> which uses the servlet located in the client (which makes the server
> dependent of the client btw...) to lookup the repository using the
> following code:
>
> Repository repository = RepositoryAccessServlet.getRepository();
>
> This should be replaced by a factory call to acquire an object that
> implement an interface that will allow to lookup the repository. The
> implementation can be defined in the servlet code to be located in
> the webapp war.
of course.
> Once again IMO only the AbstractWebdavsServlet should be in the jcr-
> server.
>
> Note that is just comments and no complains, my goal is to make it
> work with our implementation :)
>
> What do you think of that raw thoughts
so we would need:
- a commons-jcr.jar that contains helpers that just depend on jcr.
- a commons-jackrabbit.jar that contains helpers for jackrabbit,
for example the RepositoryStartup- and RepositoryAccessServlets
- define a couple of factories/interfaces primary for acquiring the repository
and providing the credentials.
what do you think?
--
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
|