[David, this discussion should really be public, I'm CCing the mailing-list
too]
> Tonight I have started my research into the new build and my plan for the
> Profiler Service.
> First, I would like to have a good understanding of the Jetspeed object
> model and how persistence works.
Don't worry I don't understand it neither : in some place it just does
not make sense.
If you encounter a piece of code that is overly complicated or badly designed,
work a new clean design rather than try to "fix" existing classes.
> So I have been browsing the code, and I come to the RegistryManager:
>
> public static void refresh() {
>
> .....
>
> DiskCacheEntry pde =
> JetspeedDiskCache.getInstance().getEntry( getURL() );
>
> Log.note( "Using JetspeedConfig from: " + pde.getURL() );
>
> jetspeedConfig = JetspeedConfig.unmarshal(
> pde.getReader() );
>
> setJetspeedConfig( jetspeedConfig );
>
> RegistryMerge.merge( jetspeedConfig );
> .....
> }
> }
>
> This code kicks off the Castor XML-Java demarshaller and merges back the
> psml into the in-memory objects.
> This is basically it for loading the objects from disk. Rather subtle.
> The simplicity concerns me.
> I was thinking there was a more abstract persistence model.
> For example I was considering storing all the PSML in a database instead of
> the file system.
> The current serialized persistence may not scale well, and will have
> multiuser issues (transactional isolation)
>
The Castor persistence model we use has a lot of drawbacks and if you
have followed the TODO discussion and vote, everybody agrees that it
needs to be changed. We just have to decide whether it's now or a bit
later.
> I like the way that Turbine allows for the backend database to be pluggable.
> Is that a goal for Jetspeed configurations, or are the plans to remain
> file-based?
>
The new persistence model choice is till up in the air. Torque is nice but
database only so far. This has the inconvenient that we *have* to provide
complete administration tools in order to let the people evaluate Jetspeed
whereas with XML persistence a bunch of example files is enough.
Following Jeff advice, I've had a quick look at the new Castor which has
another persistence mechanism using a mapping file which can either
persist to XML or to a DBMS. Seems nice. (http://www.exolab.org/castor/
if you want to have a look).
> I also like that Turbine has an Object Model abstraction.
> (org.apache.turbine.om)
>
> Profiler:
> I see the Profiler's essential behavior as a map:
>
> user + capability + ? --> psml resource
>
> A user may not have a direct resource, but may use a group-resource such as
> a company-department.
> The actual content per-portlet delivered may depend on the user, but the
> actual psml resource may be defined for the group. So there must be another
> mapping:
>
> user --> group resource
>
The original intention of the Profiler is to map a request to a PSML resource.
incoming request --------------------------------> PSML resource
^
|
Profiler
This may actually be abstracted to
Request ------------------> Profile
^
|
Profiler
where Profile is an interface giving access to the pertinent profile
for the request. Such a profile should at least provide the PSML
resource to use for this request but may provide a lot more informations
based on complex analysis of the request and some business rules.
Some thought must be given as to where to integrate this code in the
Turbine framework. I believe Profiler should be service, that's pretty
clear but I don't know if Profile should be returned directly or made
available in a subclasses RunData object or directly from the User class.
> Looking at the current Profiler code, I am considering how to better
> abstract it. It appears the PSML entries are always stored on the file
> system or remotely:
>
> DiskCacheEntry pde = JetspeedDiskCache.getInstance().getEntry(
> url );
>
> and then to map the user its simply a filename string concatenation
>
> return new StringBuffer( TurbineResources.getString(
> JetspeedResources.PSML_BASE_URL_KEY ) )
> .append( username )
> .append(".psml")
> .toString();
>
> I could be wrong. I am now thinking the URL could be a webdav resource.
> There are also simple methods to encode database oids into urls. The PSML
> filename could also be used as a unique id in a database.
>
This is only the default implementation. If you want to persist to a db
or change the default mapping strategy, just write your own Profiler
implementation and register it in the JetspeedResources.properties
(key profiler.classname).
The resource is returned as a URL because it may represent *any* resource
since it's protocol independant.
Another alternative would be to have the profiler actually load the
PSML document and retun it inside its profile. Mhhh... it may be
a better solution actually.
Just food for thought, I'm looking forward to your profiler proposal :)
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
