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 -- -----------------------------------------< [EMAIL PROTECTED] >--- 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 >---
