Raphael Luta wrote:
> [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 JetspeedDiskCache is taking care or synchronization WRT external resource
access. For writable resources, the situation is not completely done. Where the
DiskCache is renamed as a service and implemented in a pluggable way, you will
have a contract that guarantees:
- Any external resource will only be retrieved by one thread at a time
- The resource will not be retrieved again until it expires
- Any resource being written will trigger expiry (I think immediately after
writing has finished).
>
> 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]
--
--------------------------------------------------------------
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]
