Hi all
Today the Jackrabbit team checked in a WebDAV server to Subversion. This does change things quite a bit for our project.....
It would seem unwise to duplicate the work being done over at the Jackrabbit project simply because it doesn't easily support an IoC container. Having said that, I really need a WebDAV server - and whatever content repository it uses (be it JSR 170 or otherwise) - to be configurable via IoC and managed within a container. If I simply needed a standalone system (ie one I couldn't integrate with my Spring apps), I'd just deploy Apache's WebDAV module and be done with it! :-) My vision of the main benefits this project would deliver include:
- Use IoC for configuration, extension, customisation
- Use Acegi Security, as it's deployed for the rest of the app and is servlet container portable
- Integrate the content repository into other areas of the app (eg Velocity/FreeMarker template readers)
- Customise the WebDAV services (eg CalDAV extensions)
I've looked through the Jackrabbit code some more and they have a pretty comprehensive approach to most of the functional requirements. My only concern is with IoC support. Whilst it's easy enough to write a Spring FactoryBean that exposes a Repository singleton, it doesn't address the configuration using the native Jackrabbit XML file. Whilst Spring takes this approach with EH-CACHE, I'd argue a cache implementation is fairly black-box and it's unlikely you'd want to do much more than get/put cache elements and change its configuration. With a WebDAV / JCR 170 implementation you'd want to do all sorts of things like store content, search it, retrieve it, lock it, version it, manage permissions, extend it to support CalDAV and so on. Something like Jackrabbit, IMHO, would be a very good candidate for a sophisticated WebDAV / JCR 170 solution - if only we could achieve tighter IoC integration.
My proposal is for us to approach the Jackrabbit team and offer to help them implement IoC capabilities into Jackrabbit. This would not be creating a dependency on Spring. Instead it would just be moving to interface-driven design at a finer level of granularity, and moving configuration to getters/setters on implementations (as opposed to on interfaces or application-wide configuration objects parsed from XML). I've looked at trying to maintain a separate "Spring wrapper" on Jackrabbit, but these issues have prevented it from being viable.
There are pretty much four choices:
- Offer to help Jackrabbit implement an IoC-supporting design, as noted above
- Develop our own independent JSR 170 and WebDAV implementation
- Live with a FactoryBean that uses native Jackrabbit XML and "hammer a square peg into a round hole" to get customisations like non-JAAS security to work
- Don't continue with this project, if we don't consider IoC support for WebDAV and JSR 170 as high enough priority
My vote is for offering to help Jackrabbit implement an IoC-supporting design. If we can achieve that, it is of benefit to all IoC communities, not just Spring. We'd probably still continue with this project and focus on a Spring JSR 170 abstraction layer (eg wrap all those checked exceptions), and value-adding the Jackrabbit core infrastructure with Spring-specific features (eg ACL integration, nice PropertyEditors to facilitate wiring, JDBC-based repository etc).
Any thoughts?
Cheers Ben
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Acegiwebdav-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegiwebdav-developer
