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
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.
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
The name of this configuration file is stored in the
wfs.featureTypeList.cfg parameter defined in the deployment descriptor (
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:
<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>
WFSFeatureTypeListDecoder class, an implementatin of
ILcdWFSCapabilitiesProvider is created,
Finally, both the model decoder factory and the capabilities provider are registered in the
WFSCommandDispatcherFactory class, in the methods
createWFSCapabilitiesProvider respectively. This gives the server everything it needs to read data and offer it to the client.
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
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.
<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:
Accept. This is done by setting the
cors.supportedHeaders. See lines 9 through 12. The
added to cope with with Chrome browser bugs.