Error loading style after migration to 2.27 version

GeoServer GeoServer User
1

Hi there,

I am trying to migrate one of my GeoServer instance from 2.26 to 2.27, using geoserver docker image.

When starting 2.27 version, I have the following errors for several of my styles:

Style Argile_style[StyleInfoImpl--291f85b:1916a4c80c5:-5bf9] should have workspace qdn but has workspace qdn. Style ignored.

The XML for the style looks like this:

<style>
<id>StyleInfoImpl--291f85b:1916a4c80c5:-5bf9</id>
<name>Argile_style</name>
<workspace>
<name>qdn</name>
</workspace>
<format>sld</format>
<languageVersion>
<version>1.0.0</version>
</languageVersion>
<filename>Argile_style.sld</filename>
<dateCreated>2024-09-11 09:19:30.69 UTC</dateCreated>
<dateModified>2024-09-11 09:19:30.72 UTC</dateModified>
</style>

Any idea how to solve this? Should I raise a bug?

Alexandre

2

Apparently, related to the new catalog loader.

3

Did you manage to get it to work by disabling the new catalog loader? There’s an option to do that.

Peter

4

Hi Peter.

I couldn’t find it until now. Could you please point me to the documentation page?

Alexandre

5

That’s the style.xml, but it refers the workspace by name, rather than by identifier?
Here is how a properly formatted local workspace style should look like:

<style>
  <id>StyleInfoImpl-1c443fee:182c0f3f209:-7fe4</id>
  <name>boundary_lines</name>
  <workspace>
    <id>WorkspaceInfoImpl-1c443fee:182c0f3f209:-7ffe</id>
  </workspace>
  <format>sld</format>
  <languageVersion>
    <version>1.0.0</version>
  </languageVersion>
  <filename>boundary_lines.sld</filename>
  <dateCreated>2022-08-21 15:51:20.414 UTC</dateCreated>
  <dateModified>2022-09-26 06:50:09.485 UTC</dateModified>
</style>

How did you get the workspace to use a name tag instead… hand writing the XML files, or some other way?

Cheers
Andrea

6

Hello Andrea,

These style definitions have been created by the Backup/Restore extension. On the original environment, I have the expected definition but we used the extension to transfer the configuration to the production environment.

Alexandre

7

The upgrade instructions mention the variable:
https://docs.geoserver.org/main/en/user/installation/upgrade.html#faster-startup-for-large-catalogs-geoserver-2-27-and-newer

Cheers
Andrea

1 Like
8

Hi Alexandre,
backup/restore is a community module, not an extension (hence, it’s unsupported).

In its current state it indeed replaces ids with names during the process, and that can be a serious issue
If the workspace is renamed there, the style will lose the reference to its original workspace… the reason why we use ids (immutable) is that we don’t need to go and find all pointers to an object when it gets modified.

Given this, backup/restore can be used to transfer a data dir from one environment to another, assuming it won’t be touched in the destination, but not really as a “backup and restore” facility (as in, in place).

That said, the new data dir loader should be able to transparently load what the old was able to, so I’d suggest talking to Gabriel about the issue you’re seeing.

Cheers
Andrea

9

Hello Andrea,

Thanks for the link to the documentation!

For the backup/restore, I know its a community extension. I plan to change how I transfer configuration between environments in a near future.

Alexandre