> Hi,
>
> I'm trying to do certain modifications to Jetspeed. The main
> requirement we
> have is, we want to put .psml/markup information into
> database. We don't
> want all those .psml files lying around in file system. And
> as number of
> users grow, it will just flood the file system.
>
> Here are some of my findings and conclusions:
> 0. Need to define a database schema, which will allow to
> store per group/per
> role/per user specific .psml information in to database.
There is already a 'schema' for PSML: src/xml/schema/psml.xsd
This XML Schema is the definitive schema for PSML.
>From the xml schema, we use Castor to create the Java object model for PSML.
I believe the database schema to be an implementation detail for a
relational database implementation.
> 1. The current Profiler Manager Service
> (org.apache.jetspeed.services.profile.JetspeedProfileManagerSe
> rvice) needs
> to be rewritten.
I think you want to look at the
org.apache.jetspeed.services.psmlmanager.PsmlManagerService interface - this
has more to do with the storage and retrieval of PSML.
For the next release, I'd like to refactor the Profiler service to better
use the PsmlManagerService to persist and query psml.
That said, I disagree that the JetspeedProfileManagerService should be
rewritten.
It is a good implementation of a file-system based profiling system.
Wouldn't you prefer to have two implementations: a file-based and
database-based implementation?
Both would implement the same interface:
org.apache.jetspeed.services.profiler.ProfilerService.
Thus you can plug in the new Service impl. without disrupting any other code
in the system.
And for those who chose not to use database storage for their psml, they are
still free to store it in the file system with the
JetspeedProfileManagerService.
This was the design intention from the beginning.
> 2. The new rewritten class can be plugged into Jetspeed thro'
> properties
> file.
> 3. Also, org.apache.jetspeed.cache.disk package needs to be
> modified. It
> curently handles remote and local urls. It needs handle the
> database storage
> to get the required information if the newly written Profiler
> Manager has to
> use Disk Cache (which it will now, as we don't want to go to database
> everytime user logs in).
You shouldn't have to touch the Disk Cache.
The impl. of the new DatabaseProfileManagerService would most likely use
JDBC, or perhaps Castor JDO...
Take a look at the CastorPsmlManagerService. It already makes use of a
WeakReference memory cache.
>
> Will someone from the Jetspeed development team comment on
> this, please? Or
> is there a plan to incorporate this as a new feature?
>
Sure. If you write it, we would be glad to incorporate it :)
However, we are not planning on writing this for the 1.3a2 release.
I think it would be a good candidate for 1.3a3, along with the refactoring
of the Profiler and PSMLManager, which is already planned.
> Thanks,
>
> -Atul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
