Hi David, First of all thank you very much for your comments.
On 5/29/07, David Sean Taylor <[EMAIL PROTECTED]> wrote:
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
I'll make another JCRPageManager similar to the DB impl, I'll let you know how it goes. Thanks for the tips.
> 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...
in the prototype I'm not using castor, I made a PageManager that inherits from CastorXmlPagemanager but surprisingly CastorXmlpageManager hasn't any castor dependency. As a side note, from a user perspective I'm in favor of keeping a file system page manager, the castor implementation provides an easy way to get started with jetspeed without the need to configure a database or a jcr implementation. Besides, AFAIK there are many functionalities that can be used only by editing the psml files, e.g. editing security constraints or nesting fragments in a single page. Unlike the db or jcr, editing the psml files in the fyle system is extremely simple.
Are you making use of the Grafitto mapping work, or is this something different?
No, I make it in a class that handles the mapping based on the castor mapping file, it doesn't mean that I use castor, I just parse the castor mapping file to configure the jcr mapping, it can be reviewed later but for the moment I'm happy with it because I don't need to create a new configuration file nor add more dependencies. I use this class to parse the castor file http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/src/main/java/org/apache/jetspeed/page/document/jcr/JcrCastorMappingReader.java I use this class to convert from j2 objects to jcr nodes http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/src/main/java/org/apache/jetspeed/page/document/jcr/GenericJcrConverter.java
> 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
it was the easiest way I found to get a working jcr pagemanager, however, based on your previous comment about the DB impl I understand that I should drop this approach and build a PageManager following the DB PageManager patterns. I'll give it a try and let you know how it goes. br, edgar
> > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
