[Geoserver-devel] rest config code review

GeoServer GeoServer Developer
1

Hi all,

I spent this last week looking at the rest config module in preparation in moving it toward supported. First off I want to say I really like restlet, and in particular the framework David has set up in GeoServer. It is quite easy to use and understand. That said I do think there is room for improvement. Here are some of the higher level things i have come up with.

* Old Configuration / Catalog API

All the code is written against the deprecated configuration api. A while back when I did an initial review I brought this up and the response was that this would be something we would look at when moving rest config to supported, but for the purposes of experimentation we would just write against the old api. Well that time has come.

In my opinion the code should work against the new api. I don't think it makes a lot of sense to release the code when we know it will need a major overhaul shortly after. Now at first thought this would require a lot of work, however i have some other suggestions below that will save a lot of the work.

* Reflection vs Maps

Currently "resources" in rest config all extend from a generic class called MapResource. MapResource works by having subclasses transform an object (say a FeatureTypeInfo) into a map, and vice versa.

While this approach is straight forward and simple I think a reflection based approach would result in a lot less code. Especially for the new catalog and configuration interfaces. We all ready have a bunch of reflection utility classes (used by the ows dispatcher and xml parsers). And Andrea even made them fast by introducing a cache.

Anyways, I think having a MapResource around is definitely useful for some cases, but I think another base class called something like "ReflectiveResource" would also be useful.

* Serialization and De-serialization via XML and JSON

An even bigger win with the reflective approach would be the serialization/de-serialization as XML and JSON via xstream. We already has code that does this as part of saving the configuration as xml with xstream. The exact same code can also be used to serialize as json with one flag set. So that basically means we don't have to write any custom serialization or de-serialization code. It also has the nice side-effect that when we output a resource via rest, it matches how we save the resource to disk.

* Freemarker Templates for HTML output

Currently when a resource is serialized as html it uses a built-in template. I think it makes sense to make this customizable for users with our fancy template system. I don't think this will be too much work. Basically just configure the template configuration used by FreemarkerFormat to use the GeoServerTemplateLoader to find a template, and fall back on the built-in templates.

Thats it for now :).

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

Justin,

all good suggestions.

We are using the RESTful API intensively now with 1.7.1 and it’s working well with a one exception that we should keep in mind going forward.

If you look in RESTUtils in the reloadconfiguration() method, you’ll notice that the update config portion is left out. The code (taken from the loadGeoserver() method of org.vfny.geoserver.action.LoadXMLAction) was not copied over because the config objects come from the ServletContext (not available in the RESTlet). I’m hoping the “new” catalogue API won’t have this limitation (of being tightly coupled to the web app). Anyway as a result we’re losing some configuration data after a shapefile upload.

In the meantime does anyone know a workaround to get the config (global, data, wcs, wfs, and wms) reloaded without making an HTTP call to the admin webapp (that won’t be available for us in production.

On Sun, Jan 11, 2009 at 2:20 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I spent this last week looking at the rest config module in preparation
in moving it toward supported. First off I want to say I really like
restlet, and in particular the framework David has set up in GeoServer.
It is quite easy to use and understand. That said I do think there is
room for improvement. Here are some of the higher level things i have
come up with.

  • Old Configuration / Catalog API

All the code is written against the deprecated configuration api. A
while back when I did an initial review I brought this up and the
response was that this would be something we would look at when moving
rest config to supported, but for the purposes of experimentation we
would just write against the old api. Well that time has come.

In my opinion the code should work against the new api. I don’t think it
makes a lot of sense to release the code when we know it will need a
major overhaul shortly after. Now at first thought this would require a
lot of work, however i have some other suggestions below that will save
a lot of the work.

  • Reflection vs Maps

Currently “resources” in rest config all extend from a generic class
called MapResource. MapResource works by having subclasses transform an
object (say a FeatureTypeInfo) into a map, and vice versa.

While this approach is straight forward and simple I think a reflection
based approach would result in a lot less code. Especially for the new
catalog and configuration interfaces. We all ready have a bunch of
reflection utility classes (used by the ows dispatcher and xml parsers).
And Andrea even made them fast by introducing a cache.

Anyways, I think having a MapResource around is definitely useful for
some cases, but I think another base class called something like
“ReflectiveResource” would also be useful.

  • Serialization and De-serialization via XML and JSON

An even bigger win with the reflective approach would be the
serialization/de-serialization as XML and JSON via xstream. We already
has code that does this as part of saving the configuration as xml with
xstream. The exact same code can also be used to serialize as json with
one flag set. So that basically means we don’t have to write any custom
serialization or de-serialization code. It also has the nice side-effect
that when we output a resource via rest, it matches how we save the
resource to disk.

  • Freemarker Templates for HTML output

Currently when a resource is serialized as html it uses a built-in
template. I think it makes sense to make this customizable for users
with our fancy template system. I don’t think this will be too much
work. Basically just configure the template configuration used by
FreemarkerFormat to use the GeoServerTemplateLoader to find a template,
and fall back on the built-in templates.

Thats it for now :).

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Hi Sam,

