Correct uses of jackrabbit

[Gary VanMatre <gv...@comcast.net>]

First, I would like to say that the jackrabbit maven build rocks. 

I'm interested in some feedback on correct uses of jackrabbit. I'm thinking about an apache shale integration. There are a couple of specific extension points that I think would be interesting to exploit. 

The shale clay plug-in allows JavaServer Faces page composition using html and xml templating, an alternative to the standard JSP Tags. I was thinking that these templates could be served up from a jackrabbit repository instead of prepackaged in a war. The other candidate for content management would be the shale remoting that allows you to serve up images and cascading style sheets bundled under the classpath. This feature was originally targeted for fully contained and self registering libraries of JSF components but I would like to explore hooking into a jackrabbit repository.


I was thinking that these features might be attractive to shops that had different release schedules for static content versus code pushes. I also wondered if this would be attractive to web application that need to be skinned differently depending on the customer.

Can principle security be used to define the content? I was thinking in terms of user A belonging with company XYZ might have a different image logo than user B in company ZYX. Or, would this better/correctly managed using different workspaces associated with each company.
Would this be a good fit for jackrabbit? Would it perform well enough to handle serving up the content of each page hit that might in turn require several html templates and images per page?  Or, is it more suited as a repository managing artifacts used to assemble a web archive?

Gary

Re: Correct uses of jackrabbit

[Marcel Reutegger <ma...@gmx.net>]

Gary VanMatre wrote:
> Can principle security be used to define the content? I was thinking in
> terms of user A belonging with company XYZ might have a different image
> logo than user B in company ZYX. Or, would this better/correctly managed
> using different workspaces associated with each company.

this is probably handled better with different workspaces and then provide 
users access to the appropriate workspace.

> Would this be a good fit for jackrabbit? Would it perform well enough to
> handle serving up the content of each page hit that might in turn
> require several html templates and images per page? Or, is it more
> suited as a repository managing artifacts used to assemble a web
> archive?

I think jackrabbit is a good fit for directly serving content to the 
application. that's basically the idea behind jsr 170 and the content 
repository api.

you also might want to look into the jackrabbit extension-framework under 
contrib to build applications that are tighter integrated into the repository.

regards
  marcel