Aaron Mulder wrote: > 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 / >
I read that you stated, "It's kind of heavy-handed, but probably better than having it install and immediately fail due to the context root conflict." I disagreed with that statement you made. I don't believe anything should supersede any application, except those that are controlled by themselves (i.e Liferay superseding an earlier version of Liferay"). > 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 >> >> >>
