Hi,
as you many know every now and then we get reports of strange errors in KVP
requests, which end up tracing back to the caller not specifying the version and
service for the requests.
We normally just tell people to add those and be on their way, however, given
that we allow invalid requests for leniency and backwards compatibility, we should
at least be consistent about them.
This pull request dusts off a previous attempt at solving the problem, and it’s targeted
for trunk:
https://github.com/geoserver/geoserver/pull/574
Basically, it runs service/version recognition, and eventual heuristics used in case
they are not set, before doing KVP parsing, so that KVP parsers bound to a specific
service/version can recognize the context and either be chosen, or be excluded
from the KVP parse.
Anyone wants to review?
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
Looked it over and made some comments. Basically I am thinking we want to run this through the cite tests before merging. If all that goes ok the change looks good to me.
Related to cite is what I think are some actual recent breakages. I was debugging the failures on the build server and they seemed legitimate. Next step is to run the tests locally to confirm but I haven’t got around to that.
···
On Sun, Apr 27, 2014 at 8:14 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
as you many know every now and then we get reports of strange errors in KVP
requests, which end up tracing back to the caller not specifying the version and
service for the requests.
We normally just tell people to add those and be on their way, however, given
that we allow invalid requests for leniency and backwards compatibility, we should
at least be consistent about them.
This pull request dusts off a previous attempt at solving the problem, and it’s targeted
for trunk:
https://github.com/geoserver/geoserver/pull/574
Basically, it runs service/version recognition, and eventual heuristics used in case
they are not set, before doing KVP parsing, so that KVP parsers bound to a specific
service/version can recognize the context and either be chosen, or be excluded
from the KVP parse.
Anyone wants to review?
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
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
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 Mon, Apr 28, 2014 at 4:41 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Looked it over and made some comments. Basically I am thinking we want to
run this through the cite tests before merging. If all that goes ok the
change looks good to me.
Related to cite is what I think are some actual recent breakages. I was
debugging the failures on the build server and they seemed legitimate. Next
step is to run the tests locally to confirm but I haven't got around to
that.
Ah... to be honest, CITE tests have been failing on an off so often in the
last months
that I stopped looking at failures... maybe I'm not the only one 
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 Mon, Apr 28, 2014 at 8:49 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Mon, Apr 28, 2014 at 4:41 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Looked it over and made some comments. Basically I am thinking we want to
run this through the cite tests before merging. If all that goes ok the
change looks good to me.
Related to cite is what I think are some actual recent breakages. I was
debugging the failures on the build server and they seemed legitimate. Next
step is to run the tests locally to confirm but I haven't got around to
that.
Ah... to be honest, CITE tests have been failing on an off so often in the
last months
that I stopped looking at failures... maybe I'm not the only one
Well if this is the case then maybe we should deactivate them? It a very
brittle setup that is to be sure, but i am not sure what to do about that.
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 Mon, Apr 28, 2014 at 4:56 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
On Mon, Apr 28, 2014 at 8:49 AM, Andrea Aime <andrea.aime@anonymised.com
> wrote:
On Mon, Apr 28, 2014 at 4:41 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Looked it over and made some comments. Basically I am thinking we want
to run this through the cite tests before merging. If all that goes ok the
change looks good to me.
Related to cite is what I think are some actual recent breakages. I was
debugging the failures on the build server and they seemed legitimate. Next
step is to run the tests locally to confirm but I haven't got around to
that.
Ah... to be honest, CITE tests have been failing on an off so often in
the last months
that I stopped looking at failures... maybe I'm not the only one
Well if this is the case then maybe we should deactivate them? It a very
brittle setup that is to be sure, but i am not sure what to do about that.
That would be a negative reaction. Let's try a positive one:
* Fix the cite tests and make sure it's working on our local boxes (I can
help)
* Make sure the tests are reliable on the build server... how do we do
this? I basically stopped looking because I have had the impression
the builds on the servers are not reliable, although time ago (a year+)
they were... wondering what changed?
Or maybe it is just a wrong impression of mine?
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 Mon, Apr 28, 2014 at 8:59 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Mon, Apr 28, 2014 at 4:56 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
On Mon, Apr 28, 2014 at 8:49 AM, Andrea Aime <
andrea.aime@anonymised.com> wrote:
On Mon, Apr 28, 2014 at 4:41 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
Looked it over and made some comments. Basically I am thinking we want
to run this through the cite tests before merging. If all that goes ok the
change looks good to me.
Related to cite is what I think are some actual recent breakages. I was
debugging the failures on the build server and they seemed legitimate. Next
step is to run the tests locally to confirm but I haven't got around to
that.
Ah... to be honest, CITE tests have been failing on an off so often in
the last months
that I stopped looking at failures... maybe I'm not the only one
Well if this is the case then maybe we should deactivate them? It a very
brittle setup that is to be sure, but i am not sure what to do about that.
That would be a negative reaction. Let's try a positive one:
* Fix the cite tests and make sure it's working on our local boxes (I can
help)
* Make sure the tests are reliable on the build server... how do we do
this? I basically stopped looking because I have had the impression
the builds on the servers are not reliable, although time ago (a year+)
they were... wondering what changed?
Or maybe it is just a wrong impression of mine?
I am not sure if you are referring to builds in general or just the cite
builds. I wouldn't say the cite builds have ever been that reliable, the
entire test engine they are based upon is pretty brittle imo, and on top of
that we are applying hacks to make it runnable in an automated way.
Anyways, unfortunately I don't have the capacity to hand hold the cite
builds as much as they need, or as much as i would like. Given that we have
multiple organizations hosting build servers perhaps someone else wants to
take a crack at making them more reliable.
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>