portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: jcr page manager
Date Tue, 29 May 2007 21:13:27 GMT
On May 29, 2007, at 6:25 AM, Edgar Poce wrote:

> Hello,
>  I'm working in a page manager backed by jcr called JcrPageManager.
> It is an extension of CastorXmlPersistenceManager but I'm not sure
> whether it's a good idea to extend it because
> CastorXmlPersistenceManager uses a FileCache which is unusable by a
> JCR implementation. I guess this problem can be solved by implementing
> a  PageManager which doesn't inherit from CastorXmlPageManager but I'd
> like to reuse as much code as possible, WDYT?, how should I implement
> a cache for the JCRPageManager? Any help is highly appreciated.

I really need to get a roadmap put together for the 2.2 release
A JCR Page Manager is my personal top priority on the 2.2 roadmap
So this is cool to hear you are getting a start on it
Im not going to have a whole lot of time for this now as Im busy  
getting out 2.1.1

Start by reviewing the DatabasePageManager
Yes, we have a full database backend implementation of the page manager
 From there review the page-manager component, and the shared classes  
between the file system (Castor) and DB impls


There is a lot of code you should be able to leverage there in the  
same pattern

> You'll find some implementation details bellow, in case there's
> interest I'd be happy to contribute the code to jetspeed. The code can
> be downloaded from http://code.google.com/p/jcr-portlets/
> Br,
> Edgar
> Some details about the JCRPageManager:
> 1. The mapping rules are read from the castor mapping file. A
> converter class is responsible of converting j2 objects to jcr nodes
> and viceversa based on these rules.

Im not too keen on perpetuating the usage of Castor...
Are you making use of the Grafitto mapping work, or is this something  

> 2. The PageManager is an extension of CastorXmlPageManager. The only
> difference with its superclass is that JCrPageManager takes a file
> based CastorXmlPageManager instance as a constructor argument. In case
> the site doesn't exist in jcr then JCRPageManager copies the entire
> site from the file system to the underlying JCR implementation.

Yes, I can see the advantages of extending CastorXMLPageManager too,  
as the handlers can be easily replaced

> 3. The FolderHandler given to the JcrpageManager is a JCR based  
> implementation.
> 4. The DocumentHandler given to the JcrPageManager is a JCR based
> implementation.
> 5. The repository is accessed via a JcrProvider. I implemented two
> strategies, the first uses jndi and the other instantiates jackrabbit.
> 6. The configuration is handled via Spring, I made a
> jcr-page-manager.xml as a replacement for the default configuration
> file.
> The current implementation still lacks the following features:
> 1. Cache

Regarding the FileCache, its just a Spring component, but  
unfortunately its pretty old and never was converted to the interface- 
driven model found everywhere else in Jetspeed
I think we can either replace the FileCache with a more general  
cache, or make the entire caching optional

> 2. Use the same authentication mechanism to login to the repository
> than jetspeed.
>   I guess it can be achieved by configuring jackrabbit to use the
> jetspeed jaas login module but didn't try it yet.
We need to hook into Jetspeed authentication and authenticate  
Jackrabbit at the same time...

> 3. Create j2 specific nodetypes, for the moment every node is created
> with nt:unstructured as the primary type.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message