You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Jeff Hillier <hi...@llnl.gov> on 2009/05/27 18:27:41 UTC

Transition from Slide to Jackrabbit for file management

Hi All-

I'm picking up an older project that was developed using slide 2.1. 
The existing project is a "file management" application for our web 
servers. Basically the Slide stores were configured so users could 
use webdav (via Dreamweaver/Windows Explorer etc) to place there 
files onto the web server in a development environment. Then through 
the application could push those files through our work flow into our 
production environment. Under the covers the files are pragmatically 
moved from the development environment to the production environment 
using the slide API. So our existing system is not a true content 
management system, but instead a file management system.

We use a FileStore to store the files on the web server mounts and a 
DBStore to store the metadata about the files, which also completes 
our audit requirements (who did what, when, and who approved it)

Moving to a real content management system is not an option at this 
time, but we'd like to see if we can move to a more stable 
implementation for webdav access, Jackrabbit seems like it may be a 
good fit. We don't have many "content management" requirements, ie we 
don't need versioning, each file needs to be stored un altered on the 
file system, and as far as the application is concerned files have no 
relationship to each other. Basically we just need to move files from 
the users desktop to the server via webdav.

Can Jackrabbit be configured in more of a "file management" mode vs 
true content management? Can it be configured the same way Slide 
could, with metadata being stored in the DB (path, properties like 
create data, size, type), and the actual files stored on the file 
system in their original format? Am I better off trying to fix some 
of the issues we have in our current Slide based application rather 
than moving to jackrabbit?

Any advise/opinions would be greatly appreciated.

Thanks

Jeff 


Re: Transition from Slide to Jackrabbit for file management

Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, May 27, 2009 at 6:27 PM, Jeff Hillier <hi...@llnl.gov> wrote:
> Can Jackrabbit be configured in more of a "file management" mode vs true
> content management? Can it be configured the same way Slide could, with
> metadata being stored in the DB (path, properties like create data, size,
> type), and the actual files stored on the file system in their original
> format? Am I better off trying to fix some of the issues we have in our
> current Slide based application rather than moving to jackrabbit?

No, the only real access to a JCR is through the JCR API. Where things
are actually stored is up to the implementation and in Jackrabbit's
case depending on its configuration (PersistenceManagers and
DataStores are the important parts) - see [1]. This is technically
required, as the repository must have full control over the
persistence in order to optimize between the range of large binary
files and very fine-granular properties as it is the case with JCR.

Now it's more or less easy to mount a JCR as a filesystem using WebDAV
[2] [3], which will map nt:folder and nt:file nodes as OS folder and
files respectively. And since the JCR API is standardized, I encourage
you to write code using it, which allows you to access all the JCR
features.

[1] http://jackrabbit.apache.org/jackrabbit-configuration.html
[2] http://jackrabbit.apache.org/jackrabbit-web-application.html
(Simple Webdav Server)
[3] http://wiki.apache.org/jackrabbit/WebDAV

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Transition from Slide to Jackrabbit for file management

Posted by Michael Oliver <mo...@corenttech.com>.
Jeff,

As a committer on Slide and a user of Slide on several of my own projects, I
feel your pain.

JackRabbit has a different model and while I am sure you can duplicate the
behavior, I would guess it is going to be easier to fix Slide than to
re-write to the new model.

Ollie


On Wed, May 27, 2009 at 9:27 AM, Jeff Hillier <hi...@llnl.gov> wrote:

> Hi All-
>
> I'm picking up an older project that was developed using slide 2.1. The
> existing project is a "file management" application for our web servers.
> Basically the Slide stores were configured so users could use webdav (via
> Dreamweaver/Windows Explorer etc) to place there files onto the web server
> in a development environment. Then through the application could push those
> files through our work flow into our production environment. Under the
> covers the files are pragmatically moved from the development environment to
> the production environment using the slide API. So our existing system is
> not a true content management system, but instead a file management system.
>
> We use a FileStore to store the files on the web server mounts and a
> DBStore to store the metadata about the files, which also completes our
> audit requirements (who did what, when, and who approved it)
>
> Moving to a real content management system is not an option at this time,
> but we'd like to see if we can move to a more stable implementation for
> webdav access, Jackrabbit seems like it may be a good fit. We don't have
> many "content management" requirements, ie we don't need versioning, each
> file needs to be stored un altered on the file system, and as far as the
> application is concerned files have no relationship to each other. Basically
> we just need to move files from the users desktop to the server via webdav.
>
> Can Jackrabbit be configured in more of a "file management" mode vs true
> content management? Can it be configured the same way Slide could, with
> metadata being stored in the DB (path, properties like create data, size,
> type), and the actual files stored on the file system in their original
> format? Am I better off trying to fix some of the issues we have in our
> current Slide based application rather than moving to jackrabbit?
>
> Any advise/opinions would be greatly appreciated.
>
> Thanks
>
> Jeff
>



-- 
Michael Oliver
CTO, Corent Technology Inc.
3600 W Florida Ave, #481
Hemet, CA, 92545
ph:949-547-5700

Re: Transition from Slide to Jackrabbit for file management

Posted by Ralph Goers <ra...@dslextreme.com>.
On May 27, 2009, at 9:27 AM, Jeff Hillier wrote:

> Hi All-
>
> I'm picking up an older project that was developed using slide 2.1.  
> The existing project is a "file management" application for our web  
> servers. Basically the Slide stores were configured so users could  
> use webdav (via Dreamweaver/Windows Explorer etc) to place there  
> files onto the web server in a development environment. Then through  
> the application could push those files through our work flow into  
> our production environment. Under the covers the files are  
> pragmatically moved from the development environment to the  
> production environment using the slide API. So our existing system  
> is not a true content management system, but instead a file  
> management system.
>
> We use a FileStore to store the files on the web server mounts and a  
> DBStore to store the metadata about the files, which also completes  
> our audit requirements (who did what, when, and who approved it)
>
> Moving to a real content management system is not an option at this  
> time, but we'd like to see if we can move to a more stable  
> implementation for webdav access, Jackrabbit seems like it may be a  
> good fit. We don't have many "content management" requirements, ie  
> we don't need versioning, each file needs to be stored un altered on  
> the file system, and as far as the application is concerned files  
> have no relationship to each other. Basically we just need to move  
> files from the users desktop to the server via webdav.
>
> Can Jackrabbit be configured in more of a "file management" mode vs  
> true content management? Can it be configured the same way Slide  
> could, with metadata being stored in the DB (path, properties like  
> create data, size, type), and the actual files stored on the file  
> system in their original format? Am I better off trying to fix some  
> of the issues we have in our current Slide based application rather  
> than moving to jackrabbit?
>
> Any advise/opinions would be greatly appreciated.
>
> Thanks
>
> Jeff

I wrote a webdav provider for Commons VFS using jackrabbit's webdav  
support. Is there some reason your metadata can't be added to the file  
as webdav properties? As a matter of fact, Commons VFS already records  
the who, what and when by leveraging the DeltaV properties in addition  
to saving multiple versions of the file. The only issue I've had is  
that when I get a version history using DavExplorer files always are  
shown with a length of 0 and the author is empty (it should get it  
from the creator-displayname property).

Ralph