You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Brian Moseley <bc...@osafoundation.org> on 2005/04/06 22:08:12 UTC
webdav configuration api
it's pretty clear that we need a way to pass configuration info between
the various webdav components. here are a few examples where config info
is needed:
1) DavResourceImpl:319 - toggle makeVersionable flag on or off
2) DavResourceImpl:333 - toggle xml import on or off
3) NodeResource:74 - toggle dir listings on or off; generate dir listing
ourself or set the node as a request attribute and forward somewhere else
what would be the right way to pass config info?
my first instinct is to create a DavConfig interface within the servlet
and pass instances of it to the other objects as they're constructed.
the config info could be specified in servlet init params or a
properties file or even other mechanisms, each managed by a DavConfig
implementation.
are there any alternate proposals? does anybody object to me working up
a patch for this?
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
ok. i gave it a try. the actual chaining really adds value to the
code. that is cool.
i also figured out how the commands can be parametrized. the digester
calls the respective bean methods, for each attribute in the xml.
cheers, tobi
On Apr 8, 2005 6:55 PM, Brian Moseley <bc...@osafoundation.org> wrote:
> Tobias Strasser wrote:
> > and how do you pass parameters to the commands?
> > or would you create a 'MakeVersionable' command?
>
> good question. that probably takes us back to the original discussion,
> which was about configuration. but if we assume we have some object that
> contains config info, then we make it part of the chain's command context.
>
> really, these two issues are orthogonal: 1) general configuration of
> server components and 2) more sophisticated resource import and export.
> an extensible import/export design would benefit from a declarative
> configuration, but this is not the same thing as setting behavioral
> parameters for the server in general.
>
> we've identified a couple cases where we need general server config.
> presumably we will also need a general way to configure individual
> import/export handlers.
>
> i'm still in favor of a simple config object loaded by the servlet that
> can be passed around between components. maybe commons config? :)
>
> > well, just another 2 libraries we depend on...
> > but i'll give it a try and maybe i discover the beauty of commons-chain :-)
>
> two libraries? oh, are you talking about digester?
>
> it may be that a commons chain implementation *is* overkill, but i don't
> think i could make that conclusion without giving it a try. but it sure
> seems to fit the need here.
>
> why do you worry about library dependencies? are you concerned about
> bloating the distribution's file size? when there is a clear benefit,
> and the alternative is writing code that has to be maintained by *this*
> project, using external libraries is often a good choice, even if it
> makes the download time a little longer. it's not like this is a client
> app that will be downloaded by tens of millions :)
>
--
------------------------------------------< 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 >---
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> and how do you pass parameters to the commands?
> or would you create a 'MakeVersionable' command?
good question. that probably takes us back to the original discussion,
which was about configuration. but if we assume we have some object that
contains config info, then we make it part of the chain's command context.
really, these two issues are orthogonal: 1) general configuration of
server components and 2) more sophisticated resource import and export.
an extensible import/export design would benefit from a declarative
configuration, but this is not the same thing as setting behavioral
parameters for the server in general.
we've identified a couple cases where we need general server config.
presumably we will also need a general way to configure individual
import/export handlers.
i'm still in favor of a simple config object loaded by the servlet that
can be passed around between components. maybe commons config? :)
> well, just another 2 libraries we depend on...
> but i'll give it a try and maybe i discover the beauty of commons-chain :-)
two libraries? oh, are you talking about digester?
it may be that a commons chain implementation *is* overkill, but i don't
think i could make that conclusion without giving it a try. but it sure
seems to fit the need here.
why do you worry about library dependencies? are you concerned about
bloating the distribution's file size? when there is a clear benefit,
and the alternative is writing code that has to be maintained by *this*
project, using external libraries is often a good choice, even if it
makes the download time a little longer. it's not like this is a client
app that will be downloaded by tens of millions :)
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
and how do you pass parameters to the commands?
or would you create a 'MakeVersionable' command?
well, just another 2 libraries we depend on...
but i'll give it a try and maybe i discover the beauty of commons-chain :-)
cheers, tobi
On Apr 8, 2005 5:35 PM, Brian Moseley <bc...@osafoundation.org> wrote:
> Tobias Strasser wrote:
>
> > well, i guess, this is a bit overkill and we would need 2 more
> > libraries. maybe its just my personal feeling. how would a typical
> > chain configuration look like?
>
> why do you think it's overkill? it implements almost exactly what you
> described in your earlier message :)
>
> the config might look something like this:
>
> <catalog name="simple-webdav">
> <chain name="import-content">
> <command id="import-file"
> className="org.apache.jackrabbit...FileImportHandler">
> <command id="import-xml"
> className="...XmlImportHandler">
> </chain>
> <chain name="export-content">
> <command id="export-file"
> className="...FileExportHandler">
> <command id="export-html-collection"
> className="...HtmlCollectionExportHandler">
> <command id="export-ics-collection"
> className="...IcsCollectionExportHandler">
> <command id="export-xml-collection"
> className="...XmlCollectionExportHandler">
> </chain>
> </catalog>
>
> concise but expressive.
>
> here's a very good article on commons chain that might help you become
> more comfortable with the idea:
>
> <http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html>
>
> surprisingly, new requirements for my project came to light yesterday
> which almost mandate a chain of responsibility approach. i need to be
> able to offer different views (xml, html, ics) of the same collection
> based on the request's content type, user agent, and possibly other
> dimensions. so i'm motivated to work on this in the short term (probably
> the next couple weeks).
>
--
------------------------------------------< 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 >---
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> well, i guess, this is a bit overkill and we would need 2 more
> libraries. maybe its just my personal feeling. how would a typical
> chain configuration look like?
why do you think it's overkill? it implements almost exactly what you
described in your earlier message :)
the config might look something like this:
<catalog name="simple-webdav">
<chain name="import-content">
<command id="import-file"
className="org.apache.jackrabbit...FileImportHandler">
<command id="import-xml"
className="...XmlImportHandler">
</chain>
<chain name="export-content">
<command id="export-file"
className="...FileExportHandler">
<command id="export-html-collection"
className="...HtmlCollectionExportHandler">
<command id="export-ics-collection"
className="...IcsCollectionExportHandler">
<command id="export-xml-collection"
className="...XmlCollectionExportHandler">
</chain>
</catalog>
concise but expressive.
here's a very good article on commons chain that might help you become
more comfortable with the idea:
<http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html>
surprisingly, new requirements for my project came to light yesterday
which almost mandate a chain of responsibility approach. i need to be
able to offer different views (xml, html, ics) of the same collection
based on the request's content type, user agent, and possibly other
dimensions. so i'm motivated to work on this in the short term (probably
the next couple weeks).
Re: webdav configuration api
Posted by Ben Pickering <be...@gmail.com>.
I assume you're talking about import/export via WebDAV only. I'd be
interested in thoughts in applying this to JCR objects in general --
the ability to define different interfaces for setting and getting
data for some objects.
Here's a Communique example. The table editor applet sets an Atom
value that is a tab/newline-separated string. It's a nightmare to
work with in code. Why not provide a TableAtom that provides
getValue(x,y) and setValue(x,y,value) that manages the conversion to
and from the complex string. You'd just cast the Atom to TableAtom to
access the new features, and the basic getString() would obviously
work just as before.
This is an easy example and it's easy to think of many more applications:
* validation
* extracting media metdata
* applying an XSLT stylesheet to XML data
* helper functions for streaming data around (great for binary streams)
and so on
It would be nice to have this implemented in the repository, but
obviously you could also make a decorating factory that could look up
what type of atom it was and wrap the basic JCR object in something
more useful.
The former approach has the benefit of being easy to use from the
client's perspective, but the latter is perhaps less invasive.
On Apr 9, 2005 5:45 PM, Tobias Strasser <to...@gmail.com> wrote:
> > I don't see how common chain would help in the import/export task :(.
> > AFAIK chain is used to run a sequence of commands but in this case only
> > one command should handle each request, there's no complex processing
> > flows. It would be useful for performing custom operations before and
> > after import/export but I don't see it as a common requirement. Am I
> > missing something?
>
> well, the webdav server needs some mechanism to create jcr-items from
> a webdav resource, and vice versa. the most generic way is to create a
> nt:file + nt:resource for a non-collection resource and a nt:folder
> for a collection. an example for a more sophisticated import is
> deserializing a XML file, thus allowing other applications to search
> and manipulate the desrialized XML in the repository. another example
> is to extract more information from a imported resource, eg: ID3 tags
> from a mp3-file, format, colorspace, dimensions from a image etc.
> we need a plugable mechanism for import/export. we thought of a chain
> of handlers, that sequencly are asked to perform the respective import
> or export operation. instead of building an own implementation of such
> a framework, commons-chain seems to be a good alternative. i made
> first steps in implementing those handlers using commons-chain, and it
> seems worth to follow this path. imo, one chaining-framework is as
> good as something else. if jakarta provides such a framework it makes
> sense to use this one.
>
> the need for configurable, plugable import/export handlers is
> undoubted. as first step, we will provide those handles, using
> commons-chain. but if it shows, that there is a better alternative, i
> think we can easily switch to something else.
>
> cheers, tobi
>
> --
> ------------------------------------------< 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 >---
>
--
Cheers,
Ben
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Brian Moseley wrote:
> Tobias Strasser wrote:
>
>> i changed the simple-server to make use of commons-chain commands, in
>> order to import/export the resources. currently, the commands are
>> looked-up in the default catalog, but this can be improved, so the
>> name of the catalog can be specified.
>> the comments in the default catalog.xml and in the javadoc of
>> o.a.j.server.io.* should explain how it works. otherwise just ask. i
>> tried to build it somewhat generic and extensible in respect to the
>> amount of commands. eg instead of having a MakeVersionableCommand
>> there is an AddMixinCommand taking an attribute 'nodeType'.
>
>
> great! i will take a look at all this very soon. thanks much for taking
> this on.
i've integrated the latest commits into my server, and i have to say
bravo! very well done. this makes it very easy for me to implement some
of the features i have coming up.
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> i changed the simple-server to make use of commons-chain commands, in
> order to import/export the resources. currently, the commands are
> looked-up in the default catalog, but this can be improved, so the
> name of the catalog can be specified.
> the comments in the default catalog.xml and in the javadoc of
> o.a.j.server.io.* should explain how it works. otherwise just ask. i
> tried to build it somewhat generic and extensible in respect to the
> amount of commands. eg instead of having a MakeVersionableCommand
> there is an AddMixinCommand taking an attribute 'nodeType'.
great! i will take a look at all this very soon. thanks much for taking
this on.
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
hi,
i changed the simple-server to make use of commons-chain commands, in
order to import/export the resources. currently, the commands are
looked-up in the default catalog, but this can be improved, so the
name of the catalog can be specified.
the comments in the default catalog.xml and in the javadoc of
o.a.j.server.io.* should explain how it works. otherwise just ask. i
tried to build it somewhat generic and extensible in respect to the
amount of commands. eg instead of having a MakeVersionableCommand
there is an AddMixinCommand taking an attribute 'nodeType'.
cheers, tobi
--
------------------------------------------< 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 >---
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> i almost finished it....
cool. looking forward to seeing it.
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
> > the need for configurable, plugable import/export handlers is
> > undoubted. as first step, we will provide those handles, using
> > commons-chain. but if it shows, that there is a better alternative, i
> > think we can easily switch to something else.
>
> so is this something you're working on in the short term? i'm going to
> need it within the next 4 weeks, so i'm happy to work on it if you have
> other things you'd rather do, but if you're fired up about it, then i'll
> spend my time elsewhere :)
i almost finished it....
--
------------------------------------------< 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 >---
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> the need for configurable, plugable import/export handlers is
> undoubted. as first step, we will provide those handles, using
> commons-chain. but if it shows, that there is a better alternative, i
> think we can easily switch to something else.
so is this something you're working on in the short term? i'm going to
need it within the next 4 weeks, so i'm happy to work on it if you have
other things you'd rather do, but if you're fired up about it, then i'll
spend my time elsewhere :)
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
> I don't see how common chain would help in the import/export task :(.
> AFAIK chain is used to run a sequence of commands but in this case only
> one command should handle each request, there's no complex processing
> flows. It would be useful for performing custom operations before and
> after import/export but I don't see it as a common requirement. Am I
> missing something?
well, the webdav server needs some mechanism to create jcr-items from
a webdav resource, and vice versa. the most generic way is to create a
nt:file + nt:resource for a non-collection resource and a nt:folder
for a collection. an example for a more sophisticated import is
deserializing a XML file, thus allowing other applications to search
and manipulate the desrialized XML in the repository. another example
is to extract more information from a imported resource, eg: ID3 tags
from a mp3-file, format, colorspace, dimensions from a image etc.
we need a plugable mechanism for import/export. we thought of a chain
of handlers, that sequencly are asked to perform the respective import
or export operation. instead of building an own implementation of such
a framework, commons-chain seems to be a good alternative. i made
first steps in implementing those handlers using commons-chain, and it
seems worth to follow this path. imo, one chaining-framework is as
good as something else. if jakarta provides such a framework it makes
sense to use this one.
the need for configurable, plugable import/export handlers is
undoubted. as first step, we will provide those handles, using
commons-chain. but if it shows, that there is a better alternative, i
think we can easily switch to something else.
cheers, tobi
--
------------------------------------------< 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 >---
Re: webdav configuration api
Posted by Edgar Poce <ed...@gmail.com>.
Hi
I don't see how common chain would help in the import/export task :(.
AFAIK chain is used to run a sequence of commands but in this case only
one command should handle each request, there's no complex processing
flows. It would be useful for performing custom operations before and
after import/export but I don't see it as a common requirement. Am I
missing something?
regards
edgar
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
> i like the idea, tho i suggest we call them import/export handlers.
sure. i do not have any preferences.
> would the jcr server benefit from this approach as well as the simple
> server?
i'm not sure about this. the jcr server protocol defines a fixed algorithm,
how the jsr170 repository has to be exposed. but maybe a JSR170ImportHandler/
JSR170ExportHandler can help to build a more generic server code base.
angela could shed more light on this...
> how about using commons-chain to provide a chain of responsibility for
> importers and exporters?
>
> this pattern, and commons-chain's implementation (including its
> xml-based configuration) are used in several projects and consequently
> are well understood by the larger developer community.
well, i guess, this is a bit overkill and we would need 2 more
libraries. maybe its just my personal feeling. how would a typical
chain configuration look like?
cheers, tobi
--
------------------------------------------< 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 >---
Re: webdav configuration api
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> i suggest to introduce some sort of resource importer and exporter
> that handle the
> specific import/export into/from jcr. for example a: PlainFileImporter
> just stores
> the file as binary property, whereas a XmlImporter can store it as
> deserialized xml.
> additional parameters can 'configure' the importers (eg: make node
> versionable, etc.)
>
> the importers and exporters are regitered and asked sequencly, if they
> want to handle
> a specific Webdav Resource/JCR Item:
>
> boolean ResourceImporter.canImport(DavResource, Node parent);
> boolean ResourceImporter.import(DavResource, InputStream in, Node parent);
>
> boolean ResourceExporter.canExport(DavResource resource, Node node);
> NodeResource ResourceExporter.export(DavResource resource, Node node);
i like the idea, tho i suggest we call them import/export handlers.
would the jcr server benefit from this approach as well as the simple
server?
how about using commons-chain to provide a chain of responsibility for
importers and exporters?
this pattern, and commons-chain's implementation (including its
xml-based configuration) are used in several projects and consequently
are well understood by the larger developer community.
Re: webdav configuration api
Posted by Tobias Strasser <to...@gmail.com>.
hi brian,
sorry for my late response....
a configuration for the server does make sense. but especially the
saving and loading
of resources could be configured more sophistically.
i suggest to introduce some sort of resource importer and exporter
that handle the
specific import/export into/from jcr. for example a: PlainFileImporter
just stores
the file as binary property, whereas a XmlImporter can store it as
deserialized xml.
additional parameters can 'configure' the importers (eg: make node
versionable, etc.)
the importers and exporters are regitered and asked sequencly, if they
want to handle
a specific Webdav Resource/JCR Item:
boolean ResourceImporter.canImport(DavResource, Node parent);
boolean ResourceImporter.import(DavResource, InputStream in, Node parent);
boolean ResourceExporter.canExport(DavResource resource, Node node);
NodeResource ResourceExporter.export(DavResource resource, Node node);
for simplicity we can add a .properties file for configuring the server:
webdav.properties
-----------------
org.apache.jackrabbit.server.importer.0 =
org.apache.jackrabbit.server.XmlImporter
org.apache.jackrabbit.server.importer.1 =
org.apache.jackrabbit.server.PlainFileImporter
org.apache.jackrabbit.server.PlainFileImporter.makeVersionable = true;
org.apache.jackrabbit.server.exporter.0 =
org.apache.jackrabbit.server.DirListingExporter
org.apache.jackrabbit.server.exporter.1 =
org.apache.jackrabbit.server.XMLExporter
and so on...
what do you think?
cheers, tobi
On Apr 6, 2005 10:08 PM, Brian Moseley <bc...@osafoundation.org> wrote:
> it's pretty clear that we need a way to pass configuration info between
> the various webdav components. here are a few examples where config info
> is needed:
>
> 1) DavResourceImpl:319 - toggle makeVersionable flag on or off
> 2) DavResourceImpl:333 - toggle xml import on or off
> 3) NodeResource:74 - toggle dir listings on or off; generate dir listing
> ourself or set the node as a request attribute and forward somewhere else
>
> what would be the right way to pass config info?
>
> my first instinct is to create a DavConfig interface within the servlet
> and pass instances of it to the other objects as they're constructed.
> the config info could be specified in servlet init params or a
> properties file or even other mechanisms, each managed by a DavConfig
> implementation.
>
> are there any alternate proposals? does anybody object to me working up
> a patch for this?
>
--
------------------------------------------< 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 >---