> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Santiago Gala
> Sent: Thursday, November 16, 2000 4:54 AM
> To: JetSpeed
> Subject: Re: Profiler
>
>
>
>
> 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;ve already tried the mapping approach, and its easy.
Here is a working example that I am using in a BookmarkPortlet. Its a simple
recursive structure of folders and links.
The mapping file:
<mapping>
<class name="com.bluesunrise.bookmarks.Folder">
<map-to xml="folder" />
<field name="name" type="string" >
<xml name="name" node="element" />
</field>
<field name="links" type="com.bluesunrise.bookmarks.Link"
collection="vector" >
<xml name="link" node="element" />
</field>
<field name="folders" type="com.bluesunrise.bookmarks.Folder"
collection="vector" >
<xml name="folder" node="element" />
</field>
</class>
<class name="com.bluesunrise.bookmarks.Link">
<map-to xml="link" />
<field name="name" type="string" >
<xml name="name" node="element" />
</field>
<field name="href" type="string" >
<xml name="href" node="element" />
</field>
</class>
</mapping>
In the Folder and Link classes, put JavaBean-like getter/setters, and then
FileReader reader = new FileReader("bookmarks.xml");
// Marshal the person object
Mapping _mapping = new Mapping(
reader.getClass().getClassLoader() );
// _mapping.setLogWriter( writer );
_mapping.loadMapping( "mapping.xml" );
Unmarshaller unm = new Unmarshaller( Folder.class );
unm.setMapping( _mapping );
Folder folder = (Folder) unm.unmarshal(reader);
The other nice part of Castor is that it also works with databases, and that
it supports JDO to some extent.
So in theory, you could use the same classes without recompiling, and swap
your file-based mapping.xml with a database-based mapping.xml. I haven't
tried this yet. When I do I will post an example.
> > > 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.
> >
Yes, I like this, the Profiler should return a Profile object.
> > > 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.
> >
I agree. More on this later
> > Just food for thought, I'm looking forward to your profiler proposal :)
> >
Yes, I am looking forward to it too :)
But I don't want to put out a proposal without thorough research and
understanding.
So bear with me a few days..
> > --
> > 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]
>
>
--
--------------------------------------------------------------
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]
