Hi,
today I stumbled upon an apparent limitation in output format
handling in geoserver trunk.
To summarize for people not knowing about the new dispatch system,
a service is pure java class, and the service call are method
calls on that class. Each method returns an object that
gets encoded by an output format.
Each output formats is registered in the Spring context, and binds itself to a result class, plus has the ability to say whether
it can really handle a certain result by analyzing the request
too. This allows for the wfs getfeature hits output format to avoid
handling a request that asked for a GML output.
This is problematic in my case, because I'm creating a new operation,
GetLog, that returns a feature collection, but it's not a GetFeature!
The code in the GML output formats looks like:
public final boolean canHandle(Operation operation) {
//GetFeature operation?
if ("GetFeature".equalsIgnoreCase(operation.getId())
|| "GetFeatureWithLock".equalsIgnoreCase(operation.getId())) {
//also check that the resultType is "results"
GetFeatureType request = (GetFeatureType) OwsUtils.parameter(operation.getParameters(),
GetFeatureType.class);
...
well, in my case the operation is GetLog, and the parameter is a GetLogType (GetLogType is a class that represents the requests, it's
been generated from the XML schema).
So, apparently I'll have to code subclasses of the GML outputs in
order to handle GetLog outputs... this is not good imho.
A better way would be for service objects to specify the econding
in the resulting object, and have the output formats inspect only
the output object to decide whether they want to handle it, or not.
I understand this is a little of a problem since also the result
classes are generated from xml schema. So we either hand modify
them (should not be a big issue, ain't it?) to add a format parameter,
or we put the output format in the request chain "environment",
for example, in a thread local, for output formats to pick.
What do you think?
Cheers
Andrea