We ran into issues with our setup and were wondering if anyone has tried something similar and has a solutions to the problem.
We use a proxy in front of our GeoServer instance(s), disabled Global Services and only allow access to our virtual service base url (geoserver/virtual/*) through our proxy access rules. This work quite good for standard use cases. However some resources such as schemas and Openlayers (maybe others as well?) are not available below the virtual base url but only under the global context. As a result at least the schema links in response documents and the application/openlayers output format for virtual WMS is not working due to 404 errors on at least:
geoserver/virtual/openlayers/OpenLayers.js
geoserver/virtual/options.png
geoserver/virtual/www/inspire_vs.xsd
geoserver/virtual/schemas/wms/1.3.0/exceptions_1_3_0.xsd
The log is full of “No Mapping found for HTTP request with URI …” warnings.
To reproduce this behavior, use the plain geoserver-2.3-RC1 war, goto workspaces, select any workspace, enable settings, enter any proxy url (http://whatever/virtual) and then open the openlayers preview for any datasets in this workspace. You will see in the page source that the Openlayers.js is requested from http://whatever/virtual/openlayers/Openlayers.js.
As we like to keep using virtual service behind a proxy, I was wondering if the global contexts (or at least a subset) could additionally be published below the virtual services contexts, e.g. throught the dispatcher servlet or web.xml?
As we like to keep using virtual service behind a proxy, I was wondering if the global contexts (or at least a subset) could additionally be published below the virtual services contexts, e.g. throught the dispatcher servlet or web.xml?
The resources you’re citing are served directly from the classpath using the FilePublisher class, which is bound
to them in the spring context.
In order to have that work also for virtual workspaces I guess some sort I guess the url mappings
in the spring context for the classpathPublisher should also use the GeoServer custom
org.geoserver.ows.OWSHandlerMapping instead of Spring’s own
org.springframework.web.servlet.handler.SimpleUrlHandlerMapping
The change would likely have to happen in main module, applicationContext.xml, around line 150 to 170.
However, I’m not sure if there are any side effects from doing that.
Thanks for the hint, Andrea. I’ve changed the mapping class in main.jar/applicationContext.xml and added “/openlayers/**” like this:
filePublisher
filePublisher
filePublisher
Now, when requesting “/nurc/www/openlayers/theme/default/style.css” the response is a 404 and the logs says:
05 Mar 17:01:31 TRACE [ows.OWSHandlerMapping] - No handler mapping found for [/nurc/www/openlayers/theme/default/style.css]
05 Mar 17:01:31 DEBUG [ows.OWSHandlerMapping] - Matching patterns for request [/www/openlayers/theme/default/style.css] are [/www/**]
05 Mar 17:01:31 DEBUG [ows.OWSHandlerMapping] - URI Template variables for request [/www/openlayers/theme/default/style.css] are {}
05 Mar 17:01:31 DEBUG [ows.OWSHandlerMapping] - Mapping [/nurc/www/openlayers/theme/default/style.css] to HandlerExecutionChain with handler [org.geoserver.ows.FilePublisher@anonymised.com] and 1 interceptor
05 Mar 17:01:31 DEBUG [filter.GeoServerSecurityContextPersistenceFilter$1] - SecurityContextHolder now cleared, as request processing completed
It looks like the the OWSHandlerMapping class strips the workspace name (line 2) from the request but than maps the full name with workspace name to the FilePublisher (line 4). I’ve also tested “/nurc/openlayers/theme/default/style.css” with similar result. Furthermore I’ve copied the www/openlayers directory to workspaces/nurc/openlayers and workspaces/nurc/www/openlayers for test purposes but get back a 404 as well.
As we like to keep using virtual service behind a proxy, I was wondering if the global contexts (or at least a subset) could additionally be published below the virtual services contexts, e.g. throught the dispatcher servlet or web.xml?
The resources you’re citing are served directly from the classpath using the FilePublisher class, which is bound
to them in the spring context.
In order to have that work also for virtual workspaces I guess some sort I guess the url mappings
in the spring context for the classpathPublisher should also use the GeoServer custom
org.geoserver.ows.OWSHandlerMapping instead of Spring’s own
org.springframework.web.servlet.handler.SimpleUrlHandlerMapping
The change would likely have to happen in main module, applicationContext.xml, around line 150 to 170.
However, I’m not sure if there are any side effects from doing that.
Thanks for the hint, Andrea. I’ve changed the mapping class in main.jar/applicationContext.xml and added “/openlayers/**” like this:
filePublisher
filePublisher
filePublisher
Now, when requesting “/nurc/www/openlayers/theme/default/style.css” the response is a 404 and the logs says:
05 Mar 17:01:31 TRACE [ows.OWSHandlerMapping] - No handler mapping found for [/nurc/www/openlayers/theme/default/style.css]
05 Mar 17:01:31 DEBUG [ows.OWSHandlerMapping] - Matching patterns for request [/www/openlayers/theme/default/style.css] are [/www/**]
05 Mar 17:01:31 DEBUG [ows.OWSHandlerMapping] - URI Template variables for request [/www/openlayers/theme/default/style.css] are {}
05 Mar 17:01:31 DEBUG [ows.OWSHandlerMapping] - Mapping [/nurc/www/openlayers/theme/default/style.css] to HandlerExecutionChain with handler [org.geoserver.ows.FilePublisher@anonymised.com] and 1 interceptor
05 Mar 17:01:31 DEBUG [filter.GeoServerSecurityContextPersistenceFilter$1] - SecurityContextHolder now cleared, as request processing completed
It looks like the the OWSHandlerMapping class strips the workspace name (line 2) from the request but than maps the full name with workspace name to the FilePublisher (line 4). I’ve also tested “/nurc/openlayers/theme/default/style.css” with similar result. Furthermore I’ve copied the www/openlayers directory to workspaces/nurc/openlayers and workspaces/nurc/www/openlayers for test purposes but get back a 404 as well.
Am I missing something?
Nothing really, I was just trying a shot in the dark, I guess this needs more investigation.
I don’t have anything else to suggest without actually looking into it myself too.