resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] bad pom.xml version property

[Bill B. <bb...@re...>]

Martin Algesten wrote:
> In parent pom.xml we define:
> 
>          <properties>
>                  <resteasy.version>1.0-beta-6</resteasy.version>
>          </properties>
> 
> - and this property is then used wherever the version is needed.  
> Superficially this may look like it works, but it won't.

Yeah, I'm a real maven noob and really struggled with it at first.

  The maven
> pom.xml often exist outside a context where the property definition  
> will work. For my local test project I have dependency on the child  
> project such as:
> 
>      <dependency>
>        <groupId>org.jboss.resteasy</groupId>
>        <artifactId>resteasy-jaxrs</artifactId>
>        <version>1.0-beta-6</version>
>      </dependency>
> 
> And I don't define <resteasy.version> anywhere. This results in:
> 
> Downloading: http://repo1.maven.org/maven2//org/jboss/resteasy/resteasy-jaxrs-all/$ 
> {resteasy.version}/resteasy-jaxrs-all-${resteasy.version}.pom
> ...
> and eventually an error that it can't find the dependency.
> 
> The reason this works in the /examples is that the exact property  
> <resteasy.version> has been defined there as well, hence maven  
> resolves it - but we can't require every project linking to resteasy  
> to define this property.
> 
> The solution is unfortunately to duplicate the version of the parent  
> pom around endlessly - however this is where the release plugin I  
> talked about earlier comes in handy. If we can get the project to work  
> with that plugin, it will help us maintain/update these versions as we  
> move forward.
> 
> I've refactored the pom versions to use the standard maven behaviour  
> of inheriting parent pom version and use ${project.version} for  
> relationships between child modules - so for now releasing means  
> editing the parent versions manually.
> 

This sounds good.  I'm hoping you and Ryan can work out the best Maven 
structure and teach me a few things about maven in the process :)

> Btw I also made sl4j-log4j dependency optional since I hate log4j with  
> a passion, and depending on resteasy currently pulled that crud into  
> my project.
> 

If you haven't already guessed I'm not a big fan of logging in general.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Bill B. <bb...@re...>]

Would be cool to have a regression unit test that duplicates the 
problems you and ryan are seeing too.

Bill Burke wrote:
> Change the code to check for Failure (if it doesn't already) and rethrow 
> that.
> 
> Martin Algesten wrote:
>> In ResourceMethod.invoke() line 153, there's a try-catch that makes  
>> all Failure exceptions thrown below be translated to 400. Is this  
>> deliberate? To make NumberFormatException result in 404 I want to pass  
>> my error code in the Failure exception, and then get that set in the  
>> response.
>>
>> I've checked in a change where we always set the error code passed in  
>> the Failure - it looks reasonable.
>>
>> Martin
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> 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

Re: [Resteasy-developers] subresource NPE fixed RESTEAY-58, 59

[Bill B. <bb...@re...>]

Thanks Martin!!!

Martin Algesten wrote:
> My proposed patches are checked in - I've closed the JIRA issues for  
> RESTEASY-58 and 59.
> 
> M
> 
> 
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> 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

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Bill B. <bb...@re...>]

Change the code to check for Failure (if it doesn't already) and rethrow 
that.

Martin Algesten wrote:
> In ResourceMethod.invoke() line 153, there's a try-catch that makes  
> all Failure exceptions thrown below be translated to 400. Is this  
> deliberate? To make NumberFormatException result in 404 I want to pass  
> my error code in the Failure exception, and then get that set in the  
> response.
> 
> I've checked in a change where we always set the error code passed in  
> the Failure - it looks reasonable.
> 
> Martin
> 
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> 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

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Martin A. <sp...@ma...>]

I'll look at that.

M

On 8 Jul 2008, at 13:11, Ryan J. McDonough wrote:

> Martin,
>
> This sounds similar to the issue I logged:
>
> http://jira.jboss.com/jira/browse/RESTEASY-63
>
> The TestIIOImageProvider.testPostUnsupportedImage() should get a 406  
> response with a list of variants rather than a 400. The correct  
> assertion is currently commented out on line 109. So in addition to  
> the response code, we also need to include the response information  
> generated from a WebApplicationException as well. If you're in  
> there, please have a take a look.
>
> Ryan-
>
>
>
> On Jul 8, 2008, at 5:52 AM, Martin Algesten wrote:
>
>>
>> In ResourceMethod.invoke() line 153, there's a try-catch that makes
>> all Failure exceptions thrown below be translated to 400. Is this
>> deliberate? To make NumberFormatException result in 404 I want to  
>> pass
>> my error code in the Failure exception, and then get that set in the
>> response.
>>
>> I've checked in a change where we always set the error code passed in
>> the Failure - it looks reasonable.
>>
>> Martin
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

