Espero que alguien ya haya descubierto esto. Acabo de instalar Geoserver 2.9 en una distribución vainilla de Ubuntu 16.04. El método Geoserver 2.8 para habilitar CORS con la clase shanbe.hezoun ya no funciona con Jetty 9.2.13.
Se menciona que el soporte CORS ya está empaquetado con Jetty 9.2.13 en jetty-servlets.jar.
El Jetty lib que se compila con Geoserver contiene un jetty-servlet-9.2.13.v20150730.jar en geoserver / lib pero no jetty-servlets.9.2.13.v20150730.jar. ¿Se supone que estos son el mismo frasco con un nombre diferente?
Debería ser posible habilitar CORS en geoserver / etc / webdefault.xml o en geoserver / webapps / geoserver / WEB-INF / web.xml.
Entiendo que webdefault.xml se aplica primero y luego web.xml.
He intentado seguir el filtro en ambos xml. No he llegado tan lejos como para agregar un mapeo de filtro. Agregar el filtro solo hará que el servicio Geoserver / Jetty no se inicie correctamente.
<filter>
<filter-name>cross-origin</filter-name>
<filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
</filter>
Respuestas:
Edita el
webapps/geoserver/WEB-INF/web.xmlarchivo. Hay dos referencias a CORS en este archivo:y
Usted debe descomentar ambos bloques (es decir quitar
<!--y-->de lafilteryfilter-mappingbloques.Luego, cuando reinicie Jetty, puede probar que todo funciona utilizando un comando como:
que si todo está bien dará un resultado como:
Actualización 24 oct.2019
Ya no es necesario agregar el siguiente jar a GeoServer (al menos con las versiones 2.13.xy posteriores) y provocará un error . Dejo esta nota aquí para las personas que luchan contra versiones anteriores.
webapps/geoserver/WEB-INF/libdentro del directorio geoserver-2.15.0 (o donde haya desempaquetado el zip archivo).fuente
find $GEOSERVER_HOME -name "jetty*" | grep -E [[:digit:]].libcarpeta también.Funcionará si agrega el filtro en "geoserver / webapp / geoserver / WEB-INF / web.xml" y si agrega el jar "jetty-servlets.9.2.13.v20150730.jar" dentro "geoserver / webapp / geoserver / WEB-INF / lib "
fuente
con Jetty9, UbuntuServer 16.04, también tuve que modificar /etc/jetty9/start.ini, para no obtener el siguiente error:
la solución está aquí : debe habilitar el módulo de servlets en su $ {jetty.base} /start.ini
en consecuencia, reemplacé:
por:
fuente
La respuesta aceptada de Ian Turton es absolutamente mejor aquí. Como estoy usando la edición manual de Docker no es el caso. Además, no soy un gurú de SED, pero gracias a la estructura de web.xml (las cadenas de destino son únicas en el alcance del documento), se me ocurre un pequeño fragmento:
O en Dockerfile:
fuente
Cualquiera se pregunta qué versión de embarcadero tiene para su aplicación de geoservidor particular.
Para OSX simplemente inicié geoserver y busqué en el registro que debería mostrar algo como:
Estoy seguro de que es similar en los registros de Tomcat cuando se ejecuta desde un servidor Linux si es necesario.
Además, debe ser visible en los encabezados de respuesta, es decir:
Es decir, como la respuesta aceptada menciona intente usar el comando curl, también presentará la versión del servidor:
fuente