Thanks for the feedback. I agree it looks like an explicit update to the "config" objects is missing. What type of information is being lost on shapefile upload? Unless I am mistaken not updating the config objects should only affect the UI.

-Justin

Sam Brodkin wrote:

Justin,

all good suggestions.

We are using the RESTful API intensively now with 1.7.1 and it's working well with a one exception that we should keep in mind going forward.

If you look in RESTUtils in the reloadconfiguration() method, you'll notice that the update config portion is left out. The code (taken from the loadGeoserver() method of org.vfny.geoserver.action.LoadXMLAction) was not copied over because the config objects come from the ServletContext (not available in the RESTlet). I'm hoping the "new" catalogue API won't have this limitation (of being tightly coupled to the web app). Anyway as a result we're losing some configuration data after a shapefile upload.

In the meantime does anyone know a workaround to get the config (global, data, wcs, wfs, and wms) reloaded without making an HTTP call to the admin webapp (that won't be available for us in production.

On Sun, Jan 11, 2009 at 2:20 AM, Justin Deoliveira <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:

    Hi all,

    I spent this last week looking at the rest config module in preparation
    in moving it toward supported. First off I want to say I really like
    restlet, and in particular the framework David has set up in GeoServer.
    It is quite easy to use and understand. That said I do think there is
    room for improvement. Here are some of the higher level things i have
    come up with.

    * Old Configuration / Catalog API

    All the code is written against the deprecated configuration api. A
    while back when I did an initial review I brought this up and the
    response was that this would be something we would look at when moving
    rest config to supported, but for the purposes of experimentation we
    would just write against the old api. Well that time has come.

    In my opinion the code should work against the new api. I don't think it
    makes a lot of sense to release the code when we know it will need a
    major overhaul shortly after. Now at first thought this would require a
    lot of work, however i have some other suggestions below that will save
    a lot of the work.

    * Reflection vs Maps

    Currently "resources" in rest config all extend from a generic class
    called MapResource. MapResource works by having subclasses transform an
    object (say a FeatureTypeInfo) into a map, and vice versa.

    While this approach is straight forward and simple I think a reflection
    based approach would result in a lot less code. Especially for the new
    catalog and configuration interfaces. We all ready have a bunch of
    reflection utility classes (used by the ows dispatcher and xml parsers).
    And Andrea even made them fast by introducing a cache.

    Anyways, I think having a MapResource around is definitely useful for
    some cases, but I think another base class called something like
    "ReflectiveResource" would also be useful.

    * Serialization and De-serialization via XML and JSON

    An even bigger win with the reflective approach would be the
    serialization/de-serialization as XML and JSON via xstream. We already
    has code that does this as part of saving the configuration as xml with
    xstream. The exact same code can also be used to serialize as json with
    one flag set. So that basically means we don't have to write any custom
    serialization or de-serialization code. It also has the nice side-effect
    that when we output a resource via rest, it matches how we save the
    resource to disk.

    * Freemarker Templates for HTML output

    Currently when a resource is serialized as html it uses a built-in
    template. I think it makes sense to make this customizable for users
    with our fancy template system. I don't think this will be too much
    work. Basically just configure the template configuration used by
    FreemarkerFormat to use the GeoServerTemplateLoader to find a template,
    and fall back on the built-in templates.

    Thats it for now :).

    -Justin

    --
    Justin Deoliveira
    OpenGeo - http://opengeo.org
    Enterprise support for open source geospatial.

    ------------------------------------------------------------------------------
    Check out the new SourceForge.net Marketplace.
    It is the best place to buy or sell services for
    just about anything Open Source.
    http://p.sf.net/sfu/Xq1LFB
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

