I made some recent changes to the mock testing in order to support mock requests for the rest stuff. To do so i had to remove the assumption that the ows dispatcher will be handling the request, and use the spring dispatcher, mimicing what actually happens when a true geoserver is running.
It seems that this has broken some of the wcs 1.1 tests. Digging deeper I found that the reason is that the wcs tests do not provide an additional part of the context path ("wcs").
At first I was quite confused to how this was possible. But then I found RequestUtils.setForcedBaseUrl(). I think I understand what it doing, it seems it was added solely for testing purposes? It seems strange to me that a utility class would hold onto state in this matter. Before I suggest an alternative it would be nice to understand all the use cases.
-Justin
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
I made some recent changes to the mock testing in order to support mock requests for the rest stuff. To do so i had to remove the assumption that the ows dispatcher will be handling the request, and use the spring dispatcher, mimicing what actually happens when a true geoserver is running.
It seems that this has broken some of the wcs 1.1 tests. Digging deeper I found that the reason is that the wcs tests do not provide an additional part of the context path ("wcs").
At first I was quite confused to how this was possible. But then I found RequestUtils.setForcedBaseUrl(). I think I understand what it doing, it seems it was added solely for testing purposes? It seems strange to me that a utility class would hold onto state in this matter. Before I suggest an alternative it would be nice to understand all the use cases.
Yes, that's a crude hack I introduced for the sole purpose of testing, I
was getting quite desperate because I could not get the WCS xml side
work, I already wasted a lot of time on failed attempts so I took
the "commando" road and resorted to hacks in order to have stuff working.
As you may know I encoded capabilities and describe coverage responses
using the old xml encoder, the
code to do so is really simple, but unfortunately there is no guarantee
that the result is compliant to the schema, so I needed to check that
in the unit tests.
Now, wcs 1.1.1 schemas are not published online, moreover tests
trying to access them would be intolerably slow anyways (especially
from Europe, the wfs test accessing the online capabilities document
takes some 20 seconds alone over my connection).
So I put the schemas in the module, and did the proxy base hack to make the generated schema location be a relative path that happens
to match the relative path to the schemas on the filesystem, thus
allowing for schema validation.
I'm all for removing the hack, but I need to find a way to keep
on validating those xml against the wcs schemas. I'll look
in alternative ways to perform the same validation.
Cheers
Andrea
Andrea Aime ha scritto:
I'm all for removing the hack, but I need to find a way to keep
on validating those xml against the wcs schemas. I'll look
in alternative ways to perform the same validation.
Ok, this article
https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Validate%20XML%20using%20compiled%20schema
gave me the information I was looking for. I'm updating the
code so that the validation is not performed during dom
construction and in a way that it can use an externally provided
schema (hopefully, I still have to do some checks, but it looks
promising).
Cheers
Andrea
Andrea Aime ha scritto:
Andrea Aime ha scritto:
I'm all for removing the hack, but I need to find a way to keep
on validating those xml against the wcs schemas. I'll look
in alternative ways to perform the same validation.
Ok, this article
https://jaxp.dev.java.net/article/jaxp-1_3-article.html#Validate%20XML%20using%20compiled%20schema
gave me the information I was looking for. I'm updating the
code so that the validation is not performed during dom
construction and in a way that it can use an externally provided
schema (hopefully, I still have to do some checks, but it looks
promising).
Done, things also look a lot more clean than before (nice!).
The build is still not working thought, the GetMapKvpRequestReaderTest.testWmtVer is failing. Maybe some
changes in the dispatcher or in the kvp readers? Don't know,
yet it seems the wmtver parameter is not taken into consideration
anymore. Can you have a look at it?
Cheers
Andrea
Done, things also look a lot more clean than before (nice!).
The build is still not working thought, the GetMapKvpRequestReaderTest.testWmtVer is failing. Maybe some
changes in the dispatcher or in the kvp readers? Don't know,
yet it seems the wmtver parameter is not taken into consideration
anymore. Can you have a look at it?
Cool, checking it out now.
Cheers
Andrea
!DSPAM:4007,47b061ac318691336712104!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com