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
>>