On Sat, 2009-01-10 at 18:20 -0700, Justin Deoliveira wrote:

Hi all,

I spent this last week looking at the rest config module in preparation
in moving it toward supported. First off I want to say I really like
restlet, and in particular the framework David has set up in GeoServer.
It is quite easy to use and understand. That said I do think there is
room for improvement. Here are some of the higher level things i have
come up with.

* Old Configuration / Catalog API

All the code is written against the deprecated configuration api. A
while back when I did an initial review I brought this up and the
response was that this would be something we would look at when moving
rest config to supported, but for the purposes of experimentation we
would just write against the old api. Well that time has come.

In my opinion the code should work against the new api. I don't think it
makes a lot of sense to release the code when we know it will need a
major overhaul shortly after. Now at first thought this would require a
lot of work, however i have some other suggestions below that will save
a lot of the work.

* Reflection vs Maps

Currently "resources" in rest config all extend from a generic class
called MapResource. MapResource works by having subclasses transform an
object (say a FeatureTypeInfo) into a map, and vice versa.

While this approach is straight forward and simple I think a reflection
based approach would result in a lot less code. Especially for the new
catalog and configuration interfaces. We all ready have a bunch of
reflection utility classes (used by the ows dispatcher and xml parsers).
And Andrea even made them fast by introducing a cache.

While such a resource would probably be useful in a quick release, I am
not sure it should be used in the final version of the API. For
example, the current API proposal specifies the path to a datastore as:
/workspaces/{wsid}/datastores/{dsid}

Since workspaces are equivalent to namespaces (for the time being) we
should exclude the namespace from the returned representation of the
datastore. Similarly, redundant info such as the lat/long vs. native
bounds for featuretypes should be omitted (so we don't have deal with
self-inconsistent representations).

If we use a reflective implementation of the resources, I assume we will
be either exposing all attributes of configuration objects, or
blacklisting attributes to be hidden. I think it would be more safe
against future changes to the GeoServer catalog API to continue to use a
whitelist approach.

Anyways, I think having a MapResource around is definitely useful for
some cases, but I think another base class called something like
"ReflectiveResource" would also be useful.

* Serialization and De-serialization via XML and JSON

An even bigger win with the reflective approach would be the
serialization/de-serialization as XML and JSON via xstream. We already
has code that does this as part of saving the configuration as xml with
xstream. The exact same code can also be used to serialize as json with
one flag set. So that basically means we don't have to write any custom
serialization or de-serialization code. It also has the nice side-effect
that when we output a resource via rest, it matches how we save the
resource to disk.

* Freemarker Templates for HTML output

Currently when a resource is serialized as html it uses a built-in
template. I think it makes sense to make this customizable for users
with our fancy template system. I don't think this will be too much
work. Basically just configure the template configuration used by
FreemarkerFormat to use the GeoServerTemplateLoader to find a template,
and fall back on the built-in templates.

I don't see a use case for this. Could you elaborate on why this would
be a good feature to have?

Thats it for now :).

-Justin

5

* Reflection vs Maps

Currently "resources" in rest config all extend from a generic class called MapResource. MapResource works by having subclasses transform an object (say a FeatureTypeInfo) into a map, and vice versa.

While this approach is straight forward and simple I think a reflection based approach would result in a lot less code. Especially for the new catalog and configuration interfaces. We all ready have a bunch of reflection utility classes (used by the ows dispatcher and xml parsers). And Andrea even made them fast by introducing a cache.

