GeoNetwork does not start when using /jsp/geonetwork as the context path

[murrayh]

Hello,

SVN revision: 9266

The GeoNetwork webapp does not start when using a context path of /jsp/geonetwork.

The cause of this problem is that GeoNetwork attempts to create the directory "null/images/logos", which throws an exception. The exception never gets to the user, because:

• The exception does not get logged

• The webapp does not start, so HTTP requests don't return and the user cannot see the exception report

The root cause of this problem is:

• System properties are set using the webapp's context path (in my case: jsp/geonetwork)

• In some places system properties are read using "getServletContextName()", which is the display name of the webapp, which defaults to "geonetwork".

I was able to work around this issue by editing web.xml and changing the display name from "geonetwork" to "jsp/geonetwork".

I was not able to reproduce the startup issue on a separate machine. On the other machine Java would quite happily make the folder "null/images/logos" without failing or throwing exceptions. I did full filesystem searches and couldn't find that folder anywhere, so there are some aspects to this issue that I do not understand.

Cheers, Murray

[ianwallen]

Murray,

We now (Since June 14, 2012) use GIt for the repository. See the following URL regarding compiling the 2.8 branch.

​http://trac.osgeo.org/geonetwork/wiki/HowToCompile

Regarding your particular issue there have been some changes recently regarding the context path - please try compiling a more recent version to see if you issue still exist.

I'm closing the ticket - Reopen ticket if the issue can still be reproduced using a more recent build.

Thanks.

[murrayh]

Hi Ian,

The same issue exists in both the master branch and the 2.8.x branch of the git repository.

The "webAppName" argument passed into the GeonetworkDataDirectory object is actually the context path, not the display name. You can see this in GeoNetwork.java.

Then it is just a matter of searching for "getServletContextName" to find instances of the bug.

Cheers, Murray

[murrayh]

Hello,

One more note: If you have file permission errors on the logo directory (ie. the logo directory cannot be created), it is very hard to debug.

Even when this getServletContextName bug is fixed, this file permissions error state is still possible, and I strongly recommend making it easier to debug that particular failure mode (by logging the runtime exception in the debug log).

The operations team weren't happy with me. We were restarting our shared Tomcat instance at least once a day for about two weeks while I was trying debug this (as noted in the original report, for a long time I was unable to reproduce on a separate environment because Java filesystem commands behaved differently).

Cheers, Murray