Loading of resources fail if deployed under custom context

[torse]

When GeoNetwork is deployed under a custom context like http://localhost:8080/my/geonetwork (via tomcat my#geonetwork.xml context file) some UI resources are not loaded properly. E.g. in the following URL the classification names are empty, see screenshot.

http://localhost:8080/my/geonetwork/srv/eng/admin.console#/classification/categories

Furthermore changing the language in the upper right dropdown forwards to the wrong place. E.g. when selecting "Francais" the clients directs to:

http://localhost:8282/my/geonetwork/fre/eng/admin.console#/classification/categories

[torse]

Tested on GeoNetwork 3.2.0. Same problem, but different behaviour.

Also, there is now an exception in the log:
2016-10-17 20:56:06,714 ERROR [geonetwork.wro4j] - Error occurred during a wro4j request handling ro.isdc.wro.WroRuntimeException: Cannot build valid CacheKey from request: /my/geonetwork/static/bootstrap-tagsinput.min.js.map at ro.isdc.wro.manager.ResourceBundleProcessor.getSafeCacheKey(ResourceBundleProcessor.java:111) at ro.isdc.wro.manager.ResourceBundleProcessor.serveProcessedBundle(ResourceBundleProcessor.java:61) at ro.isdc.wro.manager.WroManager.process(WroManager.java:159) at ro.isdc.wro.http.WroFilter.processRequest(WroFilter.java:335) at ro.isdc.wro.http.WroFilter.doFilter(WroFilter.java:289) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:186) at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262) at jeeves.config.springutil.JeevesDelegatingFilterProxy.doFilter(JeevesDelegatingFilterProxy.java:104) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:528) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1100) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:687) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2508) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2497) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745)

[fxprunayre]

GeoNetwork does not support that and it does not support root context too. This would require probably quite some work in different places (eg. dataDirectory, harvester, UI resources loader)

[torse]

Thanks for clarification. I was not aware of that as our v2.x installation works fine under a context like "my/catalogue", hence I thought it was a bug/regression. So does this means that GeoNetwork v3 installations must be deployed under "geonetwork" or are other single-word contexs like "catalogue" are supported too?

[fxprunayre]

v2.x installation works fine under a context like "my/catalogue"

Good to know, I was thinking that both root context or custom context was not supported since the beginning.

other single-word contexs

Must be deployed on any single word context. Usually rename the WAR and you're done.

[torse]

Good to know, I was thinking that both root context or custom context was not supported since the beginning.

Well, not sure it was supported but it surely was working.. ;-) IIRC were using it like this since v2.4.

Must be deployed on any single word context. Usually rename the WAR and you're done.

Ok, thanks. I usually prefer to unpack the war and use a tomcat context xml to point to the directory. Using the xml it allows me to add JNDI settings and it's also easier to change the config files..

I'll have to check if we can use a redirect from our old custom endpoint to the new one since we don't want to break existing clients. Otherwise we'll have to stick to v2 I guess.