[Geoserver-devel] Service config object factories

GeoServer GeoServer Developer
1

While working on GEOS-6010 I’ve taken a look at the XStreamServiceLoader and ServiceFactoryExtension classes and their children.

It seems like the two overlap in their ability to create new ServiceInfo objects.

XStreamServiceLoader and its subclasses are replacing a bunch of nulls with default values when deserializing. If those properties should be non-null, then it seems like they should be set to their defaults when a new service is created as well as when being deserialized.

Am I missing something about why it’s set up like this or is this just a case of someone reinventing the wheel?

–
Kevin Smith
Junior Software Developer, OpenGeo
<ksmith@anonymised.com>

2

I have the feeling that that approach was taken before XStream supported the readResolve() initialization.
A pattern I used sometimes for xstream classes is like this:
public class ModelObject{

public ModelObject(){
readResolve();
}

private Object readResolve(){
//initialize instance variables to default values…
return this;
}
}

···

On Mon, Sep 9, 2013 at 8:09 PM, Kevin Smith <ksmith@anonymised.com> wrote:

While working on GEOS-6010 I’ve taken a look at the XStreamServiceLoader and ServiceFactoryExtension classes and their children.

It seems like the two overlap in their ability to create new ServiceInfo objects.

XStreamServiceLoader and its subclasses are replacing a bunch of nulls with default values when deserializing. If those properties should be non-null, then it seems like they should be set to their defaults when a new service is created as well as when being deserialized.

Am I missing something about why it’s set up like this or is this just a case of someone reinventing the wheel?

–
Kevin Smith
Junior Software Developer, OpenGeo
<ksmith@anonymised.com>

How ServiceNow helps IT people transform IT departments:

  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
    http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk

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

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

Yeah, this is a pain with xstream and that it doesn’t use a default constructor when creating an object. As gabriel says i think the only way to centralize that logic would be in readResolve(). Probably never became a big issue because I don’t believe the ServiceFactoryExtension is used all that much?

···

On Tue, Sep 10, 2013 at 8:20 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

I have the feeling that that approach was taken before XStream supported the readResolve() initialization.
A pattern I used sometimes for xstream classes is like this:
public class ModelObject{

public ModelObject(){
readResolve();
}

private Object readResolve(){
//initialize instance variables to default values…
return this;
}
}

How ServiceNow helps IT people transform IT departments:

  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
    http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk

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

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

On Mon, Sep 9, 2013 at 8:09 PM, Kevin Smith <ksmith@anonymised.com> wrote:

While working on GEOS-6010 I’ve taken a look at the XStreamServiceLoader and ServiceFactoryExtension classes and their children.

It seems like the two overlap in their ability to create new ServiceInfo objects.

XStreamServiceLoader and its subclasses are replacing a bunch of nulls with default values when deserializing. If those properties should be non-null, then it seems like they should be set to their defaults when a new service is created as well as when being deserialized.

Am I missing something about why it’s set up like this or is this just a case of someone reinventing the wheel?

–
Kevin Smith
Junior Software Developer, OpenGeo
<ksmith@anonymised.com>

How ServiceNow helps IT people transform IT departments:

  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
    http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk

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

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

For now I’ve just set the initial value of the interpolation property to Nearest in WMSInfoImpl and that was enough to get my fix for 6010 to pass the unit tests.

···

Neither factory method seems to be used much.

org.geoserver.config.util.XStreamServiceLoader.create(GeoServer)

is called by

org.geoserver.data.test.SystemTestData.addService(Class, String, GeoServer)
org.geoserver.jdbcconfig.JDBCGeoServerLoader.loadGeoServer(GeoServer, XStreamPersister)

while

org.geoserver.config.util.XStreamServiceLoader.create(GeoServer)

is called by

org.geoserver.config.impl.GeoServerFactoryImpl.create(Class)

On 10 September 2013 19:56, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yeah, this is a pain with xstream and that it doesn’t use a default constructor when creating an object. As gabriel says i think the only way to centralize that logic would be in readResolve(). Probably never became a big issue because I don’t believe the ServiceFactoryExtension is used all that much?

–
Kevin Smith
Junior Software Developer, OpenGeo
<ksmith@anonymised.com>

On Tue, Sep 10, 2013 at 8:20 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

I have the feeling that that approach was taken before XStream supported the readResolve() initialization.
A pattern I used sometimes for xstream classes is like this:
public class ModelObject{

public ModelObject(){
readResolve();
}

private Object readResolve(){
//initialize instance variables to default values…
return this;
}
}

How ServiceNow helps IT people transform IT departments:

  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
    http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk

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.

On Mon, Sep 9, 2013 at 8:09 PM, Kevin Smith <ksmith@anonymised.com> wrote:

While working on GEOS-6010 I’ve taken a look at the XStreamServiceLoader and ServiceFactoryExtension classes and their children.

It seems like the two overlap in their ability to create new ServiceInfo objects.

XStreamServiceLoader and its subclasses are replacing a bunch of nulls with default values when deserializing. If those properties should be non-null, then it seems like they should be set to their defaults when a new service is created as well as when being deserialized.

Am I missing something about why it’s set up like this or is this just a case of someone reinventing the wheel?

–
Kevin Smith
Junior Software Developer, OpenGeo
<ksmith@anonymised.com>

How ServiceNow helps IT people transform IT departments:

  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
    http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk

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

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.