geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: liferay
Date Thu, 22 Jun 2006 00:26:49 GMT

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

View raw message