David Vick and I spoke about this this morning and he thought the
annotation-driven elements in the context shouldn't be necessary. I
tried removing them from the GWC stand alone context but that produced a
slew of 404 errors in the integration tests.
On 2017-10-09 03:03 AM, Alessio Fabiani wrote
See responses inline
Regards,
Alessio Fabiani
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==
Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 9
On Fri, Oct 6, 2017 at 6:16 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:
> We ought to just be using context:component-scan everywhere (without
> mvc:annotation-driven) if GWC is not doing that, then that is probably an
> error.
>
I was just discussing it with Alessio this morning,
I noticed that GWC still makes use of this annotation-driven support, is
> there the possibility to get rid of it? Another issue I'm facing with this
> customization is that at startup GeoServer do not automatically redirects
> to the Wicket GUI but to the GWC homepage instead.
We ought to just b
Update on GeoWebCache REST and Web Context conflicts...
JVM needs to start with the following option
-Dgwc.context.suffix=gwc
Regards,
Alessio Fabiani
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==
Ing. Alessio Fabiani
@alfa7691
Fo
This simple hack will fix the issue
String resource = Paths.get(*URLEncoder.encode(request.getPathInfo(),
"UTF-8")*).getFileName().toString();
Regards,
Alessio Fabiani
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==
Ing. Alessio Fabiani
The GWC home page redirect issue still remains, by the way.
Regards,
Alessio Fabiani
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==
Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054
Ok, so, after further investigation I should have got the cause of the
issue.
Basically this happens when the Monitoring plugin is installed, in
particular here
https://github.com/geoserver/geoserver/blob/3518cdb07ec159c1ac365fc8583da7ff4b9da89b/src/extension/monitor/core/src/main/java/org/geoser
This is currently the customization causing that issue
https://github.com/GeoNode/geoserver-geonode-ext
I had to rewrite the community plugin by removing everywhere
"", otherwise there wasn't the possibility to let
it working.
I noticed that GWC still makes use of this annotation-driven support,
Oh, maybe is this the cause?
java.nio.file.InvalidPathException: Illegal char <:> at index 19:
/sldservice/geonode:san_andres_y_providencia_administrative/attributes.xml
at sun.nio.fs.*WindowsPathParser*.normalize(Unknown Source)
Regards,
Alessio Fabiani
==
GeoServer Professional Services fro
Hi Torben,
are you sure? Maybe it is a problem of my setup then, since with GeoServer
2.12.x I get the following
http://localhost:8080/geoserver/rest/layers/geonode:san_andres_y_providencia_administrative.json
Illegal char <:> at index 15:
/layers/geonode:san_andres_y_providencia_administrative.j
Hi Alessio,
Have you actually tried either of these functionalities out yourself? They
both work fine.
In Spring, ":" is treated like any other character, leading to a layerName
of "geosolutions:my_layer". The geoserver catalog already has the necessary
functionality to parse the workspace out of
Dear all,
with the latest porting to Spring MVC I noticed a potential issue on
Request Mappings.
Long story short with the current definition [
http://localhost:8080/geoserver/layers/{layerName}/styles] of PathVariables
requests like the following ones
http://localhost:8080/geoserver/layers/geoso
13 matches
Mail list logo
