Aaron Mulder wrote: > One is that you can declare a database pool dependency named > "LiferayDatabase" or whatever. Then provide a Derby database pool > plugin with that name. If the user creates a custom database pool > named "LiferayDatabase" then the Liferay plugin will map to that, > whatever it is. If not, it will download and install the Derby > database pool. (This only works for embedded databases like Derby > where there's no need to point it to a specific DB server, etc.)
This sounds like the right option for Liferay. > The other option is that a plugin can "obsolete" other modules or > plugins. So the Liferay can obsolete the welcome app, meaning the > welcome app will be uninstalled when the Liferay plugin is installed. > It's kind of heavy-handed, but probably better than having it install > and immediately fail due to the context root conflict. > Personal preference...but I think its better throwing an error. Is "obsoleting" a settable option? I am not so sure I like obsoleting by default...this could be ugly since it may be another app other than the Welcome app that gets obsoleted. > As far as populating the database, you can provide a GBean that runs > whenever a flag like "initialized" is false. Every time it starts it > can check the flag and abort if it's set. If it's not set, it can do > its work, and then set the flag on itself (via a roundabout kernel > call), so it will never execute the initialization again. Or, of > course, just connect to the DB and only execute the initialization if > some known Liferay table is not present. > > Thanks, > Aaron > > On 6/21/06, Paul McMahan <[EMAIL PROTECTED]> wrote: >> Liferay is an open source portal made available under the MIT license. >> They provide a geronimo+liferay distribution from their website, >> which is basically a zipped up geronimo/tomcat server with liferay >> already deployed. I had some problems starting a fresh install of this >> distribution due to hsql database driver issues. Hopefully new users >> who experience this same problem will find the entry I posted in >> liferay's support forum about how to get it working: >> http://forums.liferay.com/index.php?showtopic=5348 >> >> Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which >> has the new versioning functionality but as you can imagine is missing >> several important bug fixes and schema changes. I got their WAR >> working in geronimo 1.1 after making some adjustments to its >> geronimo-web.xml. When geronimo 1.1 is officially released I'll offer >> my assistance to help them upgrade to it. >> >> I also think and have heard others mention that liferay is a great >> candidate for a geronimo plugin. Adding the necessary plugin files to >> the liferay WAR is straightforward. But there are a couple of >> interesting challenges where I would like to get your input. First >> is that the plugin prereqs a database pool. Some expert users will >> want to manually create and populate the database and then use the >> console to point a db pool at it before installing the liferay plugin. >> But I imagine that some developers and more casual users would like >> for geronimo to automatically create a database pool for them as part >> of the liferay plugin install process. That way they could add a >> working portal server to their geronimo server with only a few clicks >> in the console (remember Joe's mom? ;-) >> >> For this latter class of users geronimo could provide a plugin that >> defines a derby datasource and automatically populates the database >> when the plugin is installed. Does this sound like a reasonable idea? >> I thought geronimo might already provide some facility to populate >> the database and I found this dev thread from last year where its >> proposed but (I assume) not implemented yet : >> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL >> PROTECTED] >> >> This idea sounds right on to me. Are others still in favor of it? If >> so then I would like to work on an implementation. By the way, >> liferay currently does not support derby but I have it (mostly) >> working via a patch that I'll submit to them later. >> >> The second interesting aspect of creating liferay plugin is that >> liferay wants to use '/' for its context root. The problem is that >> the geronimo welcome app is already installed in the '/' context root >> and this prevents liferay from starting. I tried moving it to a >> different context root but then hard-coded references to scripts and >> images in their html started breaking. Is there a way to make >> geronimo override a context root such that last in wins? Or could the >> plugin metadata specify the required context root so that the console >> can warn the user about potential conflicts before installing the >> plugin? Any ideas? >> >> Looking forward to your feedback. >> >> Best wishes, >> Paul >>
