You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Peter Darton <pe...@intrinsica.co.uk> on 2005/12/07 15:20:44 UTC
FW: JCR, RMI & WebDAV - draft HOWTO
After publicly claiming that getting JCR-RMI/WebDAV working had been a
"learning experience", it was pointed out to me that I should write
about the whole thing so others (Hi John!) might skip over some of the
mistakes I made, so I'll post my innane ramblings here...
I expect a number of issues that I met will have nice explanations that
I either stupidly missed or simply weren't documented.
It would be nice if those people who know more than I do would take the
time to read through this message, and then point out the obvious
mistakes and any better ways of doing things so that others might
benefit. You never know, making it easier to get involved might bring
more people to the project as a whole...
So, the following could be considered a draft "HOWTO get JCR-RMI-WebDAV
working".
The following instructions are based on the assumption that you're using
Linux, and you've got the "svn" command-line command installed, and
you've got Tomcat running somewhere, but you don't have anything in the
way of existing installed Java development stuff.
1) Java:
You'll need a JDK. Personally, I downloaded Java 1.5.0_05 by
downloading the "Netbeans 4.1 with Java 1.5" bundle.
I installed the JDK into /opt/jdk1.5.0_05/ and Netbeans into
/opt/netbeans-4.1/
2) Maven:
Download Maven 1. Note: That's "Maven 1", not 2.
Unpack it somewhere.
(I unpacked to /opt/maven-1.0.2/)
- Easy mistake: The Maven website has moved onto Maven 2. Maven 2 is
NOT what you want. You'll have to locate the link to Maven 1 and
download that instead. You can guess what I did first time around...
3) Xalan:
Download Xalan from http://xml.apache.org/xalan-j/downloads.html
Unpack it somewhere nearby to Maven (I unpacked to /opt/xalan-j_2_7_0/)
4) JCR build using Java 1.5 workaround:
There's a bug in the maven build under Java 1.5, so you'll need to:
cd to maven's "lib/endorsed" directory
create symbolic links to (or copy) xalan.jar and serializer.jar (which
are in the xalan directory).
I did
ln -s ../../../xalan-j_2_7_0/serializer.jar
ln -s ../../../xalan-j_2_7_0/xalan.jar
3) Download & Build Jackrabbit:
cd to whereever you want a jackrabbit directory created, then do svn
co http://svn.apache.org/repos/asf/incubator/jackrabbit/trunk jackrabbit
(that'll download the jackrabbit source) cd jackrabbit/jackrabbit
export PATH=/opt/maven-1.0.2/bin:${PATH} export
JAVA_HOME=/opt/jdk1.5.0_05 maven clean jar:jar jar:install copy_deps
dist This will take some time, firstly because it'll download some
other jar files that are needed, and secondly because the unit-tests
aren't instant (you should have time to make tea/coffee).
cd ../..
4) Build jackrabbit RMI:
cd jackrabbit/contrib/jcr-rmi
maven clean dist jar:install
cd ../../..
5) Build jackrabbit WebDAV:
cd jackrabbit/contrib/jcr-server/webdav
maven clean jar jar:install dist
cd ../server
maven clean jar jar:install dist
cd ../client
maven clean jar jar:install dist
cd ../webapp
maven clean jar jar:install dist
cd ../../../..
7) Installing WebDAV on Tomcat
I'm going to assume you've already got Apache Tomcat up and running.
Big assumption, I know, but there are existing tutorials for that
(google is your friend).
I'm going to assume that Tomcat is running on your localhost on port
8080.
Goto http://localhost:8080/manager/html/list
Scroll down to the bottom to find "Select WAR file to upload" and click
"Browse". Locate, in jackrabbit/contrib/jcr-server/webapp/target, the
file "jackrabbit-server.war".
Press "deploy".
That'll fail to start properly as the build fails to include things
properly, so now scroll up to the top, find "jackrabbit-server" and
click "stop" (NOT undeploy!).
Now copy xalan.jar and serializer.jar into tomcat's subdirectory
.../webapps/jackrabbit-server/WEB_INF/lib/
Ok, we're now into "vague and undefined" territory.
I then edited
.../webapps/jackrabbit-server/WEB_INF/repository/repository.xml, found
the AccessManager section and appended (immediately after
</AccessManager>):
<LoginModule
class="org.apache.jackrabbit.core.security.SimpleLoginModule">
<param name="anonymousId" value="anonymous" /> </LoginModule>
However I'm not entirely convinced this is necessary, as the
SimpleLoginModule doesn't actually do any authentication at all anyway
(it's on the "to do" list).
Once that's done, you can go back to
http://localhost:8080/manager/html/list and press "start" on
"jackrabbit-server" again.
The servlet should start up with few complaints. Log4j will moan about
not being configured properly, but there's nothing you can do about it
(other than fixing the code itself), but there should be no exceptions.
If you do get exceptions on startup, you'll have to edit the source and
add enough System.out.println statements and printStackTrace() calls to
work out what they mean, as logging doesn't work by default and I didn't
find any method of turning it on (this is probably because the code
started by using Log4j and is transitioning to using something else, and
currently doesn't do either properly).
- Easy mistake: Beware of using the browser "back" and "forward"
buttons on the .../manager/... Tomcat pages - the browser is unlikely to
warn you about needing to re-send form data, but it will still cause
Tomcat to perform whatever operation you used to take you to that page,
which can be quite embarrasing if you started by "undeploying" an old
copy of "jackrabbit-server".
- Easy mistake#2: Undeploying the WAR will destroy the alterations
you've just made. Re-deploying will over-write any existing files
resulting in data-loss.
8) Browsing the repository using a web-browser Point your browser at
http://localhost:8080/jackrabbit-server/repository/default/
If the servlet is working, you'll get a boring page showing ".." and
nothing else, as you've not got anything in your repository (yet).
9) Browsing the repository using WebDAV
Point your WebDAV client at
http://localhost:8080/jackrabbit-server/server/default/
e.g. On "DAV Explorer":
- enter in the above URL.
- It'll prompt for a username and password - tell it anything you like
(except "anonymous").
- You're in.
- Note: Earlier versions of Jackrabbit have a bug whereby they return
an invalid HTTP header which DAV Explorer refuses to accept. See
http://issues.apache.org/jira/browse/JCR-286?page=all for details.
e.g. On MS Windows XP-SP2:
- If you're using "XP Style", open up "My Network Places" on the start
menu. If you're using "Classic Style", open up Explorer, go "up" to the
desktop and you'll find "My Network Places" there instead.
- Within "My Network Places", find "Add Network Place" and (double)
click on it.
- That'll open an "Add Network Place Wizard". Click "Next".
- That'll claim to download things from the internet (it's actually
calling home to microsoft) then it gives you a list (with only one
option). Highlight "Choose another network location" and click "Next".
- That'll ask for the "Internet or network address:". You'll need to
enter "http://localhost:8080/jackrabbit-server/server/default/". Then
click "Next"
- That'll prompt for a username and password. Enter anything at all
(it doesn't matter, as long as you don't claim to be "anonymous"). Make
sure "Remember my password" is ticked. Click ok (or press return).
- The wizard will then attempt to open the folder, so if the username
or password is wrong or the server isn't working, it'll then tell you.
If all goes well, it'll then try to open the folder and prompt you for
the username and password again (Yes, it's forgotten already, even
though you told it to remember it, so tell it again).
- That should result in a folder being displayed. You should be able
to use this to browse around.
- Note: If you didn't tell windows to remember the password, you'll
have to enter it in over and over again, instead of just twice.
Note: The WebDAV view of the repository is NOT a normal WebDAV
filestore. It's a generic JCR being exposed in all its glory, with
nodes and parameters being exposed in a rather "raw" fashion. Whilst
this lets you see everything, I wouldn't recommend it as a nice easy
user-interface, and the use of : in "filenames" _really_ upsets MS
Windows Explorer.
Note#2: You can also mount the WebDAV view using Novell NetDrive, but it
reveals the same data as seen via the Windows-XP view - not
user-friendly - and contrary to many reports, Novell NetDrive IS NOT
FREE (it's a no-cost add-on if you've already got Netware 6, hence is
downloadable from lots of universities etc for their students because
they're allowed to use it without further charge. Those of us not using
Novell should limit usage to a 90 day evaluation only)
10) Advanced usage - a remote repository I believe it's possible to get
the Tomcat servlets to publish the JCR via RMI, but I never figured out
how to do that (the config file syntax wasn't obvious to me at the time,
and the absense of documentation or logging made investigation awkward).
However, it is relatively easy to run your own "daemon" process that
runs a JCR as a separate process which then grants access to foreign
JVMs via RMI.
First, you'll need to write a "daemon" (Microsoft-indoctrinated readers
should understand that a "daemon" is what a "service" was called before
microsoft decided to use a different name) program that starts a
repository, registers it with RMI, then sits waiting for someone to tell
it to do something.
I did try attaching my own, but the list-server just said "ZIP
attachments are not accepted here", and it considers a JAR file to be a
ZIP file too. I'm willing to email copies of "JcrRmiDaemon.zip" to
anyone who asks, at least in the short term.
Then you'll need to run it with appropriate arguments, telling it all
about the security policy to use, the jaas.config file etc, and where to
put the repository files.
Once that's running (i.e. starts and then hangs waiting for orders - if
it returns you to a command-prompt, it's broken), you can then tell the
Tomcat Servlet to use that instead of its own.
Stop the tomcat servlet "jackrabbit-repository".
Edit the tomcat file .../webapps/jackrabbit-server/WEB_INF/web.xml
Delete the "R E P O S I T O R Y S T A R T U P S E R V L E T" section
in its entirity (this is the bit that says "If you already have the
repository registered in this appservers JNDI context, or if its
accessible via RMI, you do not need to use this servlet". We've got an
RMI-accessible JCR, hence we don't need this - our daemon is doing its
job now.
Scroll down to just above "W E B D A V S E R V L E T" where you'll see
"<param-name>rmi-uri</param-name>" in a section that is commented out.
Un-comment it so it's now active. Now set the <param-value> to
rmi://localhost:1099/testRep (assuming that your daemon process is
running on localhost [i.e. same PC as Tomcat], and the daemon is running
on port 1099, and the repository it is running is called testRep).
Now restart the tomcat servlet "jackrabbit-repository"
This should start up without complaint.
Now try accessing the repository via WebDAV and/or your web-browser as
described in step 8 & 9 above - these should still work, and show an
empty repository (well, WebDAV never shows it truly empty, but as empty
as it gets).
11) Really advanced stuff - writing code to hit the repository I put
together a simple command-line client (also available on request). It's
devoid of comments (sorry), but should be fairly self-explanetory (and
the code mostly follows that of
http://www-128.ibm.com/developerworks/java/library/j-jcr/ except where
the JCR-RMI interface deviates from the JCR interface).
Using this, you should be able to stuff a file into the repository and
retrieve it _either_ using the command, WebDAV, or the http-browser, and
all remotely too, so you can have a huge array of webservers running
Tomcat, all pointing at a single RMI-repository running on a separate
box.
Footnotes (aka Whinge list):
As a result of going through all of this, I'm left with a number of
questions/wishes. (i.e. this is a list of complaints that things
weren't as I expected - please don't take it personally)
Q1) Why on earth wasn't JCR designed with remote access in mind?
It would be sensible, would it not, if one could just "plug in" ANY JCR
implementation, local OR remote, and use it without having to modify
one's code - after all, that's the whole point of JCR - to allow people
to write code that can use ANY JCR without code modification.
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.
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.
Q2) Why isn't there a web-page for the jcr-contrib code?
One can browse the current JCR code code, its JavaDocs & statistics etc
on the official page.
However, there doesn't appear to be any way of seeing the equivalent
information for the jcr-contrib code, which is in turn seperated into
lots of tiny little projects, e.g. the webdav code is split into 4
projects so you can't even browse from one to the other, or back to the
core code.
Q3) Building with maven
I'm new to maven, so this might be blindingly obvious to a
maven-veteran, but when I invoke a build tool with no arguments, I
rather expect it to EITHER tell me "you need to say what you want to
build, here's a list" OR go ahead and build everything.
What I've found is that maven (at least with these projects) does
neither - it sometimes builds something useful, but usually not.
Worse (MUCH WORSE) still, if one tells it to build lots of things, it
sometimes skips steps leaving modified-code uncompiled (this is why I've
said "clean" in all my calls to maven, otherwise I often ended up with
freshly rebuilt jar files full of the old class files, and none of the
code changes I'd made. Maybe this is considered normal and reasonable
by maven-veterans, but I consider a build system failing to rebuild code
a "Bad Thing").
So, I would highly recommend that all projects get given some sensible
default targets to cope with folks (like me) who expect that typing
"maven" on its own will do what we need, instead of assuming that
everyone who downloads the code is already intimately familiar with
maven and the code's own build targets.
Note: The JCR core code does this, but it's only one build of the (far
too) many you need - the contrib code isn't in nearly as good shape.
Q4) Developing outside of maven
As you might have gathered from my choice of Java download, I'm
currently using NetBeans to develop software. Netbeans has a simple
requirement for using external libraries - it wants a JAR of the built
code, and ideally access to the Javadocs and the source code.
It would be REALLY NICE if there was a target that packaged up the
source code into a JAR file, and did the same with the JavaDocs.
I ended up writing a script file to sift through the build area, pull
out the source files, gather them into a single hierarchy and then JAR
the lot (and also turning the JavaDocs into a single JAR file as well).
This way you end up with a nice "portable" build which can be plugged
into anything - I'm sure maven is all very nice, but not everyone is
prepared to adopt an entirely new build system for every project they
get involved with.
Q5) Building everything
Why isn't there a "build everything" command? Wouldn't that be
relatively easy to do (if not, remind me why maven is used?)? Would
that not then allow the entire project to be maintained more easily?
Q6) Why no "to do" list?
It took me a long time to discover that the reason there was no
documentation covering which usernames and passwords to use, or how to
configure authentication or authorisation, was because the necessary
code to implement that functionality hadn't been written.
It would be nice if the JCR web-page had a nice obvious link to a search
on the JIRA site that listed all the blatently missing functionality,
and that the issue subjects be re-worded to make things _really_ obvious
what they mean. Personally, I don't think
http://issues.apache.org/jira/browse/JCR-153 makes it totally obvious
that THERE IS NO SECURITY AT ALL in jackrabbit (yet), and that's _after_
finding the JIRA facility...
Ok, whinges over.
I hope this of some use to people, and saves folks from some of the
"learning experience" that I went through.
If anyone wants to offer a home for the code I tried to attach
(jcrRmiDaemon - 6k, and jcrUtil - 12k), do get in touch. Same applies
if anyone wants a copy (as long their email will accept jar files).
TT4N
Peter
_____________________________________________________________________
This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com
Re: FW: JCR, RMI & WebDAV - draft HOWTO
Posted by Tobias Bocanegra <to...@day.com>.
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 >---
Re: FW: JCR, RMI & WebDAV - draft HOWTO
Posted by Stefan Guggisberg <st...@gmail.com>.
hi peter,
just some quick inline comments...
On 12/7/05, Peter Darton <pe...@intrinsica.co.uk> wrote:
> After publicly claiming that getting JCR-RMI/WebDAV working had been a
> "learning experience", it was pointed out to me that I should write
> about the whole thing so others (Hi John!) might skip over some of the
> mistakes I made, so I'll post my innane ramblings here...
:-)
>
> I expect a number of issues that I met will have nice explanations that
> I either stupidly missed or simply weren't documented.
> It would be nice if those people who know more than I do would take the
> time to read through this message, and then point out the obvious
> mistakes and any better ways of doing things so that others might
> benefit. You never know, making it easier to get involved might bring
> more people to the project as a whole...
>
>
> So, the following could be considered a draft "HOWTO get JCR-RMI-WebDAV
> working".
>
>
> The following instructions are based on the assumption that you're using
> Linux, and you've got the "svn" command-line command installed, and
> you've got Tomcat running somewhere, but you don't have anything in the
> way of existing installed Java development stuff.
>
> 1) Java:
> You'll need a JDK. Personally, I downloaded Java 1.5.0_05 by
> downloading the "Netbeans 4.1 with Java 1.5" bundle.
> I installed the JDK into /opt/jdk1.5.0_05/ and Netbeans into
> /opt/netbeans-4.1/
>
> 2) Maven:
> Download Maven 1. Note: That's "Maven 1", not 2.
> Unpack it somewhere.
> (I unpacked to /opt/maven-1.0.2/)
> - Easy mistake: The Maven website has moved onto Maven 2. Maven 2 is
> NOT what you want. You'll have to locate the link to Maven 1 and
> download that instead. You can guess what I did first time around...
>
> 3) Xalan:
> Download Xalan from http://xml.apache.org/xalan-j/downloads.html
> Unpack it somewhere nearby to Maven (I unpacked to /opt/xalan-j_2_7_0/)
>
> 4) JCR build using Java 1.5 workaround:
> There's a bug in the maven build under Java 1.5, so you'll need to:
> cd to maven's "lib/endorsed" directory
> create symbolic links to (or copy) xalan.jar and serializer.jar (which
> are in the xalan directory).
> I did
> ln -s ../../../xalan-j_2_7_0/serializer.jar
> ln -s ../../../xalan-j_2_7_0/xalan.jar
>
> 3) Download & Build Jackrabbit:
> cd to whereever you want a jackrabbit directory created, then do svn
> co http://svn.apache.org/repos/asf/incubator/jackrabbit/trunk jackrabbit
> (that'll download the jackrabbit source) cd jackrabbit/jackrabbit
> export PATH=/opt/maven-1.0.2/bin:${PATH} export
> JAVA_HOME=/opt/jdk1.5.0_05 maven clean jar:jar jar:install copy_deps
> dist This will take some time, firstly because it'll download some
> other jar files that are needed, and secondly because the unit-tests
> aren't instant (you should have time to make tea/coffee).
> cd ../..
>
> 4) Build jackrabbit RMI:
> cd jackrabbit/contrib/jcr-rmi
> maven clean dist jar:install
> cd ../../..
>
> 5) Build jackrabbit WebDAV:
> cd jackrabbit/contrib/jcr-server/webdav
> maven clean jar jar:install dist
> cd ../server
> maven clean jar jar:install dist
> cd ../client
> maven clean jar jar:install dist
> cd ../webapp
> maven clean jar jar:install dist
> cd ../../../..
>
> 7) Installing WebDAV on Tomcat
> I'm going to assume you've already got Apache Tomcat up and running.
> Big assumption, I know, but there are existing tutorials for that
> (google is your friend).
> I'm going to assume that Tomcat is running on your localhost on port
> 8080.
> Goto http://localhost:8080/manager/html/list
> Scroll down to the bottom to find "Select WAR file to upload" and click
> "Browse". Locate, in jackrabbit/contrib/jcr-server/webapp/target, the
> file "jackrabbit-server.war".
> Press "deploy".
> That'll fail to start properly as the build fails to include things
> properly, so now scroll up to the top, find "jackrabbit-server" and
> click "stop" (NOT undeploy!).
> Now copy xalan.jar and serializer.jar into tomcat's subdirectory
> .../webapps/jackrabbit-server/WEB_INF/lib/
>
> Ok, we're now into "vague and undefined" territory.
> I then edited
> .../webapps/jackrabbit-server/WEB_INF/repository/repository.xml, found
> the AccessManager section and appended (immediately after
> </AccessManager>):
>
> <LoginModule
> class="org.apache.jackrabbit.core.security.SimpleLoginModule">
> <param name="anonymousId" value="anonymous" /> </LoginModule>
>
> However I'm not entirely convinced this is necessary, as the
> SimpleLoginModule doesn't actually do any authentication at all anyway
> (it's on the "to do" list).
jackrabbit uses JAAS-based authentication. if you want to run jackrabbit
in an environment that doesn't support JAAS you can specify the LoginModule
that jackrabbit should use for authentication in the repository.xml. note that
this way jackrabbit still uses the JAAS api but ignores the JAAS environment.
SimpleLoginModule is just a dummy JAAS LoginModule. You can use any
JAAS LoginModule you want for user authentication in jackrabbit, i.e.
ldap based etc.
>
> Once that's done, you can go back to
> http://localhost:8080/manager/html/list and press "start" on
> "jackrabbit-server" again.
> The servlet should start up with few complaints. Log4j will moan about
> not being configured properly, but there's nothing you can do about it
> (other than fixing the code itself), but there should be no exceptions.
> If you do get exceptions on startup, you'll have to edit the source and
> add enough System.out.println statements and printStackTrace() calls to
> work out what they mean, as logging doesn't work by default and I didn't
> find any method of turning it on (this is probably because the code
> started by using Log4j and is transitioning to using something else, and
> currently doesn't do either properly).
>
> - Easy mistake: Beware of using the browser "back" and "forward"
> buttons on the .../manager/... Tomcat pages - the browser is unlikely to
> warn you about needing to re-send form data, but it will still cause
> Tomcat to perform whatever operation you used to take you to that page,
> which can be quite embarrasing if you started by "undeploying" an old
> copy of "jackrabbit-server".
> - Easy mistake#2: Undeploying the WAR will destroy the alterations
> you've just made. Re-deploying will over-write any existing files
> resulting in data-loss.
>
>
> 8) Browsing the repository using a web-browser Point your browser at
> http://localhost:8080/jackrabbit-server/repository/default/
> If the servlet is working, you'll get a boring page showing ".." and
> nothing else, as you've not got anything in your repository (yet).
>
> 9) Browsing the repository using WebDAV
> Point your WebDAV client at
> http://localhost:8080/jackrabbit-server/server/default/
> e.g. On "DAV Explorer":
> - enter in the above URL.
> - It'll prompt for a username and password - tell it anything you like
> (except "anonymous").
> - You're in.
> - Note: Earlier versions of Jackrabbit have a bug whereby they return
> an invalid HTTP header which DAV Explorer refuses to accept. See
> http://issues.apache.org/jira/browse/JCR-286?page=all for details.
> e.g. On MS Windows XP-SP2:
> - If you're using "XP Style", open up "My Network Places" on the start
> menu. If you're using "Classic Style", open up Explorer, go "up" to the
> desktop and you'll find "My Network Places" there instead.
> - Within "My Network Places", find "Add Network Place" and (double)
> click on it.
> - That'll open an "Add Network Place Wizard". Click "Next".
> - That'll claim to download things from the internet (it's actually
> calling home to microsoft) then it gives you a list (with only one
> option). Highlight "Choose another network location" and click "Next".
> - That'll ask for the "Internet or network address:". You'll need to
> enter "http://localhost:8080/jackrabbit-server/server/default/". Then
> click "Next"
> - That'll prompt for a username and password. Enter anything at all
> (it doesn't matter, as long as you don't claim to be "anonymous"). Make
> sure "Remember my password" is ticked. Click ok (or press return).
> - The wizard will then attempt to open the folder, so if the username
> or password is wrong or the server isn't working, it'll then tell you.
> If all goes well, it'll then try to open the folder and prompt you for
> the username and password again (Yes, it's forgotten already, even
> though you told it to remember it, so tell it again).
> - That should result in a folder being displayed. You should be able
> to use this to browse around.
> - Note: If you didn't tell windows to remember the password, you'll
> have to enter it in over and over again, instead of just twice.
>
> Note: The WebDAV view of the repository is NOT a normal WebDAV
> filestore. It's a generic JCR being exposed in all its glory, with
> nodes and parameters being exposed in a rather "raw" fashion. Whilst
> this lets you see everything, I wouldn't recommend it as a nice easy
> user-interface, and the use of : in "filenames" _really_ upsets MS
> Windows Explorer.
>
> Note#2: You can also mount the WebDAV view using Novell NetDrive, but it
> reveals the same data as seen via the Windows-XP view - not
> user-friendly - and contrary to many reports, Novell NetDrive IS NOT
> FREE (it's a no-cost add-on if you've already got Netware 6, hence is
> downloadable from lots of universities etc for their students because
> they're allowed to use it without further charge. Those of us not using
> Novell should limit usage to a 90 day evaluation only)
>
> 10) Advanced usage - a remote repository I believe it's possible to get
> the Tomcat servlets to publish the JCR via RMI, but I never figured out
> how to do that (the config file syntax wasn't obvious to me at the time,
> and the absense of documentation or logging made investigation awkward).
> However, it is relatively easy to run your own "daemon" process that
> runs a JCR as a separate process which then grants access to foreign
> JVMs via RMI.
> First, you'll need to write a "daemon" (Microsoft-indoctrinated readers
> should understand that a "daemon" is what a "service" was called before
> microsoft decided to use a different name) program that starts a
> repository, registers it with RMI, then sits waiting for someone to tell
> it to do something.
> I did try attaching my own, but the list-server just said "ZIP
> attachments are not accepted here", and it considers a JAR file to be a
> ZIP file too. I'm willing to email copies of "JcrRmiDaemon.zip" to
> anyone who asks, at least in the short term.
> Then you'll need to run it with appropriate arguments, telling it all
> about the security policy to use, the jaas.config file etc, and where to
> put the repository files.
>
> Once that's running (i.e. starts and then hangs waiting for orders - if
> it returns you to a command-prompt, it's broken), you can then tell the
> Tomcat Servlet to use that instead of its own.
> Stop the tomcat servlet "jackrabbit-repository".
> Edit the tomcat file .../webapps/jackrabbit-server/WEB_INF/web.xml
> Delete the "R E P O S I T O R Y S T A R T U P S E R V L E T" section
> in its entirity (this is the bit that says "If you already have the
> repository registered in this appservers JNDI context, or if its
> accessible via RMI, you do not need to use this servlet". We've got an
> RMI-accessible JCR, hence we don't need this - our daemon is doing its
> job now.
> Scroll down to just above "W E B D A V S E R V L E T" where you'll see
> "<param-name>rmi-uri</param-name>" in a section that is commented out.
> Un-comment it so it's now active. Now set the <param-value> to
> rmi://localhost:1099/testRep (assuming that your daemon process is
> running on localhost [i.e. same PC as Tomcat], and the daemon is running
> on port 1099, and the repository it is running is called testRep).
> Now restart the tomcat servlet "jackrabbit-repository"
> This should start up without complaint.
> Now try accessing the repository via WebDAV and/or your web-browser as
> described in step 8 & 9 above - these should still work, and show an
> empty repository (well, WebDAV never shows it truly empty, but as empty
> as it gets).
>
> 11) Really advanced stuff - writing code to hit the repository I put
> together a simple command-line client (also available on request). It's
> devoid of comments (sorry), but should be fairly self-explanetory (and
> the code mostly follows that of
> http://www-128.ibm.com/developerworks/java/library/j-jcr/ except where
> the JCR-RMI interface deviates from the JCR interface).
> Using this, you should be able to stuff a file into the repository and
> retrieve it _either_ using the command, WebDAV, or the http-browser, and
> all remotely too, so you can have a huge array of webservers running
> Tomcat, all pointing at a single RMI-repository running on a separate
> box.
>
>
> Footnotes (aka Whinge list):
> As a result of going through all of this, I'm left with a number of
> questions/wishes. (i.e. this is a list of complaints that things
> weren't as I expected - please don't take it personally)
>
> Q1) Why on earth wasn't JCR designed with remote access in mind?
> It would be sensible, would it not, if one could just "plug in" ANY JCR
> implementation, local OR remote, and use it without having to modify
> one's code - after all, that's the whole point of JCR - to allow people
> to write code that can use ANY JCR without code modification.
> 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.
> 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.
hmm, i assume there's a major misunderstanding on your side ;-)
the JCR api is by no means limited to local-access. do you consider
JDBC to be limited to local-access? i guess not ;) the fact whether
the underlying repository that a client accesses through the JCR api
resides on the local machine or on a server is absolutely transparent to
the application. just as your application doesn't care whether it is
accessing an embedded or a remote database using JDBC.
JCR-RMI is a transparent RMI bridge that exposes the JCR api on the
client but remotes the calls using RMI. your application should just use
the plain JCR api.
cheers
stefan
>
> Q2) Why isn't there a web-page for the jcr-contrib code?
> One can browse the current JCR code code, its JavaDocs & statistics etc
> on the official page.
> However, there doesn't appear to be any way of seeing the equivalent
> information for the jcr-contrib code, which is in turn seperated into
> lots of tiny little projects, e.g. the webdav code is split into 4
> projects so you can't even browse from one to the other, or back to the
> core code.
>
> Q3) Building with maven
> I'm new to maven, so this might be blindingly obvious to a
> maven-veteran, but when I invoke a build tool with no arguments, I
> rather expect it to EITHER tell me "you need to say what you want to
> build, here's a list" OR go ahead and build everything.
> What I've found is that maven (at least with these projects) does
> neither - it sometimes builds something useful, but usually not.
> Worse (MUCH WORSE) still, if one tells it to build lots of things, it
> sometimes skips steps leaving modified-code uncompiled (this is why I've
> said "clean" in all my calls to maven, otherwise I often ended up with
> freshly rebuilt jar files full of the old class files, and none of the
> code changes I'd made. Maybe this is considered normal and reasonable
> by maven-veterans, but I consider a build system failing to rebuild code
> a "Bad Thing").
> So, I would highly recommend that all projects get given some sensible
> default targets to cope with folks (like me) who expect that typing
> "maven" on its own will do what we need, instead of assuming that
> everyone who downloads the code is already intimately familiar with
> maven and the code's own build targets.
> Note: The JCR core code does this, but it's only one build of the (far
> too) many you need - the contrib code isn't in nearly as good shape.
>
> Q4) Developing outside of maven
> As you might have gathered from my choice of Java download, I'm
> currently using NetBeans to develop software. Netbeans has a simple
> requirement for using external libraries - it wants a JAR of the built
> code, and ideally access to the Javadocs and the source code.
> It would be REALLY NICE if there was a target that packaged up the
> source code into a JAR file, and did the same with the JavaDocs.
> I ended up writing a script file to sift through the build area, pull
> out the source files, gather them into a single hierarchy and then JAR
> the lot (and also turning the JavaDocs into a single JAR file as well).
> This way you end up with a nice "portable" build which can be plugged
> into anything - I'm sure maven is all very nice, but not everyone is
> prepared to adopt an entirely new build system for every project they
> get involved with.
>
> Q5) Building everything
> Why isn't there a "build everything" command? Wouldn't that be
> relatively easy to do (if not, remind me why maven is used?)? Would
> that not then allow the entire project to be maintained more easily?
>
> Q6) Why no "to do" list?
> It took me a long time to discover that the reason there was no
> documentation covering which usernames and passwords to use, or how to
> configure authentication or authorisation, was because the necessary
> code to implement that functionality hadn't been written.
> It would be nice if the JCR web-page had a nice obvious link to a search
> on the JIRA site that listed all the blatently missing functionality,
> and that the issue subjects be re-worded to make things _really_ obvious
> what they mean. Personally, I don't think
> http://issues.apache.org/jira/browse/JCR-153 makes it totally obvious
> that THERE IS NO SECURITY AT ALL in jackrabbit (yet), and that's _after_
> finding the JIRA facility...
>
>
> Ok, whinges over.
>
> I hope this of some use to people, and saves folks from some of the
> "learning experience" that I went through.
> If anyone wants to offer a home for the code I tried to attach
> (jcrRmiDaemon - 6k, and jcrUtil - 12k), do get in touch. Same applies
> if anyone wants a copy (as long their email will accept jar files).
>
> TT4N
>
> Peter
>
> _____________________________________________________________________
> This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com
>
Re: FW: JCR, RMI & WebDAV - draft HOWTO
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Peter Darton wrote:
> Footnotes (aka Whinge list):
> As a result of going through all of this, I'm left with a number of
> questions/wishes. (i.e. this is a list of complaints that things
> weren't as I expected - please don't take it personally)
Very good points! While there are good counterpoints to part of the
issues you raised (Maven use, etc.), I think many of us who are quite
accustomed to using Maven, JCR, and Jackrabbit don't even notice the
problems and questions that look like major issues to newcomers.
> Q1) Why on earth wasn't JCR designed with remote access in mind?
> [...]
> 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.
You must be using the RMI interfaces directly! Take a look at the
org.apache.jackrabbit.rmi.client package that wraps the raw RMI
interfaces into JCR-compliant adapters. The minimum survival sequence is:
String name = ...; // The RMI URL of the repository
ClientRepositoryFactory factory = new ClientRepositoryFactory();
Repository repository = factory.getRepository(name);
After that you will be able to use the remote repository throught the
normal JCR API. :-) See the o.a.j.rmi.client package javadocs for more
details.
BR,
Jukka Zitting
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Michael Aemisegger <de...@pagnolia.ch>.
Jukka Zitting wrote:
>Hi,
>
>Brian Moseley wrote:
>
>
>>is it totally inconceivable to have non-maven-generated, hand-maintained
>>docs for the contrib projects that don't get promoted?
>>
>>
>
>Of course not, the issue I was trying to raise is where the
>documentation should be located.
>
>The current JCR-RMI documentation is embedded in the javadocs (the
>package javadocs contain the end user instructions) and I kind of like
>it that way, but at the moment the easiest way to access the docs is to
>open and read the source files. :-(
>
>Perhaps I should just extract the user instructions from the javadocs
>and set them up as a page on the main Jackrabbit web site.
>
>
>
A WIKI could be a great place to store and share information. Wouldn't
the WIKI be the right place for the 'JCR, RMI & WebDAV - Howto' ?
--
Cheers,
Michael
--
Cheers,
Michael
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Brian Moseley <bc...@osafoundation.org>.
Jukka Zitting wrote:
> Of course not, the issue I was trying to raise is where the
> documentation should be located.
i know, i was just being a smartass ;)
> The current JCR-RMI documentation is embedded in the javadocs (the
> package javadocs contain the end user instructions) and I kind of like
> it that way, but at the moment the easiest way to access the docs is to
> open and read the source files. :-(
>
> Perhaps I should just extract the user instructions from the javadocs
> and set them up as a page on the main Jackrabbit web site.
sounds like a good idea. i wish i'd had something like that for bdb as well.
like probably most others, i'm impatient and just want to drop things
into my app, twiddle a config file and be off and running. i don't want
to have to read source code or javadocs, but i'm happy to refer to a
one-page checklist/HOWTO.
imo the holy grail is a series of these, one for each major contrib
project/promoted subproject, in an obvious place on the web site. or
maybe the wiki, so that users can help maintain them.
Re: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 7, 2005, at 9:54 AM, Jukka Zitting wrote:
> Brian Moseley wrote:
>> is it totally inconceivable to have non-maven-generated, hand-
>> maintained
>> docs for the contrib projects that don't get promoted?
>
> Of course not, the issue I was trying to raise is where the
> documentation should be located.
>
> The current JCR-RMI documentation is embedded in the javadocs (the
> package javadocs contain the end user instructions) and I kind of like
> it that way, but at the moment the easiest way to access the docs
> is to
> open and read the source files. :-(
>
> Perhaps I should just extract the user instructions from the javadocs
> and set them up as a page on the main Jackrabbit web site.
The best way is to figure out where under jackrabbit-site/* we want
the contrib sites to be published and then simply change each
contrib project's site:deploy target to point at that location
in the same way that we do for jackrabbit. Then I can write a
script that builds them when I build the main jackrabbit site.
....Roy
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Brian Moseley wrote:
> is it totally inconceivable to have non-maven-generated, hand-maintained
> docs for the contrib projects that don't get promoted?
Of course not, the issue I was trying to raise is where the
documentation should be located.
The current JCR-RMI documentation is embedded in the javadocs (the
package javadocs contain the end user instructions) and I kind of like
it that way, but at the moment the easiest way to access the docs is to
open and read the source files. :-(
Perhaps I should just extract the user instructions from the javadocs
and set them up as a page on the main Jackrabbit web site.
BR,
Jukka Zitting
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Brian Moseley <bc...@osafoundation.org>.
Jukka Zitting wrote:
> The problem of course is where to draw the lines between the projects.
> Should I place JCR-RMI specific documentation in the main Jackrabbit
> project or in the JCR-RMI contrib project?
>
> As noticed during the "great split", generating a small Maven site for
> each component project just leads to a rather confusing web site. A
> better alternative would be to place the documentation on the main
> project. Then we should also start considering whether the component
> sources should also be promoted to the main source tree. A mechanism
> like the current commons module setup could be used to generate more
> specific project deliverables.
is it totally inconceivable to have non-maven-generated, hand-maintained
docs for the contrib projects that don't get promoted?
i wonder if i'm the only person out there who dislikes the
mcmavenization of java software project web sites.
of course, i'm not volunteering to do the work for the contrib projects,
so this is really just an early morning gripe :)
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Brian Moseley wrote:
> i think the fact that several people have asked the same questions
> indicates that documentation on the contrib projects needs to be
> available on the jackrabbit web site and obvious to the casual browser.
Agreed.
The problem of course is where to draw the lines between the projects.
Should I place JCR-RMI specific documentation in the main Jackrabbit
project or in the JCR-RMI contrib project?
As noticed during the "great split", generating a small Maven site for
each component project just leads to a rather confusing web site. A
better alternative would be to place the documentation on the main
project. Then we should also start considering whether the component
sources should also be promoted to the main source tree. A mechanism
like the current commons module setup could be used to generate more
specific project deliverables.
BR,
Jukka Zitting
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> i thought, this would have become clear, while writing
> it down again (answering one of your mails and a mail
> sent by gary):
>
> http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03693.html
>
> http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03658.html
i think the fact that several people have asked the same questions
indicates that documentation on the contrib projects needs to be
available on the jackrabbit web site and obvious to the casual browser.
Re: FW: JCR, RMI & WebDAV - draft HOWTO *Correction*
Posted by Angela Schreiber <an...@day.com>.
hi peter
thanks for your work.
just let me add 2 corrections to your statements regarding
webdav, which is not totally precise.
i thought, this would have become clear, while writing
it down again (answering one of your mails and a mail
sent by gary):
http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03693.html
http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg03658.html
so one more time.
there are 2 ways to browse the repository using WebDAV
WebDAV 1: Repository Browsing ('filebased', 'Simple')
------------------------------------------------------------------------
- WebDAV compliance level 1,2
- by default nt:file is displayed as 'resource' any other node
is displayed as 'collection' thus a human readable way to
view the repository.
- its refered to as 'Simple' server, too. this is rather historical ;)
- the 'Normal' WebDAV view you are looking for.
this is your 8)
> http://localhost:8080/jackrabbit-server/repository/default/
Please note, that the workspace name is required to access
the root resource.
WebDAV 2: Remoting (not completed since client is missing)
------------------------------------------------------------------------
Main focus is the map JSR170 api to WebDAV, but attempt to
be compliant to
- WebDAV compliance level 1,2
- DeltaV (RFC 3253)
- Ordering (RFC 3648)
- Search
this is your 9)
> http://localhost:8080/jackrabbit-server/server/
*IMPORTANT* the url sent by Peter is not correct.
you don't need the 'workspaceName' to be part of the root.
Instead the root is a 'fake' resource that has no corresponding
item in the repository. underneath all workspaces are displayed
Please make sure, you are not adding confusion to thinks i
keep explaining.... if its not clear, feel free to ask.
As promised in the mail sent in response to one of your
questions, i will enhance the readme as soon as possible.
regards
angela