Blog

2011
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2010
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2008
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2007
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2006
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

2005
- 12
- 11
- 10
- 09
- 08
- 07
- 06
- 05
- 04
- 03
- 02
- 01

Posted 2007/08/14

Gridsphere 3.0.8 build.properties problems

We are using Gridsphere (GS) as the container for the portal parts of the VERA project. Here are two bugs/features I found when setting up GS 3.0.8.

When you are install GS the build.properties file has a bunch of options in it to customize the ant build process. The ‘Getting Started Guide’ (at the time of writing here) has a section under ‘Building the Source’ which describes how to edit the build.properties file and the build.properties file has some in-line documentation by way of comments (always handy). Here is the build.properties file for GS 3.0.8:

# $Id: build.properties 6288 2007-06-15 09:11:38Z wehrens $
#
# Configuration properties for building GridSphere
gridsphere.version=3.0
gridsphere.release=.8
# The following 2 params determine the URL of the gridsphere portal, default is gridsphere/gridsphere
# This is the name of the gridsphere webapp that is deployed, default is gridsphere
# Some examples:
#   http:///myorg/portal
#               gridsphere.deploy=myorg, gridsphere.context=portal
#
gridsphere.deploy=gridsphere
gridsphere.context=gridsphere
gridsphere.build=build
gridsphere.dist=dist
# possible option is tomcat
gridsphere.appserver=tomcat
# deploy gs with precompiled jsp’s; options are true or false (or anything else)
gridsphere.useprecompiledjsp=true

I found that altering either ‘gridsphere.deploy’ or ‘gridsphere.context’ breaks the portal. The rest of the post describes what happened in each case so that Googlers can learn from my pain.

Changing gridsphere.deploy

I set ‘gridsphere.deploy=portal', ran ‘ant deploy’ and tried the portal. This is the exception I got in my browser window:

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception
java.lang.NullPointerException
org.gridsphere.services.core.persistence.impl.PersistenceManagerRdbmsImpl.currentSession(PersistenceManagerRdbmsImpl.java:249)
org.gridsphere.services.core.persistence.impl.PersistenceManagerRdbmsImpl.endTransaction(PersistenceManagerRdbmsImpl.java:262)
	org.gridsphere.servlets.GridSphereFilter.doFilter(GridSphereFilter.java:113)
note The full stack trace of the root cause is available in the Apache Tomcat/5.5.23 logs.
Apache Tomcat/5.5.23

Looking in the 'catalina.out' log file I found what the root of the error:

java.io.FileNotFoundException: /opt/portals/tomcat/webapps/gridsphere/WEB-INF/CustomPortal/content/repository/workspaces/default/index/redo.log (No such file or directory)

The problem with that is the portal is installed in ?/opt/portals/tomcat/webapps/portal/? and not ?/opt/portals/tomcat/webapps/gridsphere/?. I changed the deploy path for GS so maybe something inside GS has the default path hardcoded or something else requires configuring - so either code or the docs need updating.

I undeployed GS and deleted all traces of it from Tomcat. Then I deployed it again and looked in the webapps directory:

portals@skutter:~$ ls tomcat/webapps/
balancer    jsp-examples  ROOT               tomcat-docs
gridsphere  portal        servlets-examples  webdav

So there was a 'gridsphere' AND a 'portal'. If you look in the 'gridsphere' directory you see all the images, themes and javascript. Investigating the GS source showed that there are hundreds of hardcoded paths to these files in jsp, xml and bits of html. So unless there is another config step not in the docs it seems that even if you change the deploy directory GS will still need to make a ?gridsphere? dirctory to hold the files that have hardcoded references.

I started the Tomcat container and tailed ?catalina.out?, the container started with no errors. I then went to /gridsphere/gs and watched the log. This gave me the same file not found error. Using the error message I looked through the GS code to find where it was generated, following the java classes traced problem back to PortletServiceConfig.getServletContext() which returns the servlet context. This servlet context is used to find the path where the config file is stored and it is incorrectly generating 'gridsphere' rather than 'portal'. The servlet context comes from the Tomcat container itself, so there is not much we can do here, I assume tat if you leave the deploy directory alone and let everything stay in 'gridsphere' we would not see this error.

To test this out I undeployed GS and redeployed using the default location of 'gridsphere'. I edited the build.properties file to look like this:

gridsphere.deploy=gridsphere
gridsphere.context=gs

This seemed to fix it at first… So for GS version 3.0.8 do not change gridsphere.deploy from the default (gridsphere).

Changing gridsphere.context

I wiped eveyrting and started from scratch, this time I used I set ‘gridsphere.deploy=gridsphere’ and I set ‘gridsphere.context=gs', ran ‘ant deploy’ and tried the portal.

This got me past the create database screen and on to the final part of the installation which is to create a GS user. After you fill in the database form GS gives you another HTML form to enter this user information.

After creating the account I was shown a welcome page. How ever I could not see the administrator links at the top of the page. There was a ‘Login’ button in the top right but clicking it did nothing. I cleared the authenticated sessions for my browser and went back to the page and I saw the same welcome information and ‘Login’ link (which still did not work). So basically GS seemed to be installed but none the links worked.

I tried lots of different combinations of reinstalling GS and using the embedded and MySQL databases. None of this fixed the problem, I would go through setting up the database and creating the GS user but then the links in the portal did not work.

This took some head scratching because there was no exception being generated, basically the portal appears to install ok but none of the links work (so you never see the login page, just the welcome page). The solution was linked to the previous problem, I was using a build.properties file that looked like this:

gridsphere.deploy=gridsphere
gridsphere.context=gs

My strange error was caused by changing ‘gridsphere.context’ from the default of ‘gridsphere’ to ‘gs’. This seems to cause the ‘links don't work’ bug.

So the moral of the story is if you are installing GS 3.0.8 what ever you do do not alter ‘gridsphere.deploy’ or ‘gridsphere.context’.

For now I am going to leave the build.properties alone, it should be possible to rename the URL using Tomcat anyway. If not we can use Apache rewrite or another proxy server. The reason I am so keen to change the URL is we want to integrate GS into the rest of the website and not run it on a separate port.