incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <>
Subject Re: Graffito release plans?
Date Sun, 16 Jul 2006 08:39:20 GMT
On 7/15/06, Jukka Zitting <> wrote:
> Hi,
> On 7/15/06, Christophe Lombart <> wrote:
> > Ooops - I'm very sorry, the OCM unit tests are in :
> > /jcr/jcr-mapping/src/test (not in /components/src/test)
> No problem. At the moment I'm really more interested in how the
> Graffito portlet components use the persistence API than in the
> specifics of the way it is implemented by the OCM tool. Once I've
> understood the Graffito core model, I'll have a better grasp on how
> the OCM tool fits into the picture. I hope you'll have the patience to
> help me through this. :-)
> > > What is the "folder" instance in this case? Is it a plain data object
> > > or an adapter to an underlying folder concept?
> >
> > it points to  a plain data object. A usual pojo  with simple
> > getters/setters.
> Is this POJO class shared by the different persistence implementations
> (DB, JCR, etc.) or does each implementation have it's own POJO classes
> that implement the core model interfaces?

The same pojo can be persisted anywhere (DB, JCR, custom, ...).

What I'm getting at here is that if the "folder" in the example is a
> data object, why do we need the Folder interface? Wouldn't it make
> more sense to replace the Folder interface with a shared data object
> class?

Right ! The interfaces are not really useful until now.

> > Can I implement my own Folder class and pass instances of it to the
> > > persistence layer?
> >
> > yes but you have to specify the interface "Folder" and  the class
> "MyFolder"
> > it in the mapping file.
> OK. But if I write a Graffito portal component that relies on this,
> wouldn't the requirement to have a JCR-specific mapping file break the
> indepence from the underlying persistence model? How would I map that
> custom class to a DB storage?

The mapping file referenced in my previous mail is JCR specific. So, this
JCR mapping file is not required for another persistence store type. The
independence  from the underlying persistence model is still there because
we are managing simple pojo objects.

The persistence service works with "Content Stores" (see
org/apache/portals/graffito/store/ContentStore). A content store represents
a specific content server running somewhere.
There is one content store implemented  with OJB to store content objects in
a DB. A JCR store is not yet implemented. Of course, I would like to build
the JCR store with our OCM tools. If needed, you can write your own content

FYI,  each time the persistence service wants to deal with a content object
(update, insert, retrieve, ...), it redirects the request to the appropriate
content store.
The  persistence layer is just there to group together different content
servers and present them to portal components. So, the portal can access to
heterogeneous content server
I think I have to review the page : which is not very
clear. Maybe sequence diagrams will be. There is also in my language a mix
between store and server.

Supporting different content types (eg. JCR & DB in the same running
application) is not fully tested. I expected that some work has to be done.

Best regards,


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