There are two options you should be aware of for a plugin.
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.) The simple alternative is to make the database pool a prerequisite instead of a dependency, which would mean the user would have to create a pool with the right name by hand before the plugin would install. As a side note, we're certainly open to more customized handling of database pool dependencies, but it's not there in 1.1. 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. 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
