On 6/21/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
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.
You don't have to obsolete anything -- I said you "can" do that. If you use the obsoletes, you provide module IDs you obsolete. So you could specify geronimo/welcome/*/car and it would remove the welcome app if present and not if not and you wouldn't obsolete anything else that happened to be listening on / Thanks, Aaron
> 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 >>