Hi,
I was looking around and to my horror I’ve found that the cite compliance field
gets set in the dispatcher only when using the wfs protocol and the
geoserver/wfs path:
**dispatcher**
__dispatcher__
**wfsTestServlet**
Blek… it means that all other service are not covered, and that when using
ows not even wfs is.
I guess that to have this work for all services a significant rework would be
in order?
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Ah, actually this works also for CSW on the geoserver/csw path… but regardless… the way this works
breaks when people use ows, as we cannot statically associate a service class to it…
Cheers
Andrea
···
On Thu, May 1, 2014 at 12:11 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I was looking around and to my horror I’ve found that the cite compliance field
gets set in the dispatcher only when using the wfs protocol and the
geoserver/wfs path:
**dispatcher**
__dispatcher__
**wfsTestServlet**
Blek… it means that all other service are not covered, and that when using
ows not even wfs is.
I guess that to have this work for all services a significant rework would be
in order?
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Hmmm… not sure why it was done that way… maybe because WFS was the only service that needed the cite compliance hacks to pass cite? Not sure. The way it is implemented has other issues as well… it uses a field on the dispatcher itself which totally has concurrency issues… truly a hack as its name indicates 
Perhaps we can do this. Instead of making the CiteComplianceHack class a HandlerINterceptor let’s make it a dispatcher callback. And let’s remove the citeCompliant field from the dispatcher and move it to the Request class. Then the dispatcher callback can set it there.
···
On Thu, May 1, 2014 at 4:12 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Ah, actually this works also for CSW on the geoserver/csw path… but regardless… the way this works
breaks when people use ows, as we cannot statically associate a service class to it…
Cheers
Andrea
“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive
On Thu, May 1, 2014 at 12:11 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
I was looking around and to my horror I’ve found that the cite compliance field
gets set in the dispatcher only when using the wfs protocol and the
geoserver/wfs path:
**dispatcher**
__dispatcher__
**wfsTestServlet**
Blek… it means that all other service are not covered, and that when using
ows not even wfs is.
I guess that to have this work for all services a significant rework would be
in order?
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On Thu, May 1, 2014 at 3:17 PM, Justin Deoliveira <jdeolive@anonymised.com
wrote:
Hmmm... not sure why it was done that way... maybe because WFS was the
only service that needed the cite compliance hacks to pass cite? Not sure.
The way it is implemented has other issues as well... it uses a field on
the dispatcher itself which totally has concurrency issues... truly a hack
as its name indicates
Perhaps we can do this. Instead of making the CiteComplianceHack class a
HandlerINterceptor let's make it a dispatcher callback. And let's remove
the citeCompliant field from the dispatcher and move it to the Request
class. Then the dispatcher callback can set it there.
Maybe we can go one step further and fold this change into this pull
request:
https://github.com/geoserver/geoserver/pull/574
(I'm still working on it, to take into account acceptVersions when the
dispatcher does not get a version and the request is a GetCapabiltiies).
As far as I can see at the end of the day all the flag is doing is to end
up complaining
if service/version params are missing (or just service if the request is a
GetCapabilties).
With the new originalService/originalVersion fields the dispatcher callback
can actually do
all the work, see if the params are missing, if so lookup the service
object, check if the
strict cite compliance is set, and throw the exception
Cheers
Andrea
--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Thu, May 1, 2014 at 11:15 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Thu, May 1, 2014 at 3:17 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Hmmm... not sure why it was done that way... maybe because WFS was the
only service that needed the cite compliance hacks to pass cite? Not sure.
The way it is implemented has other issues as well... it uses a field on
the dispatcher itself which totally has concurrency issues... truly a hack
as its name indicates
Perhaps we can do this. Instead of making the CiteComplianceHack class a
HandlerINterceptor let's make it a dispatcher callback. And let's remove
the citeCompliant field from the dispatcher and move it to the Request
class. Then the dispatcher callback can set it there.
Maybe we can go one step further and fold this change into this pull
request:
https://github.com/geoserver/geoserver/pull/574
(I'm still working on it, to take into account acceptVersions when the
dispatcher does not get a version and the request is a GetCapabiltiies).
Hmmm... not sure if it makes sense to conflate them.
As far as I can see at the end of the day all the flag is doing is to end
up complaining
if service/version params are missing (or just service if the request is a
GetCapabilties).
With the new originalService/originalVersion fields the dispatcher
callback can actually do
all the work, see if the params are missing, if so lookup the service
object, check if the
strict cite compliance is set, and throw the exception
Well at the moment the configuration flag is per service right? The reason
the hack was done like that (as an interceptor) was so that the Dispatcher
could remain ignorant of individual service configuration.
Cheers
Andrea
--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>
On Fri, May 2, 2014 at 4:29 PM, Justin Deoliveira <jdeolive@anonymised.com
wrote:
On Thu, May 1, 2014 at 11:15 AM, Andrea Aime <andrea.aime@anonymised.com
> wrote:
On Thu, May 1, 2014 at 3:17 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Hmmm... not sure why it was done that way... maybe because WFS was the
only service that needed the cite compliance hacks to pass cite? Not sure.
The way it is implemented has other issues as well... it uses a field on
the dispatcher itself which totally has concurrency issues... truly a hack
as its name indicates
Perhaps we can do this. Instead of making the CiteComplianceHack class a
HandlerINterceptor let's make it a dispatcher callback. And let's remove
the citeCompliant field from the dispatcher and move it to the Request
class. Then the dispatcher callback can set it there.
Maybe we can go one step further and fold this change into this pull
request:
https://github.com/geoserver/geoserver/pull/574
(I'm still working on it, to take into account acceptVersions when the
dispatcher does not get a version and the request is a GetCapabiltiies).
Hmmm... not sure if it makes sense to conflate them.
Imho it's the only way forward for capabilities requests, where we don't
have a target version. This way:
* We pick an allowed service version and kvp parsers directly in the
dispatcher
* Do not rely on the capabilities implementation to delegate on older
versions, the way things are implemented
now is that the service running the caps has to know all newer and older
versions and delegate to the right one using
acceptsVersions... some services do it right (wfs), others only partially
(wcs), some not at all (wms).
Since acceptVersions is uniform in all specs, this also removes the need
to code a common part in all services,
we can do it right in a single place
The current broken-ness is not visible only because the CITE tests are not
doing version negotiation checks.
As far as I can see at the end of the day all the flag is doing is to end
up complaining
if service/version params are missing (or just service if the request is
a GetCapabilties).
With the new originalService/originalVersion fields the dispatcher
callback can actually do
all the work, see if the params are missing, if so lookup the service
object, check if the
strict cite compliance is set, and throw the exception
Well at the moment the configuration flag is per service right? The reason
the hack was done like that (as an interceptor) was so that the Dispatcher
could remain ignorant of individual service configuration.
Of course, and the dispatcher callback would pick up the right ServiceInfo
and do the checks leaving the Dispatcher ignorant
Chers
Andrea
--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Fri, May 2, 2014 at 8:41 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:
On Fri, May 2, 2014 at 4:29 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
On Thu, May 1, 2014 at 11:15 AM, Andrea Aime <
andrea.aime@anonymised.com> wrote:
On Thu, May 1, 2014 at 3:17 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Hmmm... not sure why it was done that way... maybe because WFS was the
only service that needed the cite compliance hacks to pass cite? Not sure.
The way it is implemented has other issues as well... it uses a field on
the dispatcher itself which totally has concurrency issues... truly a hack
as its name indicates
Perhaps we can do this. Instead of making the CiteComplianceHack class
a HandlerINterceptor let's make it a dispatcher callback. And let's remove
the citeCompliant field from the dispatcher and move it to the Request
class. Then the dispatcher callback can set it there.
Maybe we can go one step further and fold this change into this pull
request:
https://github.com/geoserver/geoserver/pull/574
(I'm still working on it, to take into account acceptVersions when the
dispatcher does not get a version and the request is a GetCapabiltiies).
Hmmm... not sure if it makes sense to conflate them.
Imho it's the only way forward for capabilities requests, where we don't
have a target version. This way:
* We pick an allowed service version and kvp parsers directly in the
dispatcher
* Do not rely on the capabilities implementation to delegate on older
versions, the way things are implemented
now is that the service running the caps has to know all newer and older
versions and delegate to the right one using
acceptsVersions... some services do it right (wfs), others only
partially (wcs), some not at all (wms).
Since acceptVersions is uniform in all specs, this also removes the need
to code a common part in all services,
we can do it right in a single place
The current broken-ness is not visible only because the CITE tests are not
doing version negotiation checks.
OK, works for me.
As far as I can see at the end of the day all the flag is doing is to
end up complaining
if service/version params are missing (or just service if the request is
a GetCapabilties).
With the new originalService/originalVersion fields the dispatcher
callback can actually do
all the work, see if the params are missing, if so lookup the service
object, check if the
strict cite compliance is set, and throw the exception
Well at the moment the configuration flag is per service right? The
reason the hack was done like that (as an interceptor) was so that the
Dispatcher could remain ignorant of individual service configuration.
Of course, and the dispatcher callback would pick up the right ServiceInfo
and do the checks leaving the Dispatcher ignorant
Chers
Andrea
--
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>