Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
You're welcome! On 10/05/2016 15:06, Fabio Fioretti wrote: I confirm version 6.23.0 fixed the problem. Thank you for the great support! Kind regards, Fabio On Thu, Apr 28, 2016 at 12:02 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: Thanks Andrea, that would be excellent! Keep up the great work, Fabio On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Benewrote: Thank you for the issue! I think we can make it for next release 6.23.0 which should come quite soon (at the moment we are voting to release Wicket 6.23.0). Andrea. On 28/04/2016 11:34, Fabio Fioretti wrote: Done: https://github.com/wicketstuff/core/issues/490 Many thanks, Fabio On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov < martin.grigo...@gmail.com wrote: Please file an issue at Wicketstuff GibHub. On Apr 28, 2016 10:31 AM, "Fabio Fioretti" wrote: Hi all, Please consider the following simple implementation of AbstractRestResource (6.22.0): @ResourcePath("/rest/api") public class MyRestResource extends AbstractRestResource { public MyRestResource () { super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); } @MethodMapping(value = "/offices") public List findOffices( @RequestParam(value = "region", required = false) Integer regionId) { return findOfficesByRegion(regionId); } } My question relates to the findOffices method and its filtering regionId parameter when the value is not a valid integer. For example, consider the request 'GET /rest/api/offices?region=AA'. At the second step of AbstractRestResource.handleMethodExecution, extractMethodParameters is invoked, which in turn triggers the conversion of all parameters through the static method toObject. When the conversion goes wrong and ConversionException is thrown, toObject catches it, sets the response status to 400 and returns null! Now, when my findOffices is finally executed, I get a null regionId but I don't know whether it was not valid or the parameter was not present at all. Checking the response status downstream is also particularly hard because I have no getStatus (Tomcat 6 here, ouch!). To my mind, findOffices should return null instead of the unfiltered list of offices if the conversion went wrong, even because the response status is 400 (as set by toObject). However, how can I know it? Any suggestions? IMO this is a bug in the library. #findOffices() should not be executed at all. A response with status code 400 should be returned immediately after the unsuccessful convention without giving a chance to the application code to be executed. Many thanks, Fabio - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
I confirm version 6.23.0 fixed the problem. Thank you for the great support! Kind regards, Fabio On Thu, Apr 28, 2016 at 12:02 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: > Thanks Andrea, that would be excellent! > > Keep up the great work, > Fabio > > On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Bene> wrote: > >> Thank you for the issue! I think we can make it for next release 6.23.0 >> which should come quite soon (at the moment we are voting to release Wicket >> 6.23.0). >> >> Andrea. >> >> >> On 28/04/2016 11:34, Fabio Fioretti wrote: >> >>> Done: https://github.com/wicketstuff/core/issues/490 >>> >>> Many thanks, >>> Fabio >>> >>> On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov < >>> martin.grigo...@gmail.com >>> wrote: Please file an issue at Wicketstuff GibHub. On Apr 28, 2016 10:31 AM, "Fabio Fioretti" wrote: Hi Martin, > > Thanks, I agree - findOffices() shouldn't be executed at all. In fact, > handleMethodExecution() returns before invoking application code in all > other cases (step 1 for unauthorized access, step 3 for validation > errors). > Any chance to have it fixed relatively soon? (maybe Andrea can answer > this) > Kind regards, > Fabio > > On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov > > wrote: > > Hi, >> >> >> On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < >> windom.macroso...@gmail.com> wrote: >> >> Hi all, >>> >>> Please consider the following simple implementation of >>> >> AbstractRestResource >> >>> (6.22.0): >>> >>> @ResourcePath("/rest/api") >>> public class MyRestResource extends >>> AbstractRestResource >>> { >>> >>> public MyRestResource () >>> { >>>super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); >>> } >>> >>> @MethodMapping(value = "/offices") >>> public List findOffices( >>> @RequestParam(value = "region", required = false) Integer >>> >> regionId) > { >>>return findOfficesByRegion(regionId); >>> } >>> } >>> >>> My question relates to the findOffices method and its filtering >>> >> regionId > >> parameter when the value is not a valid integer. For example, >>> >> consider > the >> >>> request 'GET /rest/api/offices?region=AA'. >>> >>> At the second step of AbstractRestResource.handleMethodExecution, >>> extractMethodParameters is invoked, which in turn triggers the >>> >> conversion > >> of all parameters through the static method toObject. >>> >>> When the conversion goes wrong and ConversionException is thrown, >>> >> toObject >> >>> catches it, sets the response status to 400 and returns null! >>> >>> Now, when my findOffices is finally executed, I get a null regionId >>> >> but I > >> don't know whether it was not valid or the parameter was not present >>> >> at > all. Checking the response status downstream is also particularly >>> >> hard > because I have no getStatus (Tomcat 6 here, ouch!). >>> >>> To my mind, findOffices should return null instead of the unfiltered >>> >> list > >> of offices if the conversion went wrong, even because the response >>> status is 400 (as set by toObject). However, how can I know it? >>> >>> Any suggestions? >>> >>> IMO this is a bug in the library. >> #findOffices() should not be executed at all. >> A response with status code 400 should be returned immediately after >> > the > unsuccessful convention without giving a chance to the application code >> > to > >> be executed. >> >> Many thanks, >>> Fabio >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Thanks Andrea, that would be excellent! Keep up the great work, Fabio On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Benewrote: > Thank you for the issue! I think we can make it for next release 6.23.0 > which should come quite soon (at the moment we are voting to release Wicket > 6.23.0). > > Andrea. > > > On 28/04/2016 11:34, Fabio Fioretti wrote: > >> Done: https://github.com/wicketstuff/core/issues/490 >> >> Many thanks, >> Fabio >> >> On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov < >> martin.grigo...@gmail.com >> >>> wrote: >>> Please file an issue at Wicketstuff GibHub. >>> On Apr 28, 2016 10:31 AM, "Fabio Fioretti" >>> wrote: >>> >>> Hi Martin, Thanks, I agree - findOffices() shouldn't be executed at all. In fact, handleMethodExecution() returns before invoking application code in all other cases (step 1 for unauthorized access, step 3 for validation >>> errors). >>> Any chance to have it fixed relatively soon? (maybe Andrea can answer >>> this) >>> Kind regards, Fabio On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov wrote: Hi, > > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < > windom.macroso...@gmail.com> wrote: > > Hi all, >> >> Please consider the following simple implementation of >> > AbstractRestResource > >> (6.22.0): >> >> @ResourcePath("/rest/api") >> public class MyRestResource extends >> AbstractRestResource >> { >> >> public MyRestResource () >> { >>super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); >> } >> >> @MethodMapping(value = "/offices") >> public List findOffices( >> @RequestParam(value = "region", required = false) Integer >> > regionId) >>> { >>return findOfficesByRegion(regionId); >> } >> } >> >> My question relates to the findOffices method and its filtering >> > regionId > parameter when the value is not a valid integer. For example, >> > consider >>> the > >> request 'GET /rest/api/offices?region=AA'. >> >> At the second step of AbstractRestResource.handleMethodExecution, >> extractMethodParameters is invoked, which in turn triggers the >> > conversion > of all parameters through the static method toObject. >> >> When the conversion goes wrong and ConversionException is thrown, >> > toObject > >> catches it, sets the response status to 400 and returns null! >> >> Now, when my findOffices is finally executed, I get a null regionId >> > but I > don't know whether it was not valid or the parameter was not present >> > at >>> all. Checking the response status downstream is also particularly >> > hard >>> because I have no getStatus (Tomcat 6 here, ouch!). >> >> To my mind, findOffices should return null instead of the unfiltered >> > list > of offices if the conversion went wrong, even because the response >> status is 400 (as set by toObject). However, how can I know it? >> >> Any suggestions? >> >> IMO this is a bug in the library. > #findOffices() should not be executed at all. > A response with status code 400 should be returned immediately after > the >>> unsuccessful convention without giving a chance to the application code > to > be executed. > > Many thanks, >> Fabio >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Thank you for the issue! I think we can make it for next release 6.23.0 which should come quite soon (at the moment we are voting to release Wicket 6.23.0). Andrea. On 28/04/2016 11:34, Fabio Fioretti wrote: Done: https://github.com/wicketstuff/core/issues/490 Many thanks, Fabio On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorovwrote: Hi Martin, Thanks, I agree - findOffices() shouldn't be executed at all. In fact, handleMethodExecution() returns before invoking application code in all other cases (step 1 for unauthorized access, step 3 for validation errors). Any chance to have it fixed relatively soon? (maybe Andrea can answer this) Kind regards, Fabio On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov wrote: Hi, On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: Hi all, Please consider the following simple implementation of AbstractRestResource (6.22.0): @ResourcePath("/rest/api") public class MyRestResource extends AbstractRestResource { public MyRestResource () { super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); } @MethodMapping(value = "/offices") public List findOffices( @RequestParam(value = "region", required = false) Integer regionId) { return findOfficesByRegion(regionId); } } My question relates to the findOffices method and its filtering regionId parameter when the value is not a valid integer. For example, consider the request 'GET /rest/api/offices?region=AA'. At the second step of AbstractRestResource.handleMethodExecution, extractMethodParameters is invoked, which in turn triggers the conversion of all parameters through the static method toObject. When the conversion goes wrong and ConversionException is thrown, toObject catches it, sets the response status to 400 and returns null! Now, when my findOffices is finally executed, I get a null regionId but I don't know whether it was not valid or the parameter was not present at all. Checking the response status downstream is also particularly hard because I have no getStatus (Tomcat 6 here, ouch!). To my mind, findOffices should return null instead of the unfiltered list of offices if the conversion went wrong, even because the response status is 400 (as set by toObject). However, how can I know it? Any suggestions? IMO this is a bug in the library. #findOffices() should not be executed at all. A response with status code 400 should be returned immediately after the unsuccessful convention without giving a chance to the application code to be executed. Many thanks, Fabio - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Done: https://github.com/wicketstuff/core/issues/490 Many thanks, Fabio On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorovwrote: > Please file an issue at Wicketstuff GibHub. > On Apr 28, 2016 10:31 AM, "Fabio Fioretti" > wrote: > > > Hi Martin, > > > > Thanks, I agree - findOffices() shouldn't be executed at all. In fact, > > handleMethodExecution() returns before invoking application code in all > > other cases (step 1 for unauthorized access, step 3 for validation > errors). > > > > Any chance to have it fixed relatively soon? (maybe Andrea can answer > this) > > > > Kind regards, > > Fabio > > > > On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov > > wrote: > > > > > Hi, > > > > > > > > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < > > > windom.macroso...@gmail.com> wrote: > > > > > > > Hi all, > > > > > > > > Please consider the following simple implementation of > > > AbstractRestResource > > > > (6.22.0): > > > > > > > > @ResourcePath("/rest/api") > > > > public class MyRestResource extends > > > > AbstractRestResource > > > > { > > > > > > > > public MyRestResource () > > > > { > > > > super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); > > > > } > > > > > > > > @MethodMapping(value = "/offices") > > > > public List findOffices( > > > >@RequestParam(value = "region", required = false) Integer > regionId) > > > > { > > > > return findOfficesByRegion(regionId); > > > > } > > > > } > > > > > > > > My question relates to the findOffices method and its filtering > > regionId > > > > parameter when the value is not a valid integer. For example, > consider > > > the > > > > request 'GET /rest/api/offices?region=AA'. > > > > > > > > At the second step of AbstractRestResource.handleMethodExecution, > > > > extractMethodParameters is invoked, which in turn triggers the > > conversion > > > > of all parameters through the static method toObject. > > > > > > > > When the conversion goes wrong and ConversionException is thrown, > > > toObject > > > > catches it, sets the response status to 400 and returns null! > > > > > > > > Now, when my findOffices is finally executed, I get a null regionId > > but I > > > > don't know whether it was not valid or the parameter was not present > at > > > > all. Checking the response status downstream is also particularly > hard > > > > because I have no getStatus (Tomcat 6 here, ouch!). > > > > > > > > To my mind, findOffices should return null instead of the unfiltered > > list > > > > of offices if the conversion went wrong, even because the response > > > > status is 400 (as set by toObject). However, how can I know it? > > > > > > > > Any suggestions? > > > > > > > > > > IMO this is a bug in the library. > > > #findOffices() should not be executed at all. > > > A response with status code 400 should be returned immediately after > the > > > unsuccessful convention without giving a chance to the application code > > to > > > be executed. > > > > > > > > > > > Many thanks, > > > > Fabio > > > > > > > > > >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Please file an issue at Wicketstuff GibHub. On Apr 28, 2016 10:31 AM, "Fabio Fioretti"wrote: > Hi Martin, > > Thanks, I agree - findOffices() shouldn't be executed at all. In fact, > handleMethodExecution() returns before invoking application code in all > other cases (step 1 for unauthorized access, step 3 for validation errors). > > Any chance to have it fixed relatively soon? (maybe Andrea can answer this) > > Kind regards, > Fabio > > On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov > wrote: > > > Hi, > > > > > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < > > windom.macroso...@gmail.com> wrote: > > > > > Hi all, > > > > > > Please consider the following simple implementation of > > AbstractRestResource > > > (6.22.0): > > > > > > @ResourcePath("/rest/api") > > > public class MyRestResource extends > > > AbstractRestResource > > > { > > > > > > public MyRestResource () > > > { > > > super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); > > > } > > > > > > @MethodMapping(value = "/offices") > > > public List findOffices( > > >@RequestParam(value = "region", required = false) Integer regionId) > > > { > > > return findOfficesByRegion(regionId); > > > } > > > } > > > > > > My question relates to the findOffices method and its filtering > regionId > > > parameter when the value is not a valid integer. For example, consider > > the > > > request 'GET /rest/api/offices?region=AA'. > > > > > > At the second step of AbstractRestResource.handleMethodExecution, > > > extractMethodParameters is invoked, which in turn triggers the > conversion > > > of all parameters through the static method toObject. > > > > > > When the conversion goes wrong and ConversionException is thrown, > > toObject > > > catches it, sets the response status to 400 and returns null! > > > > > > Now, when my findOffices is finally executed, I get a null regionId > but I > > > don't know whether it was not valid or the parameter was not present at > > > all. Checking the response status downstream is also particularly hard > > > because I have no getStatus (Tomcat 6 here, ouch!). > > > > > > To my mind, findOffices should return null instead of the unfiltered > list > > > of offices if the conversion went wrong, even because the response > > > status is 400 (as set by toObject). However, how can I know it? > > > > > > Any suggestions? > > > > > > > IMO this is a bug in the library. > > #findOffices() should not be executed at all. > > A response with status code 400 should be returned immediately after the > > unsuccessful convention without giving a chance to the application code > to > > be executed. > > > > > > > > Many thanks, > > > Fabio > > > > > >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Hi Martin, Thanks, I agree - findOffices() shouldn't be executed at all. In fact, handleMethodExecution() returns before invoking application code in all other cases (step 1 for unauthorized access, step 3 for validation errors). Any chance to have it fixed relatively soon? (maybe Andrea can answer this) Kind regards, Fabio On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorovwrote: > Hi, > > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < > windom.macroso...@gmail.com> wrote: > > > Hi all, > > > > Please consider the following simple implementation of > AbstractRestResource > > (6.22.0): > > > > @ResourcePath("/rest/api") > > public class MyRestResource extends > > AbstractRestResource > > { > > > > public MyRestResource () > > { > > super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); > > } > > > > @MethodMapping(value = "/offices") > > public List findOffices( > >@RequestParam(value = "region", required = false) Integer regionId) > > { > > return findOfficesByRegion(regionId); > > } > > } > > > > My question relates to the findOffices method and its filtering regionId > > parameter when the value is not a valid integer. For example, consider > the > > request 'GET /rest/api/offices?region=AA'. > > > > At the second step of AbstractRestResource.handleMethodExecution, > > extractMethodParameters is invoked, which in turn triggers the conversion > > of all parameters through the static method toObject. > > > > When the conversion goes wrong and ConversionException is thrown, > toObject > > catches it, sets the response status to 400 and returns null! > > > > Now, when my findOffices is finally executed, I get a null regionId but I > > don't know whether it was not valid or the parameter was not present at > > all. Checking the response status downstream is also particularly hard > > because I have no getStatus (Tomcat 6 here, ouch!). > > > > To my mind, findOffices should return null instead of the unfiltered list > > of offices if the conversion went wrong, even because the response > > status is 400 (as set by toObject). However, how can I know it? > > > > Any suggestions? > > > > IMO this is a bug in the library. > #findOffices() should not be executed at all. > A response with status code 400 should be returned immediately after the > unsuccessful convention without giving a chance to the application code to > be executed. > > > > > Many thanks, > > Fabio > > >
Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Hi, On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti < windom.macroso...@gmail.com> wrote: > Hi all, > > Please consider the following simple implementation of AbstractRestResource > (6.22.0): > > @ResourcePath("/rest/api") > public class MyRestResource extends > AbstractRestResource > { > > public MyRestResource () > { > super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); > } > > @MethodMapping(value = "/offices") > public List findOffices( >@RequestParam(value = "region", required = false) Integer regionId) > { > return findOfficesByRegion(regionId); > } > } > > My question relates to the findOffices method and its filtering regionId > parameter when the value is not a valid integer. For example, consider the > request 'GET /rest/api/offices?region=AA'. > > At the second step of AbstractRestResource.handleMethodExecution, > extractMethodParameters is invoked, which in turn triggers the conversion > of all parameters through the static method toObject. > > When the conversion goes wrong and ConversionException is thrown, toObject > catches it, sets the response status to 400 and returns null! > > Now, when my findOffices is finally executed, I get a null regionId but I > don't know whether it was not valid or the parameter was not present at > all. Checking the response status downstream is also particularly hard > because I have no getStatus (Tomcat 6 here, ouch!). > > To my mind, findOffices should return null instead of the unfiltered list > of offices if the conversion went wrong, even because the response > status is 400 (as set by toObject). However, how can I know it? > > Any suggestions? > IMO this is a bug in the library. #findOffices() should not be executed at all. A response with status code 400 should be returned immediately after the unsuccessful convention without giving a chance to the application code to be executed. > > Many thanks, > Fabio >
[wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.
Hi all, Please consider the following simple implementation of AbstractRestResource (6.22.0): @ResourcePath("/rest/api") public class MyRestResource extends AbstractRestResource { public MyRestResource () { super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial())); } @MethodMapping(value = "/offices") public List findOffices( @RequestParam(value = "region", required = false) Integer regionId) { return findOfficesByRegion(regionId); } } My question relates to the findOffices method and its filtering regionId parameter when the value is not a valid integer. For example, consider the request 'GET /rest/api/offices?region=AA'. At the second step of AbstractRestResource.handleMethodExecution, extractMethodParameters is invoked, which in turn triggers the conversion of all parameters through the static method toObject. When the conversion goes wrong and ConversionException is thrown, toObject catches it, sets the response status to 400 and returns null! Now, when my findOffices is finally executed, I get a null regionId but I don't know whether it was not valid or the parameter was not present at all. Checking the response status downstream is also particularly hard because I have no getStatus (Tomcat 6 here, ouch!). To my mind, findOffices should return null instead of the unfiltered list of offices if the conversion went wrong, even because the response status is 400 (as set by toObject). However, how can I know it? Any suggestions? Many thanks, Fabio