Hi Justin, ok no prob yep i can file a bug…
in the meantime i have a small workaround for the benefit of the list…
if instead of adding the layer and hoping for an overwrite i issue a request to explicitly change the ‘URL’ property of the coverage store it also changes the underlying reference to the file… but if i ALSO change the ‘description’ element geoserver affects the change without a reload… so ongoing requests to that layer see the change immediately without receiving errors when a config reload was underway. note without changing the description field the url change has no effect until a config reload is done… changing the description is a quick layer-specific reload, and editing the URL of the store via this way keeps it all in one request.
the rest request is therefore:
curl -u admin:xx -v -XPUT -H “Content-type: text/xml” -H “Content-type: text/xml” -d “true12345file:C:\images\image.tif” http://localhost:8080/geoserver/rest/workspaces/noveltis/coveragestores/depart_msg.xml
note that the magical reload of data only occurs if the description is different to before, in our case we use a random number as noone ever sees that field. also enabled sets to false if you dont sent it to true here.
cheers and good evening
-i
···
I don’t think it is intentional no… sounds like a bug, Can you open a jira issue for it. If you could attach some small tif samples that you can reproduce the issue with as well that would be great too.
-Justin
On Mon, Aug 8, 2011 at 7:07 AM, Ivan Price <Ivan.Price@anonymised.com> wrote:
hi there,
we have upgraded a server from 2.0.2 to 2.1.0 and have noticed a change that I’m not sure was intended or is a regression/bug.
previously I have been able to change the definition (=source TIF file) of a coverage with a REST request such as:
curl -u admin:xxx -v -XPUT -H “Content-type: text/plain” -d “file:C:\data\image.tif” http://localhost:8080/geoserver/rest/workspaces/x123/coveragestores/depart_msg/external.geotiff?configure=first&coverageName=depart_msg&coverageTitle=depart_msg
this request creates the data store and layer if they don’t already exist, and in version 2.0.2 it would update their definitions if they did, with subsequent GetMaps returning the new file immediately. In the newer version now though I need to perform a ‘configuration reload’ to get the change affected, which results in a delay that is too long for our application.
deleting and re-adding the coverage works without a reload but again takes longer than we can bear (the update frequency for this is fairly high).
was this intentional, is there a better way to update the source tif file for a given coverage that doesn’t require a whole server config reload?
thanks,
-ivan
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://psf.net/sfu/rim-blackberry-1
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.