[Geoserver-users] GeoServer rest calls not enabling layers

joel · November 20, 2014, 12:28am

Hi all,

I’m attempting to write a small python script that will enable all of my layers. To do this, I’m making a call to the REST API through curl, like so:

curl -v -u username:password -XPUT -H “Content-type: text/xml” -d “layer_name_heretrue” “http://localhost:8080/geoserver/rest/layers/layer_name_here”

This isn’t enabling the layer as I thought it would. I’ve tried various combinations of inserting the workspace before the layer name, but nothing seems to be working. Curl is always giving back an HTTP 200 (OK), which you’d think means that it successfully enabled the layer. I’ve ramped up the logging to show almost absolutely everything, and I noticed the following:

19 Nov 17:15:37 DEBUG [catalog.impl] - Warning, some code is setting the LayerInfo name, but that will be ignored
19 Nov 17:15:37 DEBUG [catalog.impl] - Warning, some code is setting the LayerInfo enabled flag, but that will be ignored
19 Nov 17:15:37 DEBUG [catalog.impl] - Warning, some code is setting the LayerInfo advertised flag, but that will be ignored
19 Nov 17:15:37 DEBUG [gwc.layer] - Handling modify event for LayerInfoImpl[layer_name_here, resource:CoverageInfoImpl[layer_name_here]]
19 Nov 17:15:37 DEBUG [geoserver.config] - Persisted $Proxy33 to global.xml
19 Nov 17:15:37 DEBUG [geoserver.config] - Persisting layer layer_name_here
19 Nov 17:15:37 DEBUG [geoserver.config] - Persisted org.geoserver.catalog.impl.LayerInfoImpl to workspaces/Workspace_here/layer_name_here/layer.xml
19 Nov 17:15:37 INFO [catalog.rest] - PUT layer layer_name_here
19 Nov 17:15:37 DEBUG [org.geoserver] - Thread 557 releasing the lock in mode WRITE
19 Nov 17:15:37 DEBUG [filter.GeoServerSecurityContextPersistenceFilter$1] - SecurityContextHolder now cleared, as request processing completed

It seems like it may be very closely related to this problem: http://sourceforge.net/p/geoserver/mailman/message/30703372/ Has anyone seen this before, or have any idea how to go about fixing it? Does this essentially mean that I’ll have to crawl the file system and manually edit each xml file?

Joel

Chris_Snider · November 20, 2014, 4:04pm

Hi,

This is an example of the XML we posted for adding a style/enabling a layer:

#{props.geoserverHostname} – The HostName/IP Address GeoServer is listening on

#{props.geoserverPortNum} – The port GeoServer is listening on

#{props.geoserverWorkspace} – Workspace containing the layer

#{style} – Style name to post against

VERB: PUT

URL: https://#{props.geoserverHostname}:#{props.geoserverPortNum}/geoserver/rest/layers/#{props.geoserverWorkspace}:#{style}

Contents:

STYLE_NAME_HERE

false

true

LAYER_NAME_HERE

If you are only attempting to enable a layer

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, Inc.

···

Hi all,

I’m attempting to write a small python script that will enable all of my layers. To do this, I’m making a call to the REST API through curl, like so:

curl -v -u username:password -XPUT -H “Content-type: text/xml” -d “layer_name_heretrue” “http://localhost:8080/geoserver/rest/layers/layer_name_here”

This isn’t enabling the layer as I thought it would. I’ve tried various combinations of inserting the workspace before the layer name, but nothing seems to be working. Curl is always giving back an HTTP 200 (OK), which you’d think means that it successfully enabled the layer. I’ve ramped up the logging to show almost absolutely everything, and I noticed the following:

19 Nov 17:15:37 DEBUG [catalog.impl] - Warning, some code is setting the LayerInfo name, but that will be ignored
19 Nov 17:15:37 DEBUG [catalog.impl] - Warning, some code is setting the LayerInfo enabled flag, but that will be ignored
19 Nov 17:15:37 DEBUG [catalog.impl] - Warning, some code is setting the LayerInfo advertised flag, but that will be ignored
19 Nov 17:15:37 DEBUG [gwc.layer] - Handling modify event for LayerInfoImpl[layer_name_here, resource:CoverageInfoImpl[layer_name_here]]
19 Nov 17:15:37 DEBUG [geoserver.config] - Persisted $Proxy33 to global.xml
19 Nov 17:15:37 DEBUG [geoserver.config] - Persisting layer layer_name_here
19 Nov 17:15:37 DEBUG [geoserver.config] - Persisted org.geoserver.catalog.impl.LayerInfoImpl to workspaces/Workspace_here/layer_name_here/layer.xml
19 Nov 17:15:37 INFO [catalog.rest] - PUT layer layer_name_here
19 Nov 17:15:37 DEBUG [org.geoserver] - Thread 557 releasing the lock in mode WRITE
19 Nov 17:15:37 DEBUG [filter.GeoServerSecurityContextPersistenceFilter$1] - SecurityContextHolder now cleared, as request processing completed

It seems like it may be very closely related to this problem: http://sourceforge.net/p/geoserver/mailman/message/30703372/ Has anyone seen this before, or have any idea how to go about fixing it? Does this essentially mean that I’ll have to crawl the file system and manually edit each xml file?

Joel