geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: liferay
Date Thu, 22 Jun 2006 07:57:56 GMT
On 6/21/06, Jeff Genender <> 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 /


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