hi marian
This sounds like a good (i.e. compatible) solution. After poking around in
the WebDAV servlet code, I've figured out that the servlet uses a
ResourceFactory to create new DavResource instances, none of which are
AclResources (obviously).
no so obvious :) the actual reason is, that JSR 170 didn't
provide any API that would allow to make the existing
DavResource implementations an AclResource. Nor did jackrabbit
at that point contain any real-life security impl that would
allow to expose any access control related properties....
i don't promise you anything.
but we will for sure need to incorporate the JCR 2.0 features
to the remoting over webdav... sooner or (realistic) later.
if you can contribute any kind of patches that would
definitely help speeding up that process.
The best way to get AclResources seems to be
creating a decorator adding the ACL bits fo the resources created by the
original ResourceFactoryImpl (or perhaps several decorators, depending on
which types of DavResource classes are actually expected by the servlet).
The part I haven't figured out yet is how to specify my own ResourceFactory
- the servlet has a setter method, but that never gets called (resulting in
it creating a new default instance the first time the factory is requested),
and I can't find anything in the config files, either.
you would have to call the setter.
e.g. The JcrRemotingServlet extends from the initial jcr server
and needs it's own locator factory -> it calls the
setLocatorFactory method during initalization.
the same would apply if it used a custom resource factory.
I'm developing this on Tomcat (for now).
that shouldn't make a difference, should it?
regards
angela
