You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Hernan Cunico <hc...@gmail.com> on 2007/04/04 21:51:07 UTC
Running portlets in Geronimo - Documentation
Hi all,
I put together a doc for configuring a portal server (a.k.a. Liferay) on Geronimo. I saw a couple of times users asking how to deploy portlets in Geronimo, hopefully this doc will help to address some of those questions.
Here is the link:
http://cwiki.apache.org/GMOxDOC11/configuring-portals-liferay.html
As usual, comments welcome!
Cheers!
Hernan
Re: Running portlets in Geronimo - Documentation
Posted by Hernan Cunico <hc...@gmail.com>.
Paul McMahan wrote:
> On Apr 4, 2007, at 6:10 PM, David Jencks wrote:
>
>> What I'm hoping for in the future for these kinds of situations is
>> that there can be plugins configured for each of several databases,
>> e.g. mysql, db2, firebird, etc and to switch the backend all you need
>> to do is change a line in artifact_aliases.properties. I'm trying
>> this out with Peter Petersson with the roller plugin we've started in
>> the plugins dir.
>
> That sounds like the right direction. This might get easier if we
> separate the datasource component from the actual database itself. I'm
> not sure about the roller plugin, but the Liferay datasource component
> includes not only the datasource but a derby database that is
> prepopulated with the Liferay schema. So, a side effect of installing
> the Liferay datasource plugin is that you get a new derby database under
> var/derby that's ready to roll. From an end user's perspective this
> makes it really easy to get a running portal server in Geronimo as a
> POC. But users looking for more configurability and optimization are
> not as well served. That becomes apparent as you read Hernan's new article.
Just for additional reference, Liferay folks provide only one plugin for the datasource, after that they provide a ton of sql scripts to create and populate data for about 8 different databases.
Agreed, it would be great to have just one click to install and just one click to remove specific features/services with all it's dependencies.
>
>> Anyway, I think its generally better to have the "other project"
>> supply plugins for the databases they support rather than asking users
>> to create one themselves. Making the process easy... that will be the
>> challenge.
>
> I totally agree here as well. I think the main impediment right now is
> that setting up and maintaining a plugin repository (or even just a
> collection of plugins to be hosted elsewhere) requires some research and
> trial and error. We can help that situation by providing more examples
> and documentation, and by improving the overall design. I hope that
> Geronimo's own plugin repository will provide an example worth emulating.
>
>
> Best wishes,
> Paul
Cheers!
Hernan
Re: Running portlets in Geronimo - Documentation
Posted by Paul McMahan <pa...@gmail.com>.
On Apr 4, 2007, at 6:10 PM, David Jencks wrote:
> What I'm hoping for in the future for these kinds of situations is
> that there can be plugins configured for each of several databases,
> e.g. mysql, db2, firebird, etc and to switch the backend all you
> need to do is change a line in artifact_aliases.properties. I'm
> trying this out with Peter Petersson with the roller plugin we've
> started in the plugins dir.
That sounds like the right direction. This might get easier if we
separate the datasource component from the actual database itself.
I'm not sure about the roller plugin, but the Liferay datasource
component includes not only the datasource but a derby database that
is prepopulated with the Liferay schema. So, a side effect of
installing the Liferay datasource plugin is that you get a new derby
database under var/derby that's ready to roll. From an end user's
perspective this makes it really easy to get a running portal server
in Geronimo as a POC. But users looking for more configurability and
optimization are not as well served. That becomes apparent as you
read Hernan's new article.
> Anyway, I think its generally better to have the "other project"
> supply plugins for the databases they support rather than asking
> users to create one themselves. Making the process easy... that
> will be the challenge.
I totally agree here as well. I think the main impediment right now
is that setting up and maintaining a plugin repository (or even just
a collection of plugins to be hosted elsewhere) requires some
research and trial and error. We can help that situation by
providing more examples and documentation, and by improving the
overall design. I hope that Geronimo's own plugin repository will
provide an example worth emulating.
Best wishes,
Paul
Re: Running portlets in Geronimo - Documentation
Posted by David Jencks <da...@yahoo.com>.
On Apr 4, 2007, at 2:34 PM, Paul McMahan wrote:
> On Apr 4, 2007, at 5:01 PM, Hernan Cunico wrote:
>
>> A limitation of the data source creation wizard is that you cannot
>> specify some of the values, more specifically all those that make
>> the moduleId. Liferay plugin is specifically looking for a
>> connection pool named *LiferayPool* and with the following
>> moduleId *liferay/liferay-pool/4.2.1/car*. If you use the console
>> you'll get something like console.dbpool/LiferayPool/1.0/rar and
>> installing the portal server plugin will fail.
>
> Hernan, you're exactly right. I had forgotten about that
> limitation of the data source wizard and how that the portal plugin
> relies on the datasource plugin to use a certain module name. The
> original reason I put that dependency in place was to facilitate
> the relationship between the plugins so that if you install portal
> plugin it will automatically download and install the datasource
> plugin. Or you could deploy a customized datasource beforehand
> (like the mysql one you provided instructions for) and the plugin
> installer wouldn't try to replace it with the derby one. The end
> goal was to minimize the number of steps it takes new users to get
> a working portal server, while still allowing more advanced users
> to use an external database like mysql or DB2.
>
> At least that's how it used to work. Now I believe the plugin
> catalog lists the datasource plugin as a "prerequisite" of the
> portal plugin instead of just a "dependency", so the plugin
> installer lists the portal plugin as unavailable until you have
> installed the datasource plugin. The Liferay team maintains the
> catalog so that may be how they prefer things. Or they might want
> to refine that part of their plugin catalog when we look into
> updating it for Geronimo's upcoming 1.2 release.
What I'm hoping for in the future for these kinds of situations is
that there can be plugins configured for each of several databases,
e.g. mysql, db2, firebird, etc and to switch the backend all you need
to do is change a line in artifact_aliases.properties. I'm trying
this out with Peter Petersson with the roller plugin we've started in
the plugins dir.
Anyway, I think its generally better to have the "other project"
supply plugins for the databases they support rather than asking
users to create one themselves. Making the process easy... that will
be the challenge.
thanks
david jencks
>
> Best wishes,
> Paul
Re: Running portlets in Geronimo - Documentation
Posted by Hernan Cunico <hc...@gmail.com>.
Yup, exactly. It wont let you install the server if you don't have the datasource defined first.
Maybe by having it this was it is somewhat easier, and maybe inviting, to customize the datasource.
Cheers!
Hernan
Paul McMahan wrote:
> On Apr 4, 2007, at 5:01 PM, Hernan Cunico wrote:
>
>> A limitation of the data source creation wizard is that you cannot
>> specify some of the values, more specifically all those that make the
>> moduleId. Liferay plugin is specifically looking for a connection pool
>> named *LiferayPool* and with the following moduleId
>> *liferay/liferay-pool/4.2.1/car*. If you use the console you'll get
>> something like console.dbpool/LiferayPool/1.0/rar and installing the
>> portal server plugin will fail.
>>
>
> Hernan, you're exactly right. I had forgotten about that limitation of
> the data source wizard and how that the portal plugin relies on the
> datasource plugin to use a certain module name. The original reason I
> put that dependency in place was to facilitate the relationship between
> the plugins so that if you install portal plugin it will automatically
> download and install the datasource plugin. Or you could deploy a
> customized datasource beforehand (like the mysql one you provided
> instructions for) and the plugin installer wouldn't try to replace it
> with the derby one. The end goal was to minimize the number of steps it
> takes new users to get a working portal server, while still allowing
> more advanced users to use an external database like mysql or DB2.
>
> At least that's how it used to work. Now I believe the plugin catalog
> lists the datasource plugin as a "prerequisite" of the portal plugin
> instead of just a "dependency", so the plugin installer lists the portal
> plugin as unavailable until you have installed the datasource plugin.
> The Liferay team maintains the catalog so that may be how they prefer
> things. Or they might want to refine that part of their plugin catalog
> when we look into updating it for Geronimo's upcoming 1.2 release.
>
> Best wishes,
> Paul
Re: Running portlets in Geronimo - Documentation
Posted by Paul McMahan <pa...@gmail.com>.
On Apr 4, 2007, at 5:01 PM, Hernan Cunico wrote:
> A limitation of the data source creation wizard is that you cannot
> specify some of the values, more specifically all those that make
> the moduleId. Liferay plugin is specifically looking for a
> connection pool named *LiferayPool* and with the following
> moduleId *liferay/liferay-pool/4.2.1/car*. If you use the console
> you'll get something like console.dbpool/LiferayPool/1.0/rar and
> installing the portal server plugin will fail.
Hernan, you're exactly right. I had forgotten about that limitation
of the data source wizard and how that the portal plugin relies on
the datasource plugin to use a certain module name. The original
reason I put that dependency in place was to facilitate the
relationship between the plugins so that if you install portal plugin
it will automatically download and install the datasource plugin. Or
you could deploy a customized datasource beforehand (like the mysql
one you provided instructions for) and the plugin installer wouldn't
try to replace it with the derby one. The end goal was to minimize
the number of steps it takes new users to get a working portal
server, while still allowing more advanced users to use an external
database like mysql or DB2.
At least that's how it used to work. Now I believe the plugin
catalog lists the datasource plugin as a "prerequisite" of the portal
plugin instead of just a "dependency", so the plugin installer lists
the portal plugin as unavailable until you have installed the
datasource plugin. The Liferay team maintains the catalog so that
may be how they prefer things. Or they might want to refine that
part of their plugin catalog when we look into updating it for
Geronimo's upcoming 1.2 release.
Best wishes,
Paul
Re: Running portlets in Geronimo - Documentation
Posted by Hernan Cunico <hc...@gmail.com>.
Thanks Paul for updating the doc, I couldn't figure out why just some times I was having the context root conflict.
A limitation of the data source creation wizard is that you cannot specify some of the values, more specifically all those that make the moduleId. Liferay plugin is specifically looking for a connection pool named *LiferayPool* and with the following moduleId *liferay/liferay-pool/4.2.1/car*. If you use the console you'll get something like console.dbpool/LiferayPool/1.0/rar and installing the portal server plugin will fail.
I think there is already a JIRA for improving the "flexibility" of thedatasource creation wizard to allow entering specific moduleId's. In fact, not too long ago we had a discussion on dev@ about these values, I'll try to find it.
Cheers!
Hernan
Paul McMahan wrote:
> Great article Hernan! I tweaked the part about uninstalling the
> welcome application. Also, I'm not sure if you might have already
> considered this but the mysql datasource could be created using the
> database wizard, and a mysql driver can be automatically downloaded from
> there as well. (Maybe you tried that but it wasn't as straight-forward
> as I imagine :-)
>
> Best wishes,
> Paul
>
> On Apr 4, 2007, at 3:51 PM, Hernan Cunico wrote:
>
>> Hi all,
>> I put together a doc for configuring a portal server (a.k.a. Liferay)
>> on Geronimo. I saw a couple of times users asking how to deploy
>> portlets in Geronimo, hopefully this doc will help to address some of
>> those questions.
>>
>> Here is the link:
>>
>> http://cwiki.apache.org/GMOxDOC11/configuring-portals-liferay.html
>>
>> As usual, comments welcome!
>>
>> Cheers!
>> Hernan
>
>
Re: Running portlets in Geronimo - Documentation
Posted by Paul McMahan <pa...@gmail.com>.
Great article Hernan! I tweaked the part about uninstalling the
welcome application. Also, I'm not sure if you might have already
considered this but the mysql datasource could be created using the
database wizard, and a mysql driver can be automatically downloaded
from there as well. (Maybe you tried that but it wasn't as straight-
forward as I imagine :-)
Best wishes,
Paul
On Apr 4, 2007, at 3:51 PM, Hernan Cunico wrote:
> Hi all,
> I put together a doc for configuring a portal server (a.k.a.
> Liferay) on Geronimo. I saw a couple of times users asking how to
> deploy portlets in Geronimo, hopefully this doc will help to
> address some of those questions.
>
> Here is the link:
>
> http://cwiki.apache.org/GMOxDOC11/configuring-portals-liferay.html
>
> As usual, comments welcome!
>
> Cheers!
> Hernan