Mind, even if the data dir reading gets addressed, the change will still break REST clients. The above attribute structure is only present sometimes in the serialized data dir, but it's always present in the REST output for feature type resources, e.g.:
So REST client relying on this information will be broken on upgrade. I don't think we had a "migration guide" for GeoServer in years, but this time it will be unavoidable. Bummer...
Yeah, it has been resolved via documentation update + release notes.
Jody Garnett
October 2, 2018 at 4:32 PM
can this be marked resolved?
Torben Barsballe
September 19, 2018 at 12:43 AM
Yep, that was my original plan, but I thought I'd mention the options available.
Jody Garnett
September 19, 2018 at 12:38 AM
Think we should stick with your PR as written.
Torben Barsballe
September 19, 2018 at 12:37 AM
I was just thinking the JTS classes. Doing everything would be both a (even more) substantial API change, and a rather more significant amount of work. In a perfect world, that seems like the best approach, but for this release it seems like its just borrowing more trouble.
As Andrea has noted on discussion of GEOS-8884:
Mind, even if the data dir reading gets addressed, the change will still break REST clients. The above attribute structure is only present sometimes in the serialized data dir, but it's always present in the REST output for feature type resources, e.g.:
So REST client relying on this information will be broken on upgrade. I don't think we had a
"migration guide" for GeoServer in years, but this time it will be unavoidable. Bummer...