Thanks for the helpful feedback Jeff. Comments inline.
On 6/21/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
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 I was the one who helped get the Liferay implementation running with the Liferay guys. I personally got it running fine on MySQL.
Nice work! Yeah I also had no problems getting it to run on mysql. It was the out of the box distribution which uses hsqldb that I had problems with. It may have been something environmental because Brian didn't encounter any problems. The instructions I provided in the support forum describe how to replace the hsqldb pool with a mysql pool. No other changes were necessary.
> 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. Yes...we used 1.1 SNAPSHOT because it was the best available to move forward with. I am currently working with them to get the Enterprise version working...hopefully next week. If you want to join in...by all means please do ;-)
I agree using the 1.1 SNAPSHOT makes good sense since the release of liferay 4.0 was imminent. To get it working in the geronimo 1.1rc I needed to update geronimo-web.xml for the new schema -- replacing configId with moduleId and removing the context-priority-classloader element. I also encountered some classloader problems due to liferay having cglib and spring in its WEB-INF/lib directory (figuring this out gave me a major headache :-) I worked around that by adding them to <hidden-classes>. I'm not an EJB expert but I'm definitely on board for helping with the Enterprise version if you could use a hand. Ping me on IRC if you wanna discuss...
> 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? ;-) When I did the professional version I placed an automagically created DB pool...but with MySQL. But it was proof of concept since who knows if someone is going to be using MySQL or not or where the database would even live. But to offer a plugin for Derby would be great IMHO for people to "try it out"...since Derby will likely live with Geronimo. But obviously when using an enterprise class database, it made no sense to include it since the locations may be anywhere. It would be difficult to provide plugins for this.
Yeah I definitely agree that this was the right approach since production level servers will want to use an enterprise class database. I think that ideally the liferay plugin would automatically set up a derby pool unless the user has already set up a pool manually. After hearing from Aaron it sounds like the plugin architecture handles this case quite nicely. Subsequently, if derby is too lightweight then it should be easy to switch to a server like DB2. Using the console db wizard that process seems pretty straightforward as well.
> 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? According to their documentation for the other appservers, they have you remove ROOT context. This seems to be the way they do it.
Removing the ROOT context definitely does the trick, and I agree that's the right approach for the distribution of geronimo+liferay available from their website. But for the case where liferay is added to an existing geronimo server I wanted to change the context root to something like "/liferay" so that the welcome app doesn't need to be removed. I had partial success by changing the redirects in index.html and updating the root_path parameter in web.xml. But after hearing from Brian now I see there's also an entry in WEB-INF/lib/portal-ejb/portal.properties that I need to adjust. Thanks, Paul
