[Geoserver-devel] REST not working on master (but cannot figure out why)

Andrea_Aime4 · May 5, 2019, 3:28pm

Hi,
I was fiddling with a bug report and noticed that the REST API seems completely bricked on master,
any GET request apparently results in a 406, it matches the controller and produces a result, but then
fails to find a converter to generate the results.

Debugging I’ve noticed that the ResConfig class (in gs-rest) is called and registers all of our custom
converters (for HTML, XML, JSON and so on), which are then properly set in a RequestMappingHandlerAdapter
that is being instantianced inside WebMvcConfigurationSupport and returned as a bean in the spring context
(the method in question is a bean factory), but then, by the time the requests are executed, the code
uses another instance of RequestMappingHandlerAdapter that does not have any of the converters we want.

During the startup I’ve noticed up to 4 RequestMappingHandlerAdapter being created, but I’m not sure how
they are getting wired… sort of seems like a routing issue to me, but I’m getting lost in details.

Another thing that I’ve noticed, is that the issue is not happening in 2.15.x, and that it can be reproduced with
a vanilla bin download of the master series, as well as a master bin download of April 29th (the oldest available
on the build server).

Finally, the build is passing, so the rest config module seems to be working fine on its own, which makes me think
about something related to wiring…

Does the above ring any bell to any you?

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Andrea_Aime4 · May 6, 2019, 6:25am

Hi,
finally figured out why: mapml

Some days ago a commit was made in web/app/pom.xml that included mapml as a direct dependency.
Chris, you probably have noticed that web/app depends on community modules only by means of a profile, a
core module should never depend on an unsupported, out of release build community module.

I’ve just committed a change to fix that.

Also, the mapml module is one breaking the REST API, even after the change, including it via “-Pmapml”
profile makes the REST API return 406 to all requests.
I’m guessing it’s due to the spring annotation usage and component scan declarations in the module
(which also the rest modules use). I did not investigate the details, not sure what exactly causes the problem,
but you probably want to either:

