The samples.ogc.wfs.server package contains a sample that illustrates how to configure a WFS server through the API. The main entry point in the API for getting started is the class ALcdOGCWFSCommandDispatcherFactory, which is used during server startup to initialize a WFS. The sample provides an implementation WFSCommandDispatcherFactory that illustrates how to configure the WFS data sources, described in Configuration of data sources, and how to add new output formats next to GML, described in Add output formats. Finally, CORS configuration for a RIA development environment shows how to configure a WFS server to enable cross origin requests for use in a RIA environment.

Configuration of data sources

The sample server is configured with support for reading SHP and GML data from files.

This is done by implementing a model decoder factory (ILcdOGCModelDecoderFactory) that can create the LuciadLightspeed decoders for these formats. The TLcdOGCModelDecoderFactory implementation uses the service loader (TLcdServiceLoader) to pick up model decoders. If needed, a custom implementation can be used.

The data files that have to be served by the sample server, the feature types, are listed in the XML configuration file wfs.featureTypeList.xml. The name of this configuration file is stored in the wfs.featureTypeList.cfg parameter defined in the deployment descriptor (web.xml). The sample class WFSFeatureTypeListDecoder can decode this file and generate a list of WFS feature types from its contents.

The implementation fetches the value of the wfs.featureTypeList.cfg parameter from web.xml, and then parses the XML file specified by this value. Each <FeatureType> element in the file specifies a unique feature type name and a path to a SHP or GML file. For instance, these are the contents of the feature type list file included with the sample:

Program: A sample feature type list
<FeatureTypeList>
  <FeatureType name="cities">data/Shp/Usa/city_125.shp</FeatureType>
  <FeatureType name="rivers">data/Shp/Usa/rivers.shp</FeatureType>
  <FeatureType name="counties">data/Shp/Usa/counties.shp</FeatureType>
</FeatureTypeList>

Using the WFSFeatureTypeListDecoder class, an implementatin of ILcdWFSCapabilitiesProvider is created, WFSCapabilitiesProvider.

Finally, both the model decoder factory and the capabilities provider are registered in the WFSCommandDispatcherFactory class, in the methods createModelDecoderFactory and createWFSCapabilitiesProvider respectively. This gives the server everything it needs to read data and offer it to the client.

Add output formats

By definition, the WFS server uses GML as default exchange format towards clients. This does not require any action from the developer configuring the WFS.

If you require other data exchange formats, you need to register their encoders through the API. The sample server illustrates this by adding support for the GeoJSON format, which is popular in a RIA environment, and is typically better suited to be supported by web clients. You can register encoders by implementing a client model encoder factory (ILcdWFSClientModelEncoderFactory) that can create the LuciadLightspeed encoder for the GeoJSON format. This is illustrated in the sample class WFSClientModelEncoderFactory. Finally, register the client model encoder factory with the WFSCommandDispatcherFactory class in the method createClientModelEncoderFactory.

CORS configuration for a RIA development environment

The sample server is configured to allow cross origin requests in a development environment. In this development environment, the developer’s computer runs two servers; one WFS server and a RIA server that hosts the web application. The RIA server hosts the web application on port 8072.

The WFS server’s deployment descriptor is shown in Program: CORS configuration in web.xml. The CORS filter is defined on lines 1-13 and applied to the WFS servlet on lines 15-18.

Program: CORS configuration in web.xml
<filter>
  <filter-name>CORSFilter</filter-name>
  <filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class>

  <init-param>
	<param-name>cors.allowOrigin</param-name>
	<param-value>http://localhost:8072</param-value>
  </init-param>
  <init-param>
	<param-name>cors.supportedHeaders</param-name>
	<param-value>X-Requested-With, Content-Type, Origin, Accept</param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name>CORSFilter</filter-name>
  <servlet-name>wfs</servlet-name>
</filter-mapping>

The CORS filter configures two parameters. First, only web applications that are hosted on the same computer, localhost, on a server that listens on port 8072 are allowed to access the server. See lines 5 through 8. Note that this restriction only applies to web applications, running in a web browser.

Secondly, the client is allowed to send the following HTTP headers to the WFS server: X-Requested-With, Content-Type, Origin, Accept. This is done by setting the cors.supportedHeaders. See lines 9 through 12. The X-Requested-With header is a header that is often automatically added by JavaScript libraries such as dojo or jQuery. The other headers are added to cope with with Chrome browser bugs.