[Resteasy-developers] bad pom.xml version property

[Martin A. <sp...@ma...>]

In parent pom.xml we define:

         <properties>
                 <resteasy.version>1.0-beta-6</resteasy.version>
         </properties>

- and this property is then used wherever the version is needed.  
Superficially this may look like it works, but it won't. The maven  
pom.xml often exist outside a context where the property definition  
will work. For my local test project I have dependency on the child  
project such as:

     <dependency>
       <groupId>org.jboss.resteasy</groupId>
       <artifactId>resteasy-jaxrs</artifactId>
       <version>1.0-beta-6</version>
     </dependency>

And I don't define <resteasy.version> anywhere. This results in:

Downloading: http://repo1.maven.org/maven2//org/jboss/resteasy/resteasy-jaxrs-all/$ 
{resteasy.version}/resteasy-jaxrs-all-${resteasy.version}.pom
...
and eventually an error that it can't find the dependency.

The reason this works in the /examples is that the exact property  
<resteasy.version> has been defined there as well, hence maven  
resolves it - but we can't require every project linking to resteasy  
to define this property.

The solution is unfortunately to duplicate the version of the parent  
pom around endlessly - however this is where the release plugin I  
talked about earlier comes in handy. If we can get the project to work  
with that plugin, it will help us maintain/update these versions as we  
move forward.

I've refactored the pom versions to use the standard maven behaviour  
of inheriting parent pom version and use ${project.version} for  
relationships between child modules - so for now releasing means  
editing the parent versions manually.

Happy to work on the release plugin if you agree this is the way  
forward.

Btw I also made sl4j-log4j dependency optional since I hate log4j with  
a passion, and depending on resteasy currently pulled that crud into  
my project.

M

Re: [Resteasy-developers] Failure == SC_BAD_REQUEST?

[Ryan J. M. <ry...@da...>]

Martin,

This sounds similar to the issue I logged:

http://jira.jboss.com/jira/browse/RESTEASY-63

The TestIIOImageProvider.testPostUnsupportedImage() should get a 406  
response with a list of variants rather than a 400. The correct  
assertion is currently commented out on line 109. So in addition to  
the response code, we also need to include the response information  
generated from a WebApplicationException as well. If you're in there,  
please have a take a look.

Ryan-



On Jul 8, 2008, at 5:52 AM, Martin Algesten wrote:

>
> In ResourceMethod.invoke() line 153, there's a try-catch that makes
> all Failure exceptions thrown below be translated to 400. Is this
> deliberate? To make NumberFormatException result in 404 I want to pass
> my error code in the Failure exception, and then get that set in the
> response.
>
> I've checked in a change where we always set the error code passed in
> the Failure - it looks reasonable.
>
> Martin
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

[Resteasy-developers] next?

[Martin A. <sp...@ma...>]

Just thinking about what I could look at next. Any thoughts on  
prioritising - perhaps there's something else more urgent?

* Get rid of eclipse warnings (see previous post)
* Work on pom.xml to make maven generate the site with documentation,  
javadoc etc. The idea would be to replace the current wiki page with  
one of the common maven style sites. I would make it so that we can  
use the release plugin for bundling up new releases.
* Implement Yaml plugin.

M

[Resteasy-developers] subresource NPE fixed RESTEAY-58, 59

[Martin A. <sp...@ma...>]

My proposed patches are checked in - I've closed the JIRA issues for  
RESTEASY-58 and 59.

M

[Resteasy-developers] Failure == SC_BAD_REQUEST?

[Martin A. <sp...@ma...>]

In ResourceMethod.invoke() line 153, there's a try-catch that makes  
all Failure exceptions thrown below be translated to 400. Is this  
deliberate? To make NumberFormatException result in 404 I want to pass  
my error code in the Failure exception, and then get that set in the  
response.

I've checked in a change where we always set the error code passed in  
the Failure - it looks reasonable.

Martin

Re: [Resteasy-developers] NumberFormatException when bad input path param

[Martin A. <sp...@ma...>]

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
>>>>>
>>>>>

[Resteasy-developers] code tidy

[Martin A. <sp...@ma...>]

I was just about to get cracking on my patches when I got distracted  
by the numerous warnings I get in eclipse. The warnings are of type:

1) Generics (loads of them)
2) Unused variables (a few)
3) serialVersionUID (a few)
4) Deprecations (rare)

I'm about to commit what I consider "harmless" fixes for unused  
variables and deprecations.

