You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Benjamin Mestrallet <be...@exoplatform.com> on 2005/05/18 13:42:44 UTC
WebDAV exploration suites
So I continue my exploration of the webDAV module and especiallly the
3 jar artifacts
* jcr-webdav
* jcr-client
* jcr-server
and the war one:
* jackrabbit-server
We already talked about the first artifact jcr-webdav which depends
on jackrabbit impl. A jcr-helpers.jar would resolve that dependency.
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.
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. 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)
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";
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.
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
cheers
Re: WebDAV exploration suites
Posted by Felix Meschberger <Fe...@day.com>.
>so we would need:
>- a commons-jcr.jar that contains helpers that just depend on jcr.
>
>
this should include a default implementation of the Value interface.
Optimally the objects would be serializable such that the JCR-RMI might
also make use of this. A sample implementation may be found - altough
somewhat incomplete in the sens of synthactic checks of Name, Path,
Reference as well as problematic Calendar implementation.
Regards
Felix
Re: WebDAV exploration suites
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian Moseley wrote:
> Benjamin Mestrallet wrote:
>
>> Sounds good to me
>
>
> me too.
>
>> Btw, has anyone tried one of the 2 webdav implementation from a Mac
>> OS WebDAV filesystem?
>
>
> i'm using the simple server for cosmo:
> <http://wiki.osafoundation.org/bin/view/Journal/CosmoTempHome>
>
> there's an unresolved issue with using os x as a webdav client against
> cosmo:
> <https://bugzilla.osafoundation.org/show_bug.cgi?id=2854>
>
> cadaver works wonderfully for everything i've tried so far.
you might want to look at
http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg07353.html
and related mails.
Not sure if this still applies to Tiger.
--
Stefano.
Re: WebDAV exploration suites
Posted by Brian Moseley <bc...@osafoundation.org>.
Benjamin Mestrallet wrote:
> Sounds good to me
me too.
> Btw, has anyone tried one of the 2 webdav implementation from a Mac OS
> WebDAV filesystem?
i'm using the simple server for cosmo:
<http://wiki.osafoundation.org/bin/view/Journal/CosmoTempHome>
there's an unresolved issue with using os x as a webdav client against
cosmo:
<https://bugzilla.osafoundation.org/show_bug.cgi?id=2854>
cadaver works wonderfully for everything i've tried so far.
Re: WebDAV exploration suites
Posted by Brian Moseley <bc...@osafoundation.org>.
Benjamin Mestrallet wrote:
> Actually the error is before what I previously pasted
>
> 18.05.2005 21:12:26 *ERROR* [http-8080-Processor25] NodeResource: Error
> while executing export chain: java.io.IOException: No such file or
> directory (NodeResource.java, line 79)
weird, i've never seen that one (using finder or any other client).
Re: WebDAV exploration suites
Posted by Angela Schreiber <an...@day.com>.
hi
i opened a jiira issue for that problem.
thanks for appending additional information there:
http://issues.apache.org/jira/browse/JCR-123
regards
angela
Re: WebDAV exploration suites
Posted by Benjamin Mestrallet <be...@exoplatform.com>.
Actually the error is before what I previously pasted
18.05.2005 21:12:26 *ERROR* [http-8080-Processor25] NodeResource:
Error while executing export chain: java.io.IOException: No such file
or directory (NodeResource.java, line 79)
18.05.2005 21:12:26 *WARN * [http-8080-Processor25]
WebdavRequestImpl: Error while building xml document from request
body: Error on line -1: Premature end of file.
(WebdavRequestImpl.java, line 257)
On May 18, 2005, at 6:38 PM, Angela Schreiber wrote:
> Benjamin Mestrallet wrote:
>
>> Actually I asked the question because I already made the tests.
>>
>
> aha :)
>
>
>> Basically it works (anonymous connection) but when I try to see
>> jcr:system nodes I get a serious error:
>> 18.05.2005 17:43:18 *WARN * [http-8080-Processor25]
>> WebdavRequestImpl: Error while building xml document from request
>> body: Error on line -1: Premature end of file.
>> (WebdavRequestImpl.java, line 257)
>>
>
> hm.... that doesn't sound like something serious.... basically...
> this particular warning is generated whenever JDOM fails to
> parse the request body.
>
>
>> ....that breaks my entire Mac Finder :) And I have to reboot. (I
>> can say this is quite rare to reboot a Mac :) )
>>
>
> uuuuu... that's bad.
> could you provide a log of the communication and open a jira bug?
> that would be helpful. the above warning does not tell soooooo
> much about the what-is-wrong...
>
> regards angela
>
Re: WebDAV exploration suites
Posted by Angela Schreiber <an...@day.com>.
Benjamin Mestrallet wrote:
> Actually I asked the question because I already made the tests.
aha :)
> Basically it works (anonymous connection) but when I try to see
> jcr:system nodes I get a serious error:
>
> 18.05.2005 17:43:18 *WARN * [http-8080-Processor25] WebdavRequestImpl:
> Error while building xml document from request body: Error on line -1:
> Premature end of file. (WebdavRequestImpl.java, line 257)
hm.... that doesn't sound like something serious.... basically...
this particular warning is generated whenever JDOM fails to
parse the request body.
> ....that breaks my entire Mac Finder :) And I have to reboot. (I can
> say this is quite rare to reboot a Mac :) )
uuuuu... that's bad.
could you provide a log of the communication and open a jira bug?
that would be helpful. the above warning does not tell soooooo
much about the what-is-wrong...
regards angela
Re: WebDAV exploration suites
Posted by Brian Moseley <bc...@osafoundation.org>.
Benjamin Mestrallet wrote:
> Actually I asked the question because I already made the tests.
>
> Basically it works (anonymous connection) but when I try to see
> jcr:system nodes I get a serious error:
>
> 18.05.2005 17:43:18 *WARN * [http-8080-Processor25] WebdavRequestImpl:
> Error while building xml document from request body: Error on line -1:
> Premature end of file. (WebdavRequestImpl.java, line 257)
i don't think this is something unique to finder as the webdav client.
it happens to me using cadaver as well.
i also don't think it's a serious error. it seems to only happen for
requests without xml content bodies. i haven't bothered to look into it,
but i'm sure WebdavRequestImpl.getRequestDocument can be made a little
more robust so that it doesn't try to parse xml from an input stream
with no data on it.
Re: WebDAV exploration suites
Posted by Benjamin Mestrallet <be...@exoplatform.com>.
Actually I asked the question because I already made the tests.
Basically it works (anonymous connection) but when I try to see
jcr:system nodes I get a serious error:
18.05.2005 17:43:18 *WARN * [http-8080-Processor25]
WebdavRequestImpl: Error while building xml document from request
body: Error on line -1: Premature end of file.
(WebdavRequestImpl.java, line 257)
....that breaks my entire Mac Finder :) And I have to reboot. (I can
say this is quite rare to reboot a Mac :) )
At the same time I checked it was not a bug in Tiger and tried with
Slide which works perfectly.
On May 18, 2005, at 5:18 PM, Angela Schreiber wrote:
> hi benjamin
>
>
>> Btw, has anyone tried one of the 2 webdav implementation from a
>> Mac OS WebDAV filesystem?
>>
>
> we did a few basic tests on mac OS X with the predecessor of the
> 'simple' server we used to have with Day's CRX before. the
> basic functionality worked more or less with the built-in client.
> but nothing exhaustive... if you find time to do so, that would
> be great.
>
> regards
> angela
>
> btw: brian moseley provided litmus results for the simple server
> a few months ago. see http://thread.gmane.org/
> gmane.comp.apache.jackrabbit.devel/1422
> for the complete thread. i posted the list of fixes thereafter.
>
>
>
>
>
>
Re: WebDAV exploration suites
Posted by Angela Schreiber <an...@day.com>.
hi benjamin
> Btw, has anyone tried one of the 2 webdav implementation from a Mac OS
> WebDAV filesystem?
we did a few basic tests on mac OS X with the predecessor of the
'simple' server we used to have with Day's CRX before. the
basic functionality worked more or less with the built-in client.
but nothing exhaustive... if you find time to do so, that would
be great.
regards
angela
btw: brian moseley provided litmus results for the simple server
a few months ago. see
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/1422
for the complete thread. i posted the list of fixes thereafter.
Re: WebDAV exploration suites
Posted by Benjamin Mestrallet <be...@exoplatform.com>.
>
> 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?
Sounds good to me
Btw, has anyone tried one of the 2 webdav implementation from a Mac
OS WebDAV filesystem?
Re: WebDAV exploration suites
Posted by Tobias Strasser <to...@gmail.com>.
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 >---