While such a resource would probably be useful in a quick release, I am
not sure it should be used in the final version of the API. For
example, the current API proposal specifies the path to a datastore as:
/workspaces/{wsid}/datastores/{dsid}

Since workspaces are equivalent to namespaces (for the time being) we
should exclude the namespace from the returned representation of the
datastore. Similarly, redundant info such as the lat/long vs. native
bounds for featuretypes should be omitted (so we don't have deal with
self-inconsistent representations).

I don't quite understand. What i am taking about is populating an object reflectively from a xml/json representation. For instance say someone POST's the following to /workspaces

<workspace>
   <name>foo</name>
</workspace>

I should be able to create a Workspace object reflectively without having to 1) write some dom code to read it 2) create a map from the dom 3) create a workspace object from the map

And similar for a GET on /workspaces/foo. It would be nice to be able to go straight from workspace object to XML.

If we use a reflective implementation of the resources, I assume we will
be either exposing all attributes of configuration objects, or
blacklisting attributes to be hidden. I think it would be more safe
against future changes to the GeoServer catalog API to continue to use a
whitelist approach.

I agree that we have to be careful about making changes to objects and how that affects the "automatic" serialized output since its our api. But I think a good set of test cases would solve this.

I see the point but I see the same situation developing here as with the persisting of the old config system. Specifically that whenever we add a property to a config object, we have to update the config object, the reader, and the writer. This sort of duplication of work has seriously discouraged maintainance of that subsystem in the past.

Also to add serialization and de-serialization of xstream is highly configurable. So we have full control over what output looks like if we want.

Anyways, I think having a MapResource around is definitely useful for some cases, but I think another base class called something like "ReflectiveResource" would also be useful.

* Freemarker Templates for HTML output

Currently when a resource is serialized as html it uses a built-in template. I think it makes sense to make this customizable for users with our fancy template system. I don't think this will be too much work. Basically just configure the template configuration used by FreemarkerFormat to use the GeoServerTemplateLoader to find a template, and fall back on the built-in templates.

I don't see a use case for this. Could you elaborate on why this would
be a good feature to have?

The use case is the same as any other "customization" use case in GeoServer. Why do we provide templates for wms getFeatureInfo output?

Thats it for now :).

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

> Since workspaces are equivalent to namespaces (for the time being) we
> should exclude the namespace from the returned representation of the
> datastore. Similarly, redundant info such as the lat/long vs. native
> bounds for featuretypes should be omitted (so we don't have deal with
> self-inconsistent representations).
I don't quite understand. What i am taking about is populating an object
reflectively from a xml/json representation. For instance say someone
POST's the following to /workspaces

<workspace>
   <name>foo</name>
</workspace>

I should be able to create a Workspace object reflectively without
having to 1) write some dom code to read it 2) create a map from the dom
3) create a workspace object from the map

The name should not be a part of the representation of a workspace; this
is exactly the type of duplication of information I am talking about.
What happens when someone updates the workspace configuration by doing a

PUT /workspaces/foo

<workspace>
    <name>bar</name>
</workspace>

?

This should be implemented as a POST request with just the namespace URI
in the body, and an HTTP header named 'Slug' (as used in Atom pub) to
specify the desired name.

Does that clarify the concern I had?

And similar for a GET on /workspaces/foo. It would be nice to be able to
go straight from workspace object to XML.

>
> If we use a reflective implementation of the resources, I assume we will
> be either exposing all attributes of configuration objects, or
> blacklisting attributes to be hidden. I think it would be more safe
> against future changes to the GeoServer catalog API to continue to use a
> whitelist approach.
I agree that we have to be careful about making changes to objects and
how that affects the "automatic" serialized output since its our api.
But I think a good set of test cases would solve this.

I see the point but I see the same situation developing here as with the
persisting of the old config system. Specifically that whenever we add a
property to a config object, we have to update the config object, the
reader, and the writer. This sort of duplication of work has seriously
discouraged maintainance of that subsystem in the past.

