Hi,
I'm facing a nasty issue. The kvp parsers do match the key they are going to parse just by name.
In geoserver trunk there is the unfortunate case where two kvp parsers
match the same key (acceptVersions) but do need to produce two
different objects, AcceptVersionsType from ows 1.0 and the one from ows 1.1. They are identical, but the other differences between the two
ows vesions are so big that one cannot be used to represent the other.
In my case this breaks the WCS 1.1.1 requests, but a different classpath
order would break the WCS 1.1.0 requests the same way.
It would be nice if the the kvp parsers could allow for a parser to be service and version specific, but unfortunately kvp parsing
occurs before the service is determined (it is required to determine
the service, in fact).
Solutions that come to mind:
* do a kvp pre-parse just to determine service and version
then to the actual kvp parsing providing the kvp parser
both service and version. Service and version may not be there
so have the kvp parsers deal with that possibility (a generic
kvp parser may be able to work anyways, others might be
service specific and not work in that occasion). This is mainly
to handle mixed requests like wms ones or the wfs with the
strict=true extra param
* run all the kvp parser, and make the kvp map a
Map<String, List<Object>> where the list contains all possible
results, and then try each one to see if they can be
set in the request objects (this happens automatically thru
EMF reflection in the KvpRequestReader class)
Any other idea?
Cheers
Andrea
I think I would prefer option #1. 2 seems a bit loose for me. I think the ability to bind a kvp parser to a particular version/service/request is something that will come up more and more as we add more versions of existing services.
It might be a bit more tricky than it looks though. For instance how to we handle the case of multiple parsers being attached top the same kvp. Does the more specific one (the one that declares more than just the name) engage?
-Justin
Andrea Aime wrote:
Hi,
I'm facing a nasty issue. The kvp parsers do match the key they are going to parse just by name.
In geoserver trunk there is the unfortunate case where two kvp parsers
match the same key (acceptVersions) but do need to produce two
different objects, AcceptVersionsType from ows 1.0 and the one from ows 1.1. They are identical, but the other differences between the two
ows vesions are so big that one cannot be used to represent the other.
In my case this breaks the WCS 1.1.1 requests, but a different classpath
order would break the WCS 1.1.0 requests the same way.
It would be nice if the the kvp parsers could allow for a parser to be service and version specific, but unfortunately kvp parsing
occurs before the service is determined (it is required to determine
the service, in fact).
Solutions that come to mind:
* do a kvp pre-parse just to determine service and version
then to the actual kvp parsing providing the kvp parser
both service and version. Service and version may not be there
so have the kvp parsers deal with that possibility (a generic
kvp parser may be able to work anyways, others might be
service specific and not work in that occasion). This is mainly
to handle mixed requests like wms ones or the wfs with the
strict=true extra param
* run all the kvp parser, and make the kvp map a
Map<String, List<Object>> where the list contains all possible
results, and then try each one to see if they can be
set in the request objects (this happens automatically thru
EMF reflection in the KvpRequestReader class)
Any other idea?
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,47a1f44a87695409313003!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
I think I would prefer option #1. 2 seems a bit loose for me. I think the ability to bind a kvp parser to a particular version/service/request is something that will come up more and more as we add more versions of existing services.
It might be a bit more tricky than it looks though. For instance how to we handle the case of multiple parsers being attached top the same kvp. Does the more specific one (the one that declares more than just the name) engage?
Maybe we don't need generic kvp parser beans at all. We have generic kvp parser classes, but as long as you don't declare them as beans in the application context, they are not going to engage. And when you declare them, you can declare them providing a service/version pair.
How does this sound.
Cheers
Andrea