Thanks Matt this helps a lot. Sounds like
DirectoryInitializationGBean can get the job done, mainly due to the
fact that creating a database in derby is as easy as copying a
directory into var/derby. I'll look into this approach for the
initial rev of the liferay database pool plugin and think longer term
about creating a more specialized GBean which can run arbitrary sql
against a database connection supplied in the plan xml.
Paul
On 6/21/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
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/[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
>
>
>