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
AbstractPageManager
DelegatingPageManager
PageImporter
PageManagerUtils
PageManagerSecurityUtils
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
different?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
