GeoServer
  1. GeoServer
  2. GEOS-510

FeatureType configuration not saving properly

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.3.0 RC7
    • Fix Version/s: None
    • Component/s: Configuration
    • Labels:
      None
    • Environment:
      Win XP, Geoserver RC7 backed by Postgis
    • Number of attachments :
      0

      Description

      When editing a featureType, 2 things seem to always get reset and seem to sometimes work:

      1. The Schema Base field seems to sometimes go back to "-" even though one was in fact chosen from the drop down and saved.
      This shows up incorrectly after changing it, aplying, saving, and loading the changes then going to the describeFeatureType demo request.

      2. A geometry attribute set to pointPropertyType in the config is sometimes returned in the describeFeatureType demo request as type="gml:pointProperty" and other times correctly as type="gml:pointPropertyType"
      WFS handlers in geotools expect pointPropertyType and have trouble otherwise.

      Right now a random sequence of 'apply', 'save', and 'load' in the geoserver config will result in the correct feature type description being returned with both points #1 & 2 correctly set

        Activity

        Hide
        Justin Deoliveira added a comment -

        Scheduling for 1.3.1

        Show
        Justin Deoliveira added a comment - Scheduling for 1.3.1
        Hide
        Amr A. Alam added a comment -

        It appears that the problem with the Schema Base field not holding it's value is the cause of point #2. After saving the correct Schema Base value geoserver returns the correct data upon request.

        Restarting geoserver again causes it to lose this configuration, and I've had to go through that process of setting and saving the value yet again.

        Show
        Amr A. Alam added a comment - It appears that the problem with the Schema Base field not holding it's value is the cause of point #2. After saving the correct Schema Base value geoserver returns the correct data upon request. Restarting geoserver again causes it to lose this configuration, and I've had to go through that process of setting and saving the value yet again.
        Hide
        dblasby added a comment -

        There are several issues with specifying a custom schema. Any changes to this portion of geoserver is going to take a lot of testing!

        Show
        dblasby added a comment - There are several issues with specifying a custom schema. Any changes to this portion of geoserver is going to take a lot of testing!
        Hide
        Brent Owens added a comment -

        The actual problem is when the schema is saved out to disk and reloaded. If you just apply the changes, it works. But saving to disk writes out the schema incorrectly. So when you hit 'load' or just restart the server, then the incorrect schema is loaded from disk.

        A temporary workaround is to configure your schema in the web-admin tool, go to the demos page and use the describeFeatureType demo, copy the output from that and paste it into the schema.xml file for your FeatureType. This way when you restart the server, the correct output is there.

        Show
        Brent Owens added a comment - The actual problem is when the schema is saved out to disk and reloaded. If you just apply the changes, it works. But saving to disk writes out the schema incorrectly. So when you hit 'load' or just restart the server, then the incorrect schema is loaded from disk. A temporary workaround is to configure your schema in the web-admin tool, go to the demos page and use the describeFeatureType demo, copy the output from that and paste it into the schema.xml file for your FeatureType. This way when you restart the server, the correct output is there.
        Hide
        Brent Owens added a comment -

        This one will take a fair amount of work and testing and I'm not sure we can make it in time for 1.5.0

        Show
        Brent Owens added a comment - This one will take a fair amount of work and testing and I'm not sure we can make it in time for 1.5.0
        Hide
        Gabriel Roldan added a comment -

        closing as won't fix, reported against 1.6.x, which is long dead version and superceed by 2.0.x

        Show
        Gabriel Roldan added a comment - closing as won't fix, reported against 1.6.x, which is long dead version and superceed by 2.0.x

          People

          • Assignee:
            Gabriel Roldan
            Reporter:
            Amr A. Alam
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: