Gonzalo,
There is no requirement from the Jetspeed end of things to use
repository security: it already implements the constraints and
permissions above the persistence layer. If a single set of credentials
is used, JCR sessions can also be pooled.
Of course, one can still use repository security if required for other
reasons. However, beware that the models are not easily mapped on top of
each other and it might take some clever coding to support existing
Jetspeed utilities and tools that read and write the existing
constraints and permissions.
Randy
Gonzalo Aguilar Delgado wrote:
Hi Randy,
Yes I noticed what you said when building objects. Effectively JABX and
JPA would be better but I didn't realized that they were not available
when you built this. So castor was a great choice...
I already built a basic set POJO objects for nodes that I will try to
propagate as a standard base for future works. But first I have to make
it work :-) Looks promising. This week I will try to have something
usable.
I'm using the OCM library with annotations but I'm considering keep
apart annotations to let others work with the same set of pojo objects.
My intention is to work with annotations until everything works and then
detach POJOS from the annotations. This way will be easier for me to
progress.
Jackrabbit has been a surprise for me... It works great for now!
I have another point that want to check with you. It's about security.
I think there are at least two ways to implement security:
1.- Using current implementation:
I will log in the repository with admin permissions and handle
by code all security constraints. This will fit best with
current implementation.
2.- Log into the repository with user credentials.
This will cause jackrabbit handle all security. I Will need more
detailed planning but I think it can work best and provide
better support for namespaces and workspaces. But maybe I will
have to touch a little bit the rest of the ecosystem.
Anyway I will try to do first (1) and then try if it will be nice to
have (2) implemented...
How do you see current approach?
____________________________________
Gonzalo Aguilar Delgado
Consultor CRM - Ingeniero en
Informática
M. +34 607814276
El jue, 24-06-2010 a las 06:17 -0700, [email protected] escribió:
Gonzalo,
Yes, ideally one would want a single set of POJO objects. However, this was not
possible for a number of reasons. The very fact that you noted the different
number of objects in the two implementation speaks to that, (yes, their
functionality is more or less equivalent believe it or not). Bottom line is
that the different persistence providers: Castor and OJB are fairly intrusive.
We would have more luck with modern implementations like JAXB and JPA. That
said, the work required to implement the behaviors required based on the APIs
far dwarfs the effort to duplicate the simple members and accessors a shared
set of beans might provide. Jetspeed is exclusively interface/component
orientated, so the common model interfaces provide the required patterns.
Conclusion: you'll need to implement your own set of beans for your JCR impl.
If you want to create a POJO layer within, there is hope in the future that it
could be reused in new persistence implementations.
BTW... are you planning on using a OCM library to facilitate the JCR to object
model mappings?
Randy
--- [email protected] wrote:
From: Gonzalo Aguilar Delgado <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Portal Page Implementation
Date: Thu, 24 Jun 2010 14:15:51 +0200
Hi Randy,
I saw that you implemented most of the page manager structure.
I'm just curious about that xml and db implementations use their own
implementation
of page, folder and rest of the objects. xml are under psml
implementation and db under impl.
I don't understand well why to do this. I suppose that all base objects
should be common and keep
them as pojo objects. And then implement special details under child
classes.
Why it's necessary duplicate every object and recreate hierarchy for
each implementation?
Also current implementation of xml and db differs. Maybe one is more
advanced than the other?
I say that because there are much more files under .impl than
under .psml
Thank you very much in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