Also to add serialization and de-serialization of xstream is highly
configurable. So we have full control over what output looks like if we
want.
>
>> Anyways, I think having a MapResource around is definitely useful for
>> some cases, but I think another base class called something like
>> "ReflectiveResource" would also be useful.
>>

>>
>> * Freemarker Templates for HTML output
>>
>> Currently when a resource is serialized as html it uses a built-in
>> template. I think it makes sense to make this customizable for users
>> with our fancy template system. I don't think this will be too much
>> work. Basically just configure the template configuration used by
>> FreemarkerFormat to use the GeoServerTemplateLoader to find a template,
>> and fall back on the built-in templates.
>
> I don't see a use case for this. Could you elaborate on why this would
> be a good feature to have?
>
The use case is the same as any other "customization" use case in
GeoServer. Why do we provide templates for wms getFeatureInfo output?

Well, the difference is that the HTML output should ideally be another
means of editing the configuration, so customizing it seems like a
headache.

>> Thats it for now :).
>>
>> -Justin
>>
>

7

The name should not be a part of the representation of a workspace; this
is exactly the type of duplication of information I am talking about.
What happens when someone updates the workspace configuration by doing a

PUT /workspaces/foo

<workspace>
    <name>bar</name>
</workspace>

Is there a way in a PUT to change or redirect where the resulting resource (after modified) will be? If not I guess the answer would be to ignore the name attribute or send back a 403 or something.

?

This should be implemented as a POST request with just the namespace URI
in the body, and an HTTP header named 'Slug' (as used in Atom pub) to
specify the desired name.

Does that clarify the concern I had?

Maybe "name" was a bad example since its used to identify a workspace. But replace name with a normal attribute and my initial argument is the same.

Aside I don't understand if a POST to /workspaces specifying the name is not allowed then how do I create a new workspace? I see no reference to the use of a header in rest configuration api proposal. All i see is that that a POST to /workspaces should create the new workspace, and set the Location header in the response which specifies the path to the new resource. Perhaps I am missing something.

And similar for a GET on /workspaces/foo. It would be nice to be able to go straight from workspace object to XML.

If we use a reflective implementation of the resources, I assume we will
be either exposing all attributes of configuration objects, or
blacklisting attributes to be hidden. I think it would be more safe
against future changes to the GeoServer catalog API to continue to use a
whitelist approach.

I agree that we have to be careful about making changes to objects and how that affects the "automatic" serialized output since its our api. But I think a good set of test cases would solve this.

I see the point but I see the same situation developing here as with the persisting of the old config system. Specifically that whenever we add a property to a config object, we have to update the config object, the reader, and the writer. This sort of duplication of work has seriously discouraged maintainance of that subsystem in the past.

Also to add serialization and de-serialization of xstream is highly configurable. So we have full control over what output looks like if we want.

Anyways, I think having a MapResource around is definitely useful for some cases, but I think another base class called something like "ReflectiveResource" would also be useful.

* Freemarker Templates for HTML output

Currently when a resource is serialized as html it uses a built-in template. I think it makes sense to make this customizable for users with our fancy template system. I don't think this will be too much work. Basically just configure the template configuration used by FreemarkerFormat to use the GeoServerTemplateLoader to find a template, and fall back on the built-in templates.

I don't see a use case for this. Could you elaborate on why this would
be a good feature to have?

The use case is the same as any other "customization" use case in GeoServer. Why do we provide templates for wms getFeatureInfo output?

Well, the difference is that the HTML output should ideally be another
means of editing the configuration, so customizing it seems like a
headache.

Thats it for now :).

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

8

On Mon, 2009-01-12 at 09:52 -0700, Justin Deoliveira wrote:

>
> The name should not be a part of the representation of a workspace; this
> is exactly the type of duplication of information I am talking about.
> What happens when someone updates the workspace configuration by doing a
>
> PUT /workspaces/foo
>
> <workspace>
> <name>bar</name>
> </workspace>

Is there a way in a PUT to change or redirect where the resulting
resource (after modified) will be? If not I guess the answer would be to
ignore the name attribute or send back a 403 or something.
>
> ?
>
> This should be implemented as a POST request with just the namespace URI
> in the body, and an HTTP header named 'Slug' (as used in Atom pub) to
> specify the desired name.
>
> Does that clarify the concern I had?

