> > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