fix the issue quickly
push the module out of the nightly build
clearly document the issue at the top of the mapml module documentation in big bold chars (https://docs.geoserver.org/latest/en/user/community/mapml/index.html)
so that random users trying it out won’t have to pull hairs trying to figure out why the REST config API does not work anymore.

Cheers

Andrea

···

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Chris_Hodgson · May 7, 2019, 4:20pm

Ack. My apologies, that change to web/app/pom.xml was never intended to be committed and was only there to support my local testing.

Sorry I couldn’t respond more quickly, we were out of internet all day yesterday due to a major fire a block away (luckily it seems that no-one was injured).

The problem is that the mapml xml spring webmvc config is re-creating and overriding the webmvc config setup by the rest module. I’ve never used spring webmvc in this kind of plugin environment before so I didn’t realize this could happen. I am working on a fix now. By the end of day I will either commit a fix or remove the module from the daily build until I have fix ready.

Again, my apologies for breaking this and making you track it down.

Chris

···

On 5/5/2019 11:25 PM, Andrea Aime wrote:

Hi,
finally figured out why: mapml

Some days ago a commit was made in web/app/pom.xml that included mapml as a direct dependency.
Chris, you probably have noticed that web/app depends on community modules only by means of a profile, a
core module should never depend on an unsupported, out of release build community module.

I’ve just committed a change to fix that.

Also, the mapml module is one breaking the REST API, even after the change, including it via “-Pmapml”
profile makes the REST API return 406 to all requests.
I’m guessing it’s due to the spring annotation usage and component scan declarations in the module
(which also the rest modules use). I did not investigate the details, not sure what exactly causes the problem,
but you probably want to either:

fix the issue quickly

push the module out of the nightly build

clearly document the issue at the top of the mapml module documentation in big bold chars (https://docs.geoserver.org/latest/en/user/community/mapml/index.html)
so that random users trying it out won’t have to pull hairs trying to figure out why the REST config API does not work anymore.

Cheers

Andrea

On Sun, May 5, 2019 at 5:28 PM Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I was fiddling with a bug report and noticed that the REST API seems completely bricked on master,
any GET request apparently results in a 406, it matches the controller and produces a result, but then
fails to find a converter to generate the results.

Debugging I’ve noticed that the ResConfig class (in gs-rest) is called and registers all of our custom
converters (for HTML, XML, JSON and so on), which are then properly set in a RequestMappingHandlerAdapter
that is being instantianced inside WebMvcConfigurationSupport and returned as a bean in the spring context
(the method in question is a bean factory), but then, by the time the requests are executed, the code
uses another instance of RequestMappingHandlerAdapter that does not have any of the converters we want.

During the startup I’ve noticed up to 4 RequestMappingHandlerAdapter being created, but I’m not sure how
they are getting wired… sort of seems like a routing issue to me, but I’m getting lost in details.

Another thing that I’ve noticed, is that the issue is not happening in 2.15.x, and that it can be reproduced with
a vanilla bin download of the master series, as well as a master bin download of April 29th (the oldest available
on the build server).

Finally, the build is passing, so the rest config module seems to be working fine on its own, which makes me think
about something related to wiring…

Does the above ring any bell to any you?

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

–

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

-- 
Chris Hodgson
Refractions Research
Suite 419 – 1207 Douglas Street
Victoria, British Columbia
Canada, V8W 2E7
1-250-383-3022
[http://www.refractions.net](http://www.refractions.net)

Chris_Hodgson · May 7, 2019, 6:36pm

I’ve committed a fix which makes use of the BaseMessageConverter extension point provided by the Geoserver REST module. It seems to allow the REST and MapML modules to both work at the same time, however, I have not thoroughly tested either, and I would appreciate it if someone more familiar with the REST module could try it with -Pmapml enabled.

Chris

···

On 5/7/2019 9:20 AM, Chris Hodgson wrote:

Ack. My apologies, that change to web/app/pom.xml was never intended to be committed and was only there to support my local testing.

Sorry I couldn’t respond more quickly, we were out of internet all day yesterday due to a major fire a block away (luckily it seems that no-one was injured).

The problem is that the mapml xml spring webmvc config is re-creating and overriding the webmvc config setup by the rest module. I’ve never used spring webmvc in this kind of plugin environment before so I didn’t realize this could happen. I am working on a fix now. By the end of day I will either commit a fix or remove the module from the daily build until I have fix ready.

Again, my apologies for breaking this and making you track it down.

Chris

-- 
Chris Hodgson
Refractions Research
Suite 419 – 1207 Douglas Street
Victoria, British Columbia
Canada, V8W 2E7
1-250-383-3022
[http://www.refractions.net](http://www.refractions.net)

On 5/5/2019 11:25 PM, Andrea Aime wrote:

Hi,
finally figured out why: mapml

Some days ago a commit was made in web/app/pom.xml that included mapml as a direct dependency.
Chris, you probably have noticed that web/app depends on community modules only by means of a profile, a
core module should never depend on an unsupported, out of release build community module.

I’ve just committed a change to fix that.

Also, the mapml module is one breaking the REST API, even after the change, including it via “-Pmapml”
profile makes the REST API return 406 to all requests.
I’m guessing it’s due to the spring annotation usage and component scan declarations in the module
(which also the rest modules use). I did not investigate the details, not sure what exactly causes the problem,
but you probably want to either:

fix the issue quickly

push the module out of the nightly build

clearly document the issue at the top of the mapml module documentation in big bold chars (https://docs.geoserver.org/latest/en/user/community/mapml/index.html)
so that random users trying it out won’t have to pull hairs trying to figure out why the REST config API does not work anymore.

Cheers

Andrea

On Sun, May 5, 2019 at 5:28 PM Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I was fiddling with a bug report and noticed that the REST API seems completely bricked on master,
any GET request apparently results in a 406, it matches the controller and produces a result, but then
fails to find a converter to generate the results.

Debugging I’ve noticed that the ResConfig class (in gs-rest) is called and registers all of our custom
converters (for HTML, XML, JSON and so on), which are then properly set in a RequestMappingHandlerAdapter
that is being instantianced inside WebMvcConfigurationSupport and returned as a bean in the spring context
(the method in question is a bean factory), but then, by the time the requests are executed, the code
uses another instance of RequestMappingHandlerAdapter that does not have any of the converters we want.

During the startup I’ve noticed up to 4 RequestMappingHandlerAdapter being created, but I’m not sure how
they are getting wired… sort of seems like a routing issue to me, but I’m getting lost in details.

Another thing that I’ve noticed, is that the issue is not happening in 2.15.x, and that it can be reproduced with
a vanilla bin download of the master series, as well as a master bin download of April 29th (the oldest available
on the build server).

Finally, the build is passing, so the rest config module seems to be working fine on its own, which makes me think
about something related to wiring…

Does the above ring any bell to any you?

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

–

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

-- 
Chris Hodgson
Refractions Research
Suite 419 – 1207 Douglas Street
Victoria, British Columbia
Canada, V8W 2E7
1-250-383-3022
[http://www.refractions.net](http://www.refractions.net)