portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject Re: dbpsml 2
Date Tue, 20 Nov 2001 05:48:24 GMT
> > The problem seems to be that while loading the file based psml, the
> > getDocument call, goes to the DBPsmlManagerService and is thus
> > trying
> > to get the document from the db...  I will see if I can work out
> > why
> > it does try and use the file based service... that started to load
> > it...
> >
>
> I think the way forward is to store the "loading" manager service in
> a transient variable of the profile - thus any calls for its document
> can be handled via the same manager.
>

It should be working now with Hypersonic, give it a try.
I am incredibly stupid. I took me forever to figure out that "ant install"
was copying over the entire Hypersonic database!
I used to have a little icon to do what I thought was the same thing - but I
only copied over the modified class files, not the whole webapp.
Anyway, I added a new target to the build -- 'ant deploy' -- which fits my
need of a 'hot deploy' to Tomcat, only copying over the latest 'touched'
class files.

> Although this seems a little involved... Perhaps this is because the
> committed code imports profiles differently from Atuls original patch
> and thus avoid this issue.
>
Yes thats true, it does work differently. I didnt like Atul's original
solution for the import, which was to basically duplicate all the code
(lots) in the CastorPsmlManagerService in the DbInitializer.
So I removed the DBInitializer, and came up with 'PsmlImporter' - which
makes use of both the file-based service and the database-service without
hardly any new code.
This almost worked, except for the BaseProfile always used the static
accessor class PsmlManager, to save and get PSML documents.
The ImportProfile takes a 'provider' and 'consumer' service, and then knows
that it gets its PSML from the provider service, and writes to the consumer
service.

> What is the bigger picture for this import routine - is it a "hack"
> until jetspeed handles starting from nothing in the db and building
> up the psml db from that?

No its not a hack. The default Jetspeed system is still distributed with
PSML on the file system.
If a user would like to switch over to the database impl, they have to have
some way to get their file-based PSML into the database.
My original thought was to write a command-line app, but that didn't go so
well since I couldn't find a good way to decouple our services from Turbine
and servlets in general.
Im told this will be easier in Turbine-3.
So Atul came up with the idea to import when the DBPSML Service first starts
up.
The first thing it does is run a check to see if the import has been run
before. If it finds the 'admin' user, it will NOT import.
Actually Atul had a setting in the JRP where you could specify which user to
lookup.
Or perhaps if we simply did a count(*) on the anonymous user


>
> Or is there a plan to keep the files/db in sync?
>
No - but Im working on an export from the database to the file system -
which will give you roundtrip.
To export elsewhere on the file system, set your JRP entry:
services.PsmlManager.root=<somewhere else on your file system>

David



--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message