You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Edgar Poce <ed...@gmail.com> on 2007/05/29 15:25:42 UTC
jcr page manager
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.
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.
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.
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
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.
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
Re: jcr page manager
Posted by Edgar Poce <ed...@gmail.com>.
Hi,
On 6/17/07, Christophe Lombart <ch...@gmail.com> wrote:
> On 6/14/07, Edgar Poce <ed...@gmail.com> wrote:
> >
> > This made the jcr mapping file quite long and
> > hard to read, I guess my lack of experience with the jcr-mapping tool
> > increased this problem.
> >
>
> Hi Edgar,
>
> Nice to see that you are working on the a JCR impl for the page manager. Let
> me know if you need more infor on the jcr-mapping tools. I can try to find
> time to help.
>
Thank you very much for the offer!. in case I refactor what I made
I'll let you know.
br,
Edgar
> br,
> Christophe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by Christophe Lombart <ch...@gmail.com>.
On 6/14/07, Edgar Poce <ed...@gmail.com> wrote:
>
> This made the jcr mapping file quite long and
> hard to read, I guess my lack of experience with the jcr-mapping tool
> increased this problem.
>
Hi Edgar,
Nice to see that you are working on the a JCR impl for the page manager. Let
me know if you need more infor on the jcr-mapping tools. I can try to find
time to help.
br,
Christophe
Re: jcr page manager
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 14, 2007, at 9:02 AM, Edgar Poce wrote:
> Hi david,
>
> On 5/29/07, Edgar Poce <ed...@gmail.com> wrote:
>> 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.
>>
>
> I gave a try to the approach we discussed but I found a few problems
> to implement it. Because of that I had to keep the previous design to
> get a working version. This new version is downloadable from
> http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/. Feel
> free to include in j2 whatever you consider a valuable contribution.
>
I will need to review it, not sure if I can get it into 2.1.1 release
or not due to time constraints
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by Edgar Poce <ed...@gmail.com>.
Hi david,
On 5/29/07, Edgar Poce <ed...@gmail.com> wrote:
> 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.
>
I gave a try to the approach we discussed but I found a few problems
to implement it. Because of that I had to keep the previous design to
get a working version. This new version is downloadable from
http://jcr-portlets.googlecode.com/svn/trunk/jcr-page-manager/. Feel
free to include in j2 whatever you consider a valuable contribution.
br,
edgar
A brief description of the current implementation:
----------------------
org.apache.jetspeed.page.jcr
Provides the main JCR PageManager classes and a cache that uses the
jcr path as the key and jcr observation to remove stale entries.
org.apache.jetspeed.page.jcr.converters
Provides mapping from j2 object model to JCR by parsing the rules in
the castor mapping file
org.apache.jetspeed.page.jcr.provider
Provides utility classes to get a JCR session
Issues trying to implement a page manger without extending from the
castor implementation
----------------------
- The database object model is different from the castor object model
then I couldn't reuse the mapping I've made for my previous attempt to
get a JCR page manager.
- I tried to use the jcr-mapping project from graffito/jackrabbit but
I found that the collections from the database object model are
coupled to the ORM implementation (OJB), I mean that those collection
implementations are not standard (arraylist, vector, ...).
consequently I had to create customs converters to handle them. In
addition, I found that the security constraints in the object model
used in the database page manager are modelled with an implementation
for each object, thus I had to create a new mapping rule for each type
of security constraint. This made the jcr mapping file quite long and
hard to read, I guess my lack of experience with the jcr-mapping tool
increased this problem.
- After having failed to map the database object model to jcr I
decided to extend that object model as the castor implementation does
(org.apache.jetspeed.om.page.psml), it seems that extending the
database object model to override the db specific behaviour was the
right way to go. After several hours working in this I couldn't make
it to work correctly and I decided to go back to the previous design.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by Edgar Poce <ed...@gmail.com>.
On 5/31/07, David Sean Taylor <da...@bluesunrise.com> wrote:
>
> On May 31, 2007, at 1:08 PM, Edgar Poce wrote:
>
> >
> >> In general I would like
> >> to not introduce anymore new ways to parse XML into Jetspeed
> >> As I have stated on this list before, we have like 5 different ways
> >> to parse XML built into Jetspeed today such as Castor, Digester
> >> Would be best to settle on one approach
> >>
> >
> > I'm using DOM which is included in the jdk, but I can change to other
> > strategy if needed.
>
> Sorry, don't mean to tell you how to do things.
> DOM with the JDK is fine by me
>
Don't worry, I appreciate your feedback.I don't have any preference on
implementations details to make the JCR page manager work. Moreover,
since it's a j2 extension I'd like it to be aligned with the j2 design
choices.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by David Sean Taylor <da...@bluesunrise.com>.
On May 31, 2007, at 1:08 PM, Edgar Poce wrote:
>
>> In general I would like
>> to not introduce anymore new ways to parse XML into Jetspeed
>> As I have stated on this list before, we have like 5 different ways
>> to parse XML built into Jetspeed today such as Castor, Digester
>> Would be best to settle on one approach
>>
>
> I'm using DOM which is included in the jdk, but I can change to other
> strategy if needed.
Sorry, don't mean to tell you how to do things.
DOM with the JDK is fine by me
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by Edgar Poce <ed...@gmail.com>.
On 5/31/07, David Sean Taylor <da...@bluesunrise.com> wrote:
>
> On May 29, 2007, at 7:07 PM, Edgar Poce wrote:
>
> > Hi David,
> >
> > First of all thank you very much for your comments.
> >
> > On 5/29/07, David Sean Taylor <da...@bluesunrise.com> wrote:
> >> On May 29, 2007, at 6:25 AM, Edgar Poce wrote:
> >> 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
>
> Im in favor of keeping the file system Page Manager too
> We are already have a Page importer feature in Jetspeed (but no
> Administrative portlet yet, see JS2-716)
>
> > 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.
> >
> Security constraints can be editing in the Site Manager
> Nested fragments are supported in both customizers
> Menus and menu ordering still require XML editing, thats why I was
> hoping to get JS2-716 in for the next release, but imports can be
> done via the command line as well today
>
> >> 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
> >
> Interesting. What license is this code developed under?
It's under ASL.my intention is contribute it to j2 in case there's
interest from the community.
> I will review the code and see what I think.
I'm working on a new approach based on your comments, if you don't
have much time you can wait a few days until I have a new prototype.
I moved the previous approach to a branch
(http://jcr-portlets.googlecode.com/svn/branches/castor-jcr-page-manager/)
and I'll use the trunk to work in the new one.
> In general I would like
> to not introduce anymore new ways to parse XML into Jetspeed
> As I have stated on this list before, we have like 5 different ways
> to parse XML built into Jetspeed today such as Castor, Digester
> Would be best to settle on one approach
>
I'm using DOM which is included in the jdk, but I can change to other
strategy if needed.
br,
edgar
>
> >> > 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.
> >
> Yes, you can leverage a lot of the high level stuff for copying and
> cloning trees of PSML
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by David Sean Taylor <da...@bluesunrise.com>.
On May 29, 2007, at 7:07 PM, Edgar Poce wrote:
> Hi David,
>
> First of all thank you very much for your comments.
>
> On 5/29/07, David Sean Taylor <da...@bluesunrise.com> wrote:
>> On May 29, 2007, at 6:25 AM, Edgar Poce wrote:
>> 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
Im in favor of keeping the file system Page Manager too
We are already have a Page importer feature in Jetspeed (but no
Administrative portlet yet, see JS2-716)
> 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.
>
Security constraints can be editing in the Site Manager
Nested fragments are supported in both customizers
Menus and menu ordering still require XML editing, thats why I was
hoping to get JS2-716 in for the next release, but imports can be
done via the command line as well today
>> 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
>
Interesting. What license is this code developed under?
I will review the code and see what I think. In general I would like
to not introduce anymore new ways to parse XML into Jetspeed
As I have stated on this list before, we have like 5 different ways
to parse XML built into Jetspeed today such as Castor, Digester
Would be best to settle on one approach
>> > 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.
>
Yes, you can leverage a lot of the high level stuff for copying and
cloning trees of PSML
Re: jcr page manager
Posted by Edgar Poce <ed...@gmail.com>.
Hi David,
First of all thank you very much for your comments.
On 5/29/07, David Sean Taylor <da...@bluesunrise.com> 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: jetspeed-dev-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: jcr page manager
Posted by David Sean Taylor <da...@bluesunrise.com>.
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: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>