Maybe "name" was a bad example since its used to identify a workspace.
But replace name with a normal attribute and my initial argument is the
same.

Aside I don't understand if a POST to /workspaces specifying the name is
not allowed then how do I create a new workspace? I see no reference to
the use of a header in rest configuration api proposal. All i see is
that that a POST to /workspaces should create the new workspace, and set
the Location header in the response which specifies the path to the new
resource. Perhaps I am missing something.

Indeed, there is no mention of the actual representations in either the
documentation of the current API or the proposal for the new one. This
is something I have been meaning to address, but I haven't written
anything up yet. The 'Slug' header in particular is something that only
came to my attention this weekend, but it seems like a reasonably
standard means of naming things POSTed to a collection.

>
>> And similar for a GET on /workspaces/foo. It would be nice to be able to
>> go straight from workspace object to XML.
>>
>>> If we use a reflective implementation of the resources, I assume we will
>>> be either exposing all attributes of configuration objects, or
>>> blacklisting attributes to be hidden. I think it would be more safe
>>> against future changes to the GeoServer catalog API to continue to use a
>>> whitelist approach.
>> I agree that we have to be careful about making changes to objects and
>> how that affects the "automatic" serialized output since its our api.
>> But I think a good set of test cases would solve this.
>>
>> I see the point but I see the same situation developing here as with the
>> persisting of the old config system. Specifically that whenever we add a
>> property to a config object, we have to update the config object, the
>> reader, and the writer. This sort of duplication of work has seriously
>> discouraged maintainance of that subsystem in the past.
>>
>> Also to add serialization and de-serialization of xstream is highly
>> configurable. So we have full control over what output looks like if we
>> want.
>>>> Anyways, I think having a MapResource around is definitely useful for
>>>> some cases, but I think another base class called something like
>>>> "ReflectiveResource" would also be useful.
>>>>
>>>> * Freemarker Templates for HTML output
>>>>
>>>> Currently when a resource is serialized as html it uses a built-in
>>>> template. I think it makes sense to make this customizable for users
>>>> with our fancy template system. I don't think this will be too much
>>>> work. Basically just configure the template configuration used by
>>>> FreemarkerFormat to use the GeoServerTemplateLoader to find a template,
>>>> and fall back on the built-in templates.
>>> I don't see a use case for this. Could you elaborate on why this would
>>> be a good feature to have?
>>>
>> The use case is the same as any other "customization" use case in
>> GeoServer. Why do we provide templates for wms getFeatureInfo output?
>
> Well, the difference is that the HTML output should ideally be another
> means of editing the configuration, so customizing it seems like a
> headache.
>
>>>> Thats it for now :).
>>>>
>>>> -Justin
>>>>
>>
>

9

Justin, if you add base maps (in the admin app → config | WMS | Contents) these are lost without the update config portion of reloadconfiguration(). It is basically what is stored in the services.xml file in the geoserver data dir.

On Mon, Jan 12, 2009 at 4:00 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Sam,

Thanks for the feedback. I agree it looks like an explicit update to the “config” objects is missing. What type of information is being lost on shapefile upload? Unless I am mistaken not updating the config objects should only affect the UI.

-Justin

Sam Brodkin wrote:

Justin,

all good suggestions.
We are using the RESTful API intensively now with 1.7.1 and it’s working well with a one exception that we should keep in mind going forward.
If you look in RESTUtils in the reloadconfiguration() method, you’ll notice that the update config portion is left out. The code (taken from the loadGeoserver() method of org.vfny.geoserver.action.LoadXMLAction) was not copied over because the config objects come from the ServletContext (not available in the RESTlet). I’m hoping the “new” catalogue API won’t have this limitation (of being tightly coupled to the web app). Anyway as a result we’re losing some configuration data after a shapefile upload.

In the meantime does anyone know a workaround to get the config (global, data, wcs, wfs, and wms) reloaded without making an HTTP call to the admin webapp (that won’t be available for us in production.