geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <>
Subject Re: liferay
Date Thu, 22 Jun 2006 14:42:16 GMT
Thanks for the suggestions Aaron.  Comments inline.

On 6/21/06, Aaron Mulder <> wrote:
> 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.

OK this sounds perfect. Before you revealed this I was planning to
create two liferay plugins -- one with the "LiferayDatabase"
dependency and one without  -- and then count on the user that has
manually created the db pool to pick the one without the dependency.
But IIUC I can use the technique you describe above to create a single
liferay plugin with the dependency and as long as the manually created
db pool is named correctly the plugin installer will do the right
thing.  Neat.

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

Brian Chan sent a note earlier that says I can in fact change
liferay's context root by adjusting some XML and a properties file.
I'll look into that but it's nice to have this feature you describe in
my back pocket.

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

Since I'm using derby I believe that the DirectoryInitializationGBean
Matt pointed out should do the job.  But longer term I agree that a
more specialized GBean like you describe is the right way to go.  I'll
create a JIRA for a reusable version of the specialized GBean and
maybe this item can make it into 1.2.


View raw message