At first I tried to tackle the generics warnings as well, but quickly  
got into hmm... headache. Is this a priority? Should I continue to  
work through them?

With regards to serialVersionUID - how do you want them fixed? I can  
let eclipse do the "Add generated serial version UID" or I can  
suppress the warning. What do you prefer?

Martin

[Resteasy-developers] Added client module to spring-hibernate example

[Olivier B. <ol...@mu...>]

I have added the missing building block to my spring-hibernate example. I have also fixed the main pom file which had an error in it.
The new client module shows how to use embedded jetty6 in Junit4 by leveraging Spring autowiring features (need to read this line more than twice....). It shows then a very simple example that pulls the rest interface via the resteasy client proxy.
Use of embedded jetty4 was chosen over embedded resteasy http server in order to mimic what would be closer to a production environment test, it also shows how to use embedded jetty in a Spring configuration. Seraching the web, I had never really found a complete example on how to use it, so I thought someone would appreciate this....

Enjoy!

Olivier

Re: [Resteasy-developers] Logging Configuration Details

[Ryan M. <ry...@da...>]

I can see your point, but I do respectfully disagree. The idea behind it was
to offer choice to end users on logging frameworks. I didn't want people to
have to manage 2 different logging configurations just to get at the log
messages from RESTEasy. If I'm using JBoss AS, I'm most likely going to be
using log4j, but if I'm running stand alone, maybe JDK logging will be
sufficient. I've also not been much of a fan of JDK logging since
configuration is kind of a pain. I've used log4j frequently, but I don't
want to impose that restriction onto anyone else, which was the reason
behind slf4j.



On a related note, from a framework debugging perspective, I'd like to be
able to offer detailed information available to developers, much the same
way Hibernate does it:



http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/hibernate/Hibernate_Reference_Guide/Configuration-Logging.html



and how it's done in JBoss AS:



http://docs.jboss.org/process-guide/en/html/logging.html



I'd like to be able to offer the same level of details going forward. This
is what the LoggingCategories class.



Ryan-


On Mon, Jul 7, 2008 at 10:03 AM, Bill Burke <bb...@re...> wrote:

> -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
> instead.  Its good enough for what we want to do.
>
> Ryan J. McDonough wrote:
>
>>  -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Since we didn't have logging in RESTEasy I introduced the slf4j  logging
>> API to the project over the weekend. I have put the following  wiki page up
>> here to detail some of the changes:
>>
>> http://wiki.jboss.org/wiki/RESTEasyLogging
>>
>> Going forward, I'd like to see logging instead of System.out ;)
>>
>> Ryan-
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (Darwin)
>>
>> iD8DBQFIcYdHK/xjmUY6JwURAl9iAJ453Bq+zrfPUvsmUgO83CaCmJ/9/ACfTDGm
>> 18+LjZ87CRYVgDJtkO5djKM=
>> =hKND
>> -----END PGP SIGNATURE-----
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> 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
>



-- 
Ryan J. McDonough
http://www.damnhandy.com

Re: [Resteasy-developers] Logging Configuration Details

[Bill B. <bb...@re...>]

-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 instead.  Its good enough for what we want to do.

Ryan J. McDonough wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Since we didn't have logging in RESTEasy I introduced the slf4j  
> logging API to the project over the weekend. I have put the following  
> wiki page up here to detail some of the changes:
> 
> http://wiki.jboss.org/wiki/RESTEasyLogging
> 
> Going forward, I'd like to see logging instead of System.out ;)
> 
> Ryan-
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> 
> iD8DBQFIcYdHK/xjmUY6JwURAl9iAJ453Bq+zrfPUvsmUgO83CaCmJ/9/ACfTDGm
> 18+LjZ87CRYVgDJtkO5djKM=
> =hKND
> -----END PGP SIGNATURE-----
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> 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

[Resteasy-developers] LOGGING was Re: NumberFormatException when bad input path param

[Bill B. <bb...@re...>]

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

Re: [Resteasy-developers] NumberFormatException when bad input path param

[Bill B. <bb...@re...>]

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

[Resteasy-developers] Logging Configuration Details

[Ryan J. M. <ry...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since we didn't have logging in RESTEasy I introduced the slf4j  
logging API to the project over the weekend. I have put the following  
wiki page up here to detail some of the changes:

http://wiki.jboss.org/wiki/RESTEasyLogging

Going forward, I'd like to see logging instead of System.out ;)

Ryan-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIcYdHK/xjmUY6JwURAl9iAJ453Bq+zrfPUvsmUgO83CaCmJ/9/ACfTDGm
18+LjZ87CRYVgDJtkO5djKM=
=hKND
-----END PGP SIGNATURE-----

Re: [Resteasy-developers] NumberFormatException when bad input path param

[Ryan J. M. <ry...@da...>]

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-----
>

Re: [Resteasy-developers] NumberFormatException when bad input path param

[Martin A. <sp...@ma...>]

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-----

Re: [Resteasy-developers] NumberFormatException when bad input path param

[Ryan J. M. <ry...@da...>]

-----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-----

[Resteasy-developers] Package Renaming Completed

[Ryan J. M. <ry...@da...>]

I have finished the package renaming from org.resteast to  
org.jboss.resteasy. I also created 2 new sub projects for common and  
client that will be used to separate the client code. Please let me  
know if you see any hiccups.

Ryan-

Re: [Resteasy-developers] Resources throwing 404 on JBoss 4.2.2

[Bill B. <bb...@re...>]

I'm running in 4.2.2, you need to start a server manually.  Maybe that's 
your problem.

Ryan J. McDonough wrote:
> No, I changed so it's parameterized and the resources got deployed but 
> still returned a 404. I also tried deploying the war manually but still 
> no luck. The resources get deployed and I see the resource being 
> register when looking at the console but the resource never responds. 
> I'll debug it some more to see what's up, but it should be noted that 
> the unit tests continue to work. So it's isolated to JBoss 4.2.2 in my 
> case. I'm going to try it in Tomcat standalone to see if the problem is 
> there as well.
> 
> Ryan-
> 
> On Jul 3, 2008, at 3:41 PM, Bill Burke wrote:
> 
>> Ryan, I cannot reproduce this problem.  Everything builds and tests fine.
>>
>> Maybe its because the JBoss path is hardcoded in the pom?
>>
>>               
>> <jbossHome>/Users/billburke/jboss/jboss-4.2.2.GA</jbossHome>
>>
>>
>> Maybe that's another thing you can do in your build refactor?
>>
>>
>>
>> Ryan J. McDonough wrote:
>>> I'm trying t complete an example app for a few things i am working on 
>>> and I am hitting a wall with the latest code. It appears there's been 
>>> a regression recently because the resource is located by the 
>>> scannotation, but any requests to it will always yield a 404 
>>> response. Even executing the basic-integration-test produce the same 
>>> results. However, the same resources under beta 5 work just fine. I 
>>> logged the following defect to track the issue:
>>> http://jira.jboss.com/jira/browse/RESTEASY-70
>>> Ryan-
>>> ------------------------------------------------------------------------
>>> ------------------------------------------------------------------------- 
>>>
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> 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
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Resources throwing 404 on JBoss 4.2.2

[Ryan J. M. <ry...@da...>]

No, I changed so it's parameterized and the resources got deployed but  
still returned a 404. I also tried deploying the war manually but  
still no luck. The resources get deployed and I see the resource being  
register when looking at the console but the resource never responds.  
I'll debug it some more to see what's up, but it should be noted that  
the unit tests continue to work. So it's isolated to JBoss 4.2.2 in my  
case. I'm going to try it in Tomcat standalone to see if the problem  
is there as well.

Ryan-

On Jul 3, 2008, at 3:41 PM, Bill Burke wrote:

> Ryan, I cannot reproduce this problem.  Everything builds and tests  
> fine.
>
> Maybe its because the JBoss path is hardcoded in the pom?
>
>               <jbossHome>/Users/billburke/jboss/jboss-4.2.2.GA</ 
> jbossHome>
>
>
> Maybe that's another thing you can do in your build refactor?
>
>
>
> Ryan J. McDonough wrote:
>> I'm trying t complete an example app for a few things i am working  
>> on and I am hitting a wall with the latest code. It appears there's  
>> been a regression recently because the resource is located by the  
>> scannotation, but any requests to it will always yield a 404  
>> response. Even executing the basic-integration-test produce the  
>> same results. However, the same resources under beta 5 work just  
>> fine. I logged the following defect to track the issue:
>> http://jira.jboss.com/jira/browse/RESTEASY-70
>> Ryan-
>> ------------------------------------------------------------------------
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> ------------------------------------------------------------------------
>> _______________________________________________
>> 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

Re: [Resteasy-developers] PDF/HTML documentation

[Ryan J. M. <ry...@da...>]

Now if we can make that into a Maven plugin, we'll be fully integrated  
at build time ;)

Ryan-

On Jul 3, 2008, at 3:53 PM, Bill Burke wrote:

> I've written a tool that scrapes our WIKI and generates docbook:
>
> http://wiki.jboss.org/wiki/JBossWiki2Docbook
>
> So, that means next Resteasy release we'll have nice PDF/HTML
> documentation distributed with the release.
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers