Menu
▾
▴
resteasy-developers
|
From: Martin A. <sp...@ma...> - 2008-06-16 10:39:12
|
In my code I have the following subresource locator:
@Path("{number}")
public AccountResource getAccount( @PathParam("number") int
number ) {
This is the only method that can match anything. If I pass in
something that can not get interpreted as a string I get a 500 and a
NumberFormatException - which doesn't seem entirely right. However
from the spec I struggle to work out what it should be. 404? 400?. I
plan to file it as a bug, but would like to provide a test case for it
as well - so I need to work out the wanted behaviour.
Here's the stack trace:
java.lang.NumberFormatException: For input string: "q"
at
java
.lang.NumberFormatException.forInputString(NumberFormatException.java:
48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.valueOf(Integer.java:553)
at
org
.resteasy
.util
.StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:18)
at
org
.resteasy
.StringParameterInjector.extractValue(StringParameterInjector.java:143)
at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
at
org
.resteasy.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
at org.resteasy.ResourceLocator.createResource(ResourceLocator.java:64)
Martin
|
|
From: Bill B. <bb...@re...> - 2008-06-16 19:13:27
|
I'd say 400. Bad request. Please log jira bug. Thanks.
Martin Algesten wrote:
>
> In my code I have the following subresource locator:
>
> @Path("{number}")
> public AccountResource getAccount( @PathParam("number") int number ) {
>
> This is the only method that can match anything. If I pass in something
> that can not get interpreted as a string I get a 500 and a
> NumberFormatException - which doesn't seem entirely right. However from
> the spec I struggle to work out what it should be. 404? 400?. I plan to
> file it as a bug, but would like to provide a test case for it as well -
> so I need to work out the wanted behaviour.
>
> Here's the stack trace:
>
> java.lang.NumberFormatException: For input string: "q"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:447)
> at java.lang.Integer.valueOf(Integer.java:553)
> at
> org.resteasy.util.StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:18)
> at
> org.resteasy.StringParameterInjector.extractValue(StringParameterInjector.java:143)
> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
> at
> org.resteasy.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
> at org.resteasy.ResourceLocator.createResource(ResourceLocator.java:64)
>
> Martin
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ryan J. M. <ry...@da...> - 2008-07-06 12:29:45
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry for the slow response, but I had this sitting in my draft
forlder for w while. But I disagree with 400 here and it should be a
404 since an AccountResource identified by a String identifier will
never exist. Therefore, if you attempt to access a resource with a
String-based ID, it should return a 404 rather than just a 400. Since
we can understand the request and know that the resource isn't
available, we should return the client a more specific message.
Ryan-
On Jun 16, 2008, at 3:15 PM, Bill Burke wrote:
> I'd say 400. Bad request. Please log jira bug. Thanks.
>
> Martin Algesten wrote:
>>
>> In my code I have the following subresource locator:
>>
>> @Path("{number}")
>> public AccountResource getAccount( @PathParam("number") int
>> number ) {
>>
>> This is the only method that can match anything. If I pass in
>> something
>> that can not get interpreted as a string I get a 500 and a
>> NumberFormatException - which doesn't seem entirely right. However
>> from
>> the spec I struggle to work out what it should be. 404? 400?. I
>> plan to
>> file it as a bug, but would like to provide a test case for it as
>> well -
>> so I need to work out the wanted behaviour.
>>
>> Here's the stack trace:
>>
>> java.lang.NumberFormatException: For input string: "q"
>> at
>> java
>> .lang
>> .NumberFormatException.forInputString(NumberFormatException.java:48)
>> at java.lang.Integer.parseInt(Integer.java:447)
>> at java.lang.Integer.valueOf(Integer.java:553)
>> at
>> org
>> .resteasy
>> .util
>> .StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:
>> 18)
>> at
>> org
>> .resteasy
>> .StringParameterInjector.extractValue(StringParameterInjector.java:
>> 143)
>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>> at
>> org
>> .resteasy
>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>> at org.resteasy.ResourceLocator.createResource(ResourceLocator.java:
>> 64)
>>
>> Martin
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFIcLqwK/xjmUY6JwURAskZAJ0bLmdnBkR4vnpywPg00pnYU6yMOACgjV06
7oGPAdjtQn2NAqN/gNNBwsg=
=SRbP
-----END PGP SIGNATURE-----
|
|
From: Martin A. <sp...@ma...> - 2008-06-17 09:47:54
|
There's something I'm missing. I can't work out in why I hit the method:
org.resteasy.ResourceLocator.createResource()
With my test project I do hit it, and that's why I get the uncaught
NumberFormatException - however I don't understand how I can make a
test case that use this method, the TestSmoke etc don't seem to hit it
- so for now I've logged the jira bug and attached a patch that fixes
the problem, but doesn't have a test case.
Martin
On 16 Jun 2008, at 21:15, Bill Burke wrote:
> I'd say 400. Bad request. Please log jira bug. Thanks.
>
> Martin Algesten wrote:
>> In my code I have the following subresource locator:
>> @Path("{number}")
>> public AccountResource getAccount( @PathParam("number") int
>> number ) {
>> This is the only method that can match anything. If I pass in
>> something that can not get interpreted as a string I get a 500 and
>> a NumberFormatException - which doesn't seem entirely right.
>> However from the spec I struggle to work out what it should be.
>> 404? 400?. I plan to file it as a bug, but would like to provide a
>> test case for it as well - so I need to work out the wanted
>> behaviour.
>> Here's the stack trace:
>> java.lang.NumberFormatException: For input string: "q"
>> at
>> java
>> .lang
>> .NumberFormatException.forInputString(NumberFormatException.java:48)
>> at java.lang.Integer.parseInt(Integer.java:447)
>> at java.lang.Integer.valueOf(Integer.java:553)
>> at
>> org
>> .resteasy
>> .util
>> .StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:
>> 18)
>> at
>> org
>> .resteasy
>> .StringParameterInjector.extractValue(StringParameterInjector.java:
>> 143)
>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>> at
>> org
>> .resteasy
>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>> at org.resteasy.ResourceLocator.createResource(ResourceLocator.java:
>> 64)
>> Martin
>>
|
|
From: Bill B. <bb...@re...> - 2008-06-17 11:13:05
|
ResourceLocator gets hit when:
@Path(...)
public class RootResource {
@Path(...)
public Subresource getSubResource() {...}
}
If you are following me.
Martin Algesten wrote:
>
> There's something I'm missing. I can't work out in why I hit the method:
>
> org.resteasy.ResourceLocator.createResource()
>
> With my test project I do hit it, and that's why I get the uncaught
> NumberFormatException - however I don't understand how I can make a
> test case that use this method, the TestSmoke etc don't seem to hit it -
> so for now I've logged the jira bug and attached a patch that fixes the
> problem, but doesn't have a test case.
>
> Martin
>
>
> On 16 Jun 2008, at 21:15, Bill Burke wrote:
>
>> I'd say 400. Bad request. Please log jira bug. Thanks.
>>
>> Martin Algesten wrote:
>>> In my code I have the following subresource locator:
>>> @Path("{number}")
>>> public AccountResource getAccount( @PathParam("number") int number ) {
>>> This is the only method that can match anything. If I pass in
>>> something that can not get interpreted as a string I get a 500 and a
>>> NumberFormatException - which doesn't seem entirely right. However
>>> from the spec I struggle to work out what it should be. 404? 400?. I
>>> plan to file it as a bug, but would like to provide a test case for
>>> it as well - so I need to work out the wanted behaviour.
>>> Here's the stack trace:
>>> java.lang.NumberFormatException: For input string: "q"
>>> at
>>> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>>> at java.lang.Integer.parseInt(Integer.java:447)
>>> at java.lang.Integer.valueOf(Integer.java:553)
>>> at
>>> org.resteasy.util.StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:18)
>>> at
>>> org.resteasy.StringParameterInjector.extractValue(StringParameterInjector.java:143)
>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>>> at
>>> org.resteasy.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>> at org.resteasy.ResourceLocator.createResource(ResourceLocator.java:64)
>>> Martin
>>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Martin A. <sp...@ma...> - 2008-06-17 11:18:37
|
Yeah, that much I figured out.
It's specifically the method createResource() that I'm wondering about.
Martin
On 17 Jun 2008, at 13:15, Bill Burke wrote:
> ResourceLocator gets hit when:
>
> @Path(...)
> public class RootResource {
>
>
> @Path(...)
> public Subresource getSubResource() {...}
>
> }
>
> If you are following me.
>
> Martin Algesten wrote:
>> There's something I'm missing. I can't work out in why I hit the
>> method:
>> org.resteasy.ResourceLocator.createResource()
>> With my test project I do hit it, and that's why I get the uncaught
>> NumberFormatException - however I don't understand how I can make
>> a test case that use this method, the TestSmoke etc don't seem to
>> hit it - so for now I've logged the jira bug and attached a patch
>> that fixes the problem, but doesn't have a test case.
>> Martin
>> On 16 Jun 2008, at 21:15, Bill Burke wrote:
>>> I'd say 400. Bad request. Please log jira bug. Thanks.
>>>
>>> Martin Algesten wrote:
>>>> In my code I have the following subresource locator:
>>>> @Path("{number}")
>>>> public AccountResource getAccount( @PathParam("number") int
>>>> number ) {
>>>> This is the only method that can match anything. If I pass in
>>>> something that can not get interpreted as a string I get a 500
>>>> and a NumberFormatException - which doesn't seem entirely right.
>>>> However from the spec I struggle to work out what it should be.
>>>> 404? 400?. I plan to file it as a bug, but would like to provide
>>>> a test case for it as well - so I need to work out the wanted
>>>> behaviour.
>>>> Here's the stack trace:
>>>> java.lang.NumberFormatException: For input string: "q"
>>>> at
>>>> java
>>>> .lang
>>>> .NumberFormatException.forInputString(NumberFormatException.java:
>>>> 48)
>>>> at java.lang.Integer.parseInt(Integer.java:447)
>>>> at java.lang.Integer.valueOf(Integer.java:553)
>>>> at
>>>> org
>>>> .resteasy
>>>> .util
>>>> .StringToPrimitive
>>>> .stringToPrimitiveBoxType(StringToPrimitive.java:18)
>>>> at
>>>> org
>>>> .resteasy
>>>> .StringParameterInjector
>>>> .extractValue(StringParameterInjector.java:143)
>>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>>>> at
>>>> org
>>>> .resteasy
>>>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>>> at
>>>> org.resteasy.ResourceLocator.createResource(ResourceLocator.java:
>>>> 64)
>>>> Martin
>>>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
|
|
From: Bill B. <bb...@re...> - 2008-06-17 11:27:13
|
Cool. I'll take a look later this week. I'm in some stupid management
meetings all week....
Martin Algesten wrote:
>
> Yeah, that much I figured out.
>
> It's specifically the method createResource() that I'm wondering about.
>
> Martin
>
> On 17 Jun 2008, at 13:15, Bill Burke wrote:
>
>> ResourceLocator gets hit when:
>>
>> @Path(...)
>> public class RootResource {
>>
>>
>> @Path(...)
>> public Subresource getSubResource() {...}
>>
>> }
>>
>> If you are following me.
>>
>> Martin Algesten wrote:
>>> There's something I'm missing. I can't work out in why I hit the method:
>>> org.resteasy.ResourceLocator.createResource()
>>> With my test project I do hit it, and that's why I get the uncaught
>>> NumberFormatException - however I don't understand how I can make a
>>> test case that use this method, the TestSmoke etc don't seem to hit
>>> it - so for now I've logged the jira bug and attached a patch that
>>> fixes the problem, but doesn't have a test case.
>>> Martin
>>> On 16 Jun 2008, at 21:15, Bill Burke wrote:
>>>> I'd say 400. Bad request. Please log jira bug. Thanks.
>>>>
>>>> Martin Algesten wrote:
>>>>> In my code I have the following subresource locator:
>>>>> @Path("{number}")
>>>>> public AccountResource getAccount( @PathParam("number") int number ) {
>>>>> This is the only method that can match anything. If I pass in
>>>>> something that can not get interpreted as a string I get a 500 and
>>>>> a NumberFormatException - which doesn't seem entirely right.
>>>>> However from the spec I struggle to work out what it should be.
>>>>> 404? 400?. I plan to file it as a bug, but would like to provide a
>>>>> test case for it as well - so I need to work out the wanted behaviour.
>>>>> Here's the stack trace:
>>>>> java.lang.NumberFormatException: For input string: "q"
>>>>> at
>>>>> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>>>>>
>>>>> at java.lang.Integer.parseInt(Integer.java:447)
>>>>> at java.lang.Integer.valueOf(Integer.java:553)
>>>>> at
>>>>> org.resteasy.util.StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:18)
>>>>>
>>>>> at
>>>>> org.resteasy.StringParameterInjector.extractValue(StringParameterInjector.java:143)
>>>>>
>>>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>>>>> at
>>>>> org.resteasy.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>>>>
>>>>> at
>>>>> org.resteasy.ResourceLocator.createResource(ResourceLocator.java:64)
>>>>> Martin
>>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Martin A. <sp...@ma...> - 2008-07-06 20:09:14
|
An easy enough fix. With your reasoning I +1 404. I take it Bill is
not disagreeing?
I'm planning to get my patches into the source tree Mon-Tue this week.
Cheers,
Martin
On 6 Jul 2008, at 14:29, Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sorry for the slow response, but I had this sitting in my draft
> forlder for w while. But I disagree with 400 here and it should be a
> 404 since an AccountResource identified by a String identifier will
> never exist. Therefore, if you attempt to access a resource with a
> String-based ID, it should return a 404 rather than just a 400.
> Since we can understand the request and know that the resource isn't
> available, we should return the client a more specific message.
>
> Ryan-
>
>
> On Jun 16, 2008, at 3:15 PM, Bill Burke wrote:
>
>> I'd say 400. Bad request. Please log jira bug. Thanks.
>>
>> Martin Algesten wrote:
>>>
>>> In my code I have the following subresource locator:
>>>
>>> @Path("{number}")
>>> public AccountResource getAccount( @PathParam("number") int
>>> number ) {
>>>
>>> This is the only method that can match anything. If I pass in
>>> something
>>> that can not get interpreted as a string I get a 500 and a
>>> NumberFormatException - which doesn't seem entirely right. However
>>> from
>>> the spec I struggle to work out what it should be. 404? 400?. I
>>> plan to
>>> file it as a bug, but would like to provide a test case for it as
>>> well -
>>> so I need to work out the wanted behaviour.
>>>
>>> Here's the stack trace:
>>>
>>> java.lang.NumberFormatException: For input string: "q"
>>> at
>>> java
>>> .lang
>>> .NumberFormatException.forInputString(NumberFormatException.java:48)
>>> at java.lang.Integer.parseInt(Integer.java:447)
>>> at java.lang.Integer.valueOf(Integer.java:553)
>>> at
>>> org
>>> .resteasy
>>> .util
>>> .StringToPrimitive.stringToPrimitiveBoxType(StringToPrimitive.java:
>>> 18)
>>> at
>>> org
>>> .resteasy
>>> .StringParameterInjector.extractValue(StringParameterInjector.java:
>>> 143)
>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>>> at
>>> org
>>> .resteasy
>>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>> at
>>> org.resteasy.ResourceLocator.createResource(ResourceLocator.java:64)
>>>
>>> Martin
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFIcLqwK/xjmUY6JwURAskZAJ0bLmdnBkR4vnpywPg00pnYU6yMOACgjV06
> 7oGPAdjtQn2NAqN/gNNBwsg=
> =SRbP
> -----END PGP SIGNATURE-----
|
|
From: Bill B. <bb...@re...> - 2008-07-07 13:58:18
|
Martin Algesten wrote: > > An easy enough fix. With your reasoning I +1 404. I take it Bill is not > disagreeing? > +1 :) > I'm planning to get my patches into the source tree Mon-Tue this week. > Cool man, keep it up. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2008-07-07 00:19:55
|
Oh, I don't think so. I just realized I had this response queued up in
my drafts and just wanted to weigh-in is all. On a related note, I did
make the package rename on Thursday night so be sure to take an
update. Also, I'm adding slf4j to the project so we have some type of
logging framework available. I'll be make those commits and publishing
details in the wiki later tonight or Monday morning.
Ryan-
On Jul 6, 2008, at 4:09 PM, Martin Algesten wrote:
>
> An easy enough fix. With your reasoning I +1 404. I take it Bill is
> not disagreeing?
>
> I'm planning to get my patches into the source tree Mon-Tue this week.
>
> Cheers,
> Martin
>
> On 6 Jul 2008, at 14:29, Ryan J. McDonough wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Sorry for the slow response, but I had this sitting in my draft
>> forlder for w while. But I disagree with 400 here and it should be
>> a 404 since an AccountResource identified by a String identifier
>> will never exist. Therefore, if you attempt to access a resource
>> with a String-based ID, it should return a 404 rather than just a
>> 400. Since we can understand the request and know that the resource
>> isn't available, we should return the client a more specific message.
>>
>> Ryan-
>>
>>
>> On Jun 16, 2008, at 3:15 PM, Bill Burke wrote:
>>
>>> I'd say 400. Bad request. Please log jira bug. Thanks.
>>>
>>> Martin Algesten wrote:
>>>>
>>>> In my code I have the following subresource locator:
>>>>
>>>> @Path("{number}")
>>>> public AccountResource getAccount( @PathParam("number") int
>>>> number ) {
>>>>
>>>> This is the only method that can match anything. If I pass in
>>>> something
>>>> that can not get interpreted as a string I get a 500 and a
>>>> NumberFormatException - which doesn't seem entirely right.
>>>> However from
>>>> the spec I struggle to work out what it should be. 404? 400?. I
>>>> plan to
>>>> file it as a bug, but would like to provide a test case for it as
>>>> well -
>>>> so I need to work out the wanted behaviour.
>>>>
>>>> Here's the stack trace:
>>>>
>>>> java.lang.NumberFormatException: For input string: "q"
>>>> at
>>>> java
>>>> .lang
>>>> .NumberFormatException.forInputString(NumberFormatException.java:
>>>> 48)
>>>> at java.lang.Integer.parseInt(Integer.java:447)
>>>> at java.lang.Integer.valueOf(Integer.java:553)
>>>> at
>>>> org
>>>> .resteasy
>>>> .util
>>>> .StringToPrimitive
>>>> .stringToPrimitiveBoxType(StringToPrimitive.java:18)
>>>> at
>>>> org
>>>> .resteasy
>>>> .StringParameterInjector
>>>> .extractValue(StringParameterInjector.java:143)
>>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:44)
>>>> at
>>>> org
>>>> .resteasy
>>>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>>> at
>>>> org.resteasy.ResourceLocator.createResource(ResourceLocator.java:
>>>> 64)
>>>>
>>>> Martin
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Resteasy-developers mailing list
>>>> Res...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>>
>> iD8DBQFIcLqwK/xjmUY6JwURAskZAJ0bLmdnBkR4vnpywPg00pnYU6yMOACgjV06
>> 7oGPAdjtQn2NAqN/gNNBwsg=
>> =SRbP
>> -----END PGP SIGNATURE-----
>
|
|
From: Bill B. <bb...@re...> - 2008-07-07 13:59:53
|
Ryan J. McDonough wrote: > Oh, I don't think so. I just realized I had this response queued up in > my drafts and just wanted to weigh-in is all. On a related note, I did > make the package rename on Thursday night so be sure to take an update. > Also, I'm adding slf4j to the project so we have some type of logging > framework available. I'll be make those commits and publishing details > in the wiki later tonight or Monday morning. > -1 on slf4j. I'm so sick of these shitty logging frameworks and the dependency problems and bloat problems they create. Let's use JDK logging insead. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Martin A. <sp...@ma...> - 2008-07-08 09:52:24
|
It was obviously not as easy as that. The question is what happens
when the arguments are passed as request headers or question
parameters instead of on the path. 404 in those cases too?
I.e. if you have a method
@Path("{number}")
public AccountResource getAccount( @PathParam("number") int number ) {
and you pass ?number=bad or request.setRequestHeader( "number", "bad )
404 in all cases?
That's what I've checked in now. I've also changed the expected
behaviour for bad list values (i.e. ?number=bad1&number=bad2) to also
give 404.
I could see an argument that:
1) Subresource locator with bad path argument => 404
2) Bad path argument => 400
3) Bad header argument => 400
4) Bad request argument => 400
That would require some further refactoring though. Thoughts?
M
On 7 Jul 2008, at 02:19, Ryan J. McDonough wrote:
> Oh, I don't think so. I just realized I had this response queued up
> in my drafts and just wanted to weigh-in is all. On a related note,
> I did make the package rename on Thursday night so be sure to take
> an update. Also, I'm adding slf4j to the project so we have some
> type of logging framework available. I'll be make those commits and
> publishing details in the wiki later tonight or Monday morning.
>
> Ryan-
>
> On Jul 6, 2008, at 4:09 PM, Martin Algesten wrote:
>
>>
>> An easy enough fix. With your reasoning I +1 404. I take it Bill is
>> not disagreeing?
>>
>> I'm planning to get my patches into the source tree Mon-Tue this
>> week.
>>
>> Cheers,
>> Martin
>>
>> On 6 Jul 2008, at 14:29, Ryan J. McDonough wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Sorry for the slow response, but I had this sitting in my draft
>>> forlder for w while. But I disagree with 400 here and it should be
>>> a 404 since an AccountResource identified by a String identifier
>>> will never exist. Therefore, if you attempt to access a resource
>>> with a String-based ID, it should return a 404 rather than just a
>>> 400. Since we can understand the request and know that the
>>> resource isn't available, we should return the client a more
>>> specific message.
>>>
>>> Ryan-
>>>
>>>
>>> On Jun 16, 2008, at 3:15 PM, Bill Burke wrote:
>>>
>>>> I'd say 400. Bad request. Please log jira bug. Thanks.
>>>>
>>>> Martin Algesten wrote:
>>>>>
>>>>> In my code I have the following subresource locator:
>>>>>
>>>>> @Path("{number}")
>>>>> public AccountResource getAccount( @PathParam("number") int
>>>>> number ) {
>>>>>
>>>>> This is the only method that can match anything. If I pass in
>>>>> something
>>>>> that can not get interpreted as a string I get a 500 and a
>>>>> NumberFormatException - which doesn't seem entirely right.
>>>>> However from
>>>>> the spec I struggle to work out what it should be. 404? 400?. I
>>>>> plan to
>>>>> file it as a bug, but would like to provide a test case for it
>>>>> as well -
>>>>> so I need to work out the wanted behaviour.
>>>>>
>>>>> Here's the stack trace:
>>>>>
>>>>> java.lang.NumberFormatException: For input string: "q"
>>>>> at
>>>>> java
>>>>> .lang
>>>>> .NumberFormatException.forInputString(NumberFormatException.java:
>>>>> 48)
>>>>> at java.lang.Integer.parseInt(Integer.java:447)
>>>>> at java.lang.Integer.valueOf(Integer.java:553)
>>>>> at
>>>>> org
>>>>> .resteasy
>>>>> .util
>>>>> .StringToPrimitive
>>>>> .stringToPrimitiveBoxType(StringToPrimitive.java:18)
>>>>> at
>>>>> org
>>>>> .resteasy
>>>>> .StringParameterInjector
>>>>> .extractValue(StringParameterInjector.java:143)
>>>>> at org.resteasy.PathParamInjector.inject(PathParamInjector.java:
>>>>> 44)
>>>>> at
>>>>> org
>>>>> .resteasy
>>>>> .MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:53)
>>>>> at
>>>>> org.resteasy.ResourceLocator.createResource(ResourceLocator.java:
>>>>> 64)
>>>>>
>>>>> Martin
>>>>>
>>>>>
|
Thanks for helping keep SourceForge clean.
X