jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tobias.bocane...@day.com>
Subject Re: FW: JCR, RMI & WebDAV - draft HOWTO
Date Wed, 07 Dec 2005 14:55:03 GMT
wow, thanks for this comprehensive tutorial!

just a few notes:
- you have much less hassle, if you are using jdk1.4.2 (no xalan issues)
- log4j should be initialized properly, if you are using the LoggingServlet
- the default goal in the 'jackrabbit' directory should actually build
& test it completely
- the default goal in the 'jcr-server' contrib, should actually build
all jcr-server jars
- the jcr-server consists of 2 parts, the simple server, (located
under /repository) which acts as normal WebDAV filestore and the
'server' (located under /server) which is though of a WebDAV
client-server protocol for JCR
- the repository can be bind to the RMI registry, using the respective
settings in the init-params of the RepositoryStartupServlet (web.xml).
just uncomment the RMI section

> Q1) Why on earth wasn't JCR designed with remote access in mind?
it totaly is! all functions of the API are either available per
session or per workspace or both, anticipating a client-server
archtiecture.
today, only a RMI remoting exists, but which is a 100% JCR API implementation.
i don't see at all, where you would need to rewrite your applications
(if they are 100% JCR and do not use internal jackrabbit stuff).

> However, it turns out that you can't - if you want to use a remote JCR
> (e.g. via RMI), you need to re-write all your JCR-using code because JCR
> _only_ supports local static access and as a result any remote-capable
> code is going to have a different interface.
that is not true....

> In the case of the RMI-JCR code, one gets arrays where one would expect
> Iterators, and getting data in and out of the RMI-JCR is not nearly as
> friendly as with the "raw" JCR code itself.
> Having to re-code one's application just because the JCR is on a
> different machine, or even runnining on a different JVM within the same
> machine, is rather missing the whole point of having a _single_
> interface that'll work on _any_ compatible repository.
> The requirement that one's (client) code co-habits in the same JVM (as
> the JCR code) is a serious impediment to scalability.
> Maybe there are good reasons why JCR has been limited to local-access
> only and isn't networkable, but I found this limitation to be a real
> pain.
i don't get your point....sorry...just explain why you would need to
rewrite your applications, and why RMI does not work...


> Q4) Developing outside of maven
just use:
> maven idea
or
> maven eclipse
or
> maven netbeans

to build your projects

regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message