|
|
|
Issue Type:
|
 Bug
|
|
Affects Versions:
|
2.2.5
|
|
Assignee:
|
Andrea Aime
|
|
Components:
|
Configuration
|
|
Created:
|
12/Mar/13 1:31 PM
|
|
Description:
|
in the current code base we have three properties that LayerInfoImpl tries to keep in synch between
the layer and the resource:
Having them in synch is pretty important, as LayerInfo is used only by WMS, whilst WFS and WCS
use the underlying resource.
Also, the AdvertisedCatalog (which used to be a filter in previous releases) use the advertised
flag of the resources to decide whether to return them.
Unfortunately it seems that any attempt to edit enabled and advertised will result in the data stored
on disk to get inconsistent, with the layer.xml containing what we edited on the GUI, but the
resource xml file (featuretype.xml, wmsLayer.xml, coverage.xml) will have a enabled and advertised
flags that almost seem random, but are never consistent with the layer ones.
Debugged the issue, and tracked down the problem to how we save stuff:
- the resource get saved, and stored on disk
- the layer gets saved on disk, then the modification proxy does the commit,
LayerInfoImpl tries to synch the resource, but it’s too late
Tried to invert the way things are saved, first layer then resource, but that does not change a thing,
since the layer has a direct reference to ResourceInfo (no modification proxy),
while the save subsystem looks at the properties modified via a ModificationProxy.
Then I looked at why name is always in synch instead… and saw it’s because:
- the name is edited directly against the resource
- the layer does not have a name attribute, it just reflects the resource one
Well, I guess we could do the same for enabled and advertised…
|
|
Fix Versions:
|
2.2.6
|
|
Project:
|
GeoServer
|
|
Priority:
|
 Major
|
|
Reporter:
|
Andrea Aime
|
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your [JIRA administrators](https://jira.codehaus.org/secure/ContactAdministrators!default.jspa)
For more information on JIRA, see: [http://www.atlassian.com/software/jira](http://www.atlassian.com/software/jira)