geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: liferay
Date Wed, 21 Jun 2006 21:42:15 GMT
Paul,

David Jencks wrote a GBean to do mostly what your looking for.  If you look in 
applications/daytrader/derby you'll find how the database is predefined for derby.  In the
DayTrader 
plan built in configs/daytrader/src/plan/target/plan.xml you'll find an entry in the deployment
plan 
the copies the pre-built database into the Geronimo var directory.

Here is the XML part of the deployment plan.

   <gbean name="DaytraderResources" 
class="org.apache.geronimo.system.util.DirectoryInitializationGBean">
     <!--copies daytrader derby db files into specified location-->
     <attribute name="prefix">META-INF/geronimo-daytrader-derby-db</attribute>
     <attribute name="path">var/derby</attribute>
     <reference name="ServerInfo">
       <name>ServerInfo</name>
     </reference>

I think this is what your are looking for.  Does this help?

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:
> 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/%3c0293590575765d45a9bfccfe7220a654@yahoo.com%3e

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

Mime
View raw message