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

Re: [Resteasy-developers] IIOImageProvider and new bug

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

Also, maybe the client could request a compression via a new ACCEPT header?

ACCEPT_COMPRESSION

Bill Burke wrote:
> 
> Ryan J. McDonough wrote:
>> Yeah, I was planning on doing that as well, just not right away because 
>> there's a few things I want to do. But I came across something that i 
>> don't thing the spec supports: proving hints to providers.  Currently, 
>> the provider will always use the highest quality settings for images 
>> that can be compressed. However, if I want to use a lower setting 
>> there's not a good way to configure that. You could configure this at 
>> the application level, but if I want to different configurations for 
>> different resources, there's not a portable way to do it.
>>
>> This is an item that will also affect a FileProvider as well: where do 
>> you read and write the files. The Jersey FileProvider uses temp files 
>> which isn't very flexible. If I were writing files, I'd want to specify 
>> a specific location. With that said, I was thinking about something like 
>> this:
>>
>>     @POST
>>     @ConsumeMime("*/*")
>>     @ProviderHints(provider = FileProvider.class,
>>            hints= {@Hint(name="basedir",value="/opt/files")})
>>     public File processFile(File file) {
>>
>> To define the root location for this resource. With this approach, each 
>> resource could write files to different locations. For the 
>> IIOImageProvider, you could do something like this to change the 
>> compression level.
>>
>>     @POST
>>     @ConsumeMime("image/*")
>>     @ProduceMime("image/jpeg")
>>     @ProviderHints(provider = IIOImageProvider.class,
>>           hints= {@Hint(name="compresionQuality",value="0.6")})
>>     public IIOImage transcodeImage(IIOImage image) {
>>
>> In this case, we'd be overriding the default compression value to get a 
>> more compressed image. There's still more thinking to be done, such as 
>> is this just a class-level or method level annotation, etc. However, i 
>> wanted to get some feedback on the idea.
>>
> 
> You don't need a @Hint in this case.  Just create a new IIOImage 
> specific annotation
> 
> @POST
> @ConsumeMime("image/*")
> @ProduceMime("image/jpeg")
> @CompressionQuality(0.2)
> public IIOImage transcodeImage(@CompressionQuality(0.6) image) {...}
> 
> 
> The @CompressionQuality annotation would be 0.6 for the 
> MessageBodyReader, 0.2 for Writer.
> 
> You get the list of annotations on the parameter for input, method for 
> output.
> 

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

Re: [Resteasy-developers] IIOImageProvider and new bug

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

Ryan J. McDonough wrote:
> Yeah, I was planning on doing that as well, just not right away because 
> there's a few things I want to do. But I came across something that i 
> don't thing the spec supports: proving hints to providers.  Currently, 
> the provider will always use the highest quality settings for images 
> that can be compressed. However, if I want to use a lower setting 
> there's not a good way to configure that. You could configure this at 
> the application level, but if I want to different configurations for 
> different resources, there's not a portable way to do it.
> 
> This is an item that will also affect a FileProvider as well: where do 
> you read and write the files. The Jersey FileProvider uses temp files 
> which isn't very flexible. If I were writing files, I'd want to specify 
> a specific location. With that said, I was thinking about something like 
> this:
> 
>     @POST
>     @ConsumeMime("*/*")
>     @ProviderHints(provider = FileProvider.class,
>            hints= {@Hint(name="basedir",value="/opt/files")})
>     public File processFile(File file) {
> 
> To define the root location for this resource. With this approach, each 
> resource could write files to different locations. For the 
> IIOImageProvider, you could do something like this to change the 
> compression level.
> 
>     @POST
>     @ConsumeMime("image/*")
>     @ProduceMime("image/jpeg")
>     @ProviderHints(provider = IIOImageProvider.class,
>           hints= {@Hint(name="compresionQuality",value="0.6")})
>     public IIOImage transcodeImage(IIOImage image) {
> 
> In this case, we'd be overriding the default compression value to get a 
> more compressed image. There's still more thinking to be done, such as 
> is this just a class-level or method level annotation, etc. However, i 
> wanted to get some feedback on the idea.
> 

You don't need a @Hint in this case.  Just create a new IIOImage 
specific annotation

@POST
@ConsumeMime("image/*")
@ProduceMime("image/jpeg")
@CompressionQuality(0.2)
public IIOImage transcodeImage(@CompressionQuality(0.6) image) {...}


The @CompressionQuality annotation would be 0.6 for the 
MessageBodyReader, 0.2 for Writer.

You get the list of annotations on the parameter for input, method for 
output.

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

Re: [Resteasy-developers] Client on Android

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

Yes, I can try to take a look at it.

Bill Burke wrote:
> This sounds really really cool.  Would sure make some noise.  You want 
> to take that on?  I'm only one man ATM :(
>
> Olivier wrote:
>> Bill,
>>
>> Android makes also use of an Apache http package which differs from 
>> http client.
>> Take a look there, the main interface would be HttpClientConnection
>>
>> http://www.androidjavadoc.com/m5-rc15/index.html
>>
>> Olivier
>>
>>
>

Re: [Resteasy-developers] IIOImageProvider and new bug

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

Yeah, I was planning on doing that as well, just not right away  
because there's a few things I want to do. But I came across something  
that i don't thing the spec supports: proving hints to providers.   
Currently, the provider will always use the highest quality settings  
for images that can be compressed. However, if I want to use a lower  
setting there's not a good way to configure that. You could configure  
this at the application level, but if I want to different  
configurations for different resources, there's not a portable way to  
do it.

This is an item that will also affect a FileProvider as well: where do  
you read and write the files. The Jersey FileProvider uses temp files  
which isn't very flexible. If I were writing files, I'd want to  
specify a specific location. With that said, I was thinking about  
something like this:

     @POST
     @ConsumeMime("*/*")
     @ProviderHints(provider = FileProvider.class,
	           hints= {@Hint(name="basedir",value="/opt/files")})
     public File processFile(File file) {

To define the root location for this resource. With this approach,  
each resource could write files to different locations. For the  
IIOImageProvider, you could do something like this to change the  
compression level.

     @POST
     @ConsumeMime("image/*")
     @ProduceMime("image/jpeg")
     @ProviderHints(provider = IIOImageProvider.class,
	           hints= {@Hint(name="compresionQuality",value="0.6")})
     public IIOImage transcodeImage(IIOImage image) {

In this case, we'd be overriding the default compression value to get  
a more compressed image. There's still more thinking to be done, such  
as is this just a class-level or method level annotation, etc.  
However, i wanted to get some feedback on the idea.

Ryan-


On Jun 25, 2008, at 7:59 AM, Bill Burke wrote:

> Cool. Thanks man!
>
> Are you going to document your new providers on the Wiki too?  If  
> not, let me know and I'll get to it sometime.
>
> Ryan J. McDonough wrote:
>> I just committed a IIOImageProvider that could be useful if you  
>> need/ want to handle image data. However, in the process I came  
>> across an  issue when trying to throw a WebApplictaionException  
>> from the  provider. The provider handles image/* since if you may  
>> have an  ImageIO plugin to read additional image formats beyond  
>> what the stock  JDK offers. If the provider cannot read the image,  
>> it attempts to  throw a WebApplictaionException issuing a 406  
>> response with the list  of variants that the provider can support.  
>> However, the client always  gets a 400 response. I have logged the  
>> defect here:
>> http://jira.jboss.com/jira/browse/RESTEASY-63
>> Additionally, I also made some tweaks to the pom's by adding more   
>> project information and additional reports.
>> Ryan-
>> -------------------------------------------------------------------------
>> 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

Re: [Resteasy-developers] Client on Android

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

This sounds really really cool.  Would sure make some noise.  You want 
to take that on?  I'm only one man ATM :(

Olivier wrote:
> Bill,
> 
> Android makes also use of an Apache http package which differs from http 
> client.
> Take a look there, the main interface would be HttpClientConnection
> 
> http://www.androidjavadoc.com/m5-rc15/index.html
> 
> Olivier
> 
> 

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

Re: [Resteasy-developers] IIOImageProvider and new bug

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

Cool. Thanks man!

Are you going to document your new providers on the Wiki too?  If not, 
let me know and I'll get to it sometime.

Ryan J. McDonough wrote:
> I just committed a IIOImageProvider that could be useful if you need/ 
> want to handle image data. However, in the process I came across an  
> issue when trying to throw a WebApplictaionException from the  
> provider. The provider handles image/* since if you may have an  
> ImageIO plugin to read additional image formats beyond what the stock  
> JDK offers. If the provider cannot read the image, it attempts to  
> throw a WebApplictaionException issuing a 406 response with the list  
> of variants that the provider can support. However, the client always  
> gets a 400 response. I have logged the defect here:
> 
> http://jira.jboss.com/jira/browse/RESTEASY-63
> 
> Additionally, I also made some tweaks to the pom's by adding more  
> project information and additional reports.
> 
> Ryan-
> 
> -------------------------------------------------------------------------
> 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

[Resteasy-developers] Client on Android

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

Bill,

Android makes also use of an Apache http package which differs from http 
client.
Take a look there, the main interface would be HttpClientConnection

http://www.androidjavadoc.com/m5-rc15/index.html

Olivier

[Resteasy-developers] IIOImageProvider and new bug

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

I just committed a IIOImageProvider that could be useful if you need/ 
want to handle image data. However, in the process I came across an  
issue when trying to throw a WebApplictaionException from the  
provider. The provider handles image/* since if you may have an  
ImageIO plugin to read additional image formats beyond what the stock  
JDK offers. If the provider cannot read the image, it attempts to  
throw a WebApplictaionException issuing a 406 response with the list  
of variants that the provider can support. However, the client always  
gets a 400 response. I have logged the defect here:

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

Additionally, I also made some tweaks to the pom's by adding more  
project information and additional reports.

Ryan-

Re: [Resteasy-developers] Innovation WAS Re: Back to RestEasy

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

Right now its built off of Apache HttpClient.  Maybe we should fork 
HttpClient and whittle things out?

olivier brand wrote:
> is there any plan to also package the client framework as a single jar that does not include the server side bells ans whistles?
> the main idea behind this would also be able to provide a mobile client implementation such as Android.
> that could also be a pretty nice differentiator.
> 
> 
> Ryan J. McDonough wrote:
>> On Jun 23, 2008, at 7:48 PM, Bill Burke wrote:
>>>
>>>> if these make sense, would it make sense to provide that in  
>>>> resteasy and have a way to differentiate the package with the others?
>>> Here's a few ideas for innovation that I've come up with:
>>>
>>> * We already have a Client Proxy Framework.
>>> * PathInfo rewriting (like URL rewriting, but only the path and only
>>> with JAX-RS expressions)
>>> * Client Framework support for CacheControl
>>> * ServerSide CacheControl support.  Annotate a JAX-RS method with
>>> default CacheControl options.  Cache the marshalled response on the
>>> server to avoid reprocessing and re marshalling.
>>> * Asynchronous HTTP (COMET) support.  Ability to suspend within a  
>>> JAX-RS
>>> request.
>>> * Asynchrnous JAX-RS.  Basically implement a Job Queue with asyncrnous
>>> JAX-RS endpoints.  (See RESTFul Web Services book).
>>> * Combine ideas from Resteasy MOM (the JMS facade I wrote) with Asych
>>> JAX-RS and JBoss Cache and basically create a lightweight, RESTful
>>> ESB-like thingy.
>>> * Provide Ruby, Python, and PHP versions of JAX-RS.  (Not sure if this
>>> is even possible :) )  (Groovy and Scala should just work).
>>>
>> In regards to Ruby, we should take a look RoR's ActiveResource:
>> http://wiki.rubyonrails.org/rails/pages/ActiveResource
>> They've been doing some cool stuff and there's some ideas in there we  
>> might want to consider ourselves.
>>>
>>> Another big thing to differentiate ourselves is with exactly what  
>>> you're
>>> doing.  Provide examples on how to integrate with various  
>>> technologies.
>>>  In your case Spring + Hibernate + OAuth.  I was thinking of writing  
>>> an
>>> Adobe Flex application using JAX-RS as the backend.
>>>
>> I've already got the foundation for such an app that I just need to  
>> repackage. With that said, I'd like to propose that we create project  
>> for some examples. We'd have a subdirectory in the repo such that:
>> resteasy-examples
>> 	+- pom.xml
>> 	+- example1
>> 		+- pom.xml
>> 	+-example2
>> 		+- pom.xml
>> Ideally, I'd like to have a suite of examples much like the Seam  
>> project has. If people are cool with this, I'll have this set up by  
>> the end of the week.
>>> Another way to differentiate is to have a shitload of connectors.   
>>> Some
>>> ideas I have are POI readers/writers (for MS docs).
>> Agreed. I have a few that I started from the original RESTEasy that  
>> didn't get into SVN. They are:
>> IIOImageProvider
>> PDFProvider
>> SVGProvider
>> Some will take a bit more time that others.
>>> Another way to is to have cool applications on top of Resteasy.  i.e.
>>> Resteasy MOM, maybe a automatic Hibernate RESTful interface.
>>>
>> Can you elaborate on the automatic part?
>>> -- 
>>> 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
> 

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

Re: [Resteasy-developers] Innovation WAS Re: Back to RestEasy

[olivier b. <ob...@ya...>]

is there any plan to also package the client framework as a single jar that does not include the server side bells ans whistles?
the main idea behind this would also be able to provide a mobile client implementation such as Android.
that could also be a pretty nice differentiator.


Ryan J. McDonough wrote:
> On Jun 23, 2008, at 7:48 PM, Bill Burke wrote:
>>
>>
>>> if these make sense, would it make sense to provide that in  
>>> resteasy and have a way to differentiate the package with the others?
>> Here's a few ideas for innovation that I've come up with:
>>
>> * We already have a Client Proxy Framework.
>> * PathInfo rewriting (like URL rewriting, but only the path and only
>> with JAX-RS expressions)
>> * Client Framework support for CacheControl
>> * ServerSide CacheControl support.  Annotate a JAX-RS method with
>> default CacheControl options.  Cache the marshalled response on the
>> server to avoid reprocessing and re marshalling.
>> * Asynchronous HTTP (COMET) support.  Ability to suspend within a  
>> JAX-RS
>> request.
>> * Asynchrnous JAX-RS.  Basically implement a Job Queue with asyncrnous
>> JAX-RS endpoints.  (See RESTFul Web Services book).
>> * Combine ideas from Resteasy MOM (the JMS facade I wrote) with Asych
>> JAX-RS and JBoss Cache and basically create a lightweight, RESTful
>> ESB-like thingy.
>> * Provide Ruby, Python, and PHP versions of JAX-RS.  (Not sure if this
>> is even possible :) )  (Groovy and Scala should just work).
>>
> In regards to Ruby, we should take a look RoR's ActiveResource:
> http://wiki.rubyonrails.org/rails/pages/ActiveResource
> They've been doing some cool stuff and there's some ideas in there we  
> might want to consider ourselves.
>>
>>
>> Another big thing to differentiate ourselves is with exactly what  
>> you're
>> doing.  Provide examples on how to integrate with various  
>> technologies.
>>  In your case Spring + Hibernate + OAuth.  I was thinking of writing  
>> an
>> Adobe Flex application using JAX-RS as the backend.
>>
> I've already got the foundation for such an app that I just need to  
> repackage. With that said, I'd like to propose that we create project  
> for some examples. We'd have a subdirectory in the repo such that:
> resteasy-examples
> 	+- pom.xml
> 	+- example1
> 		+- pom.xml
> 	+-example2
> 		+- pom.xml
> Ideally, I'd like to have a suite of examples much like the Seam  
> project has. If people are cool with this, I'll have this set up by  
> the end of the week.
>> Another way to differentiate is to have a shitload of connectors.   
>> Some
>> ideas I have are POI readers/writers (for MS docs).
> Agreed. I have a few that I started from the original RESTEasy that  
> didn't get into SVN. They are:
> IIOImageProvider
> PDFProvider
> SVGProvider
> Some will take a bit more time that others.
>> Another way to is to have cool applications on top of Resteasy.  i.e.
>> Resteasy MOM, maybe a automatic Hibernate RESTful interface.
>>
> Can you elaborate on the automatic part?
>> -- 
>> 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

Re: [Resteasy-developers] Innovation WAS Re: Back to RestEasy

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

On Jun 23, 2008, at 7:48 PM, Bill Burke wrote:
>
>
>> if these make sense, would it make sense to provide that in  
>> resteasy and have a way to differentiate the package with the others?
> Here's a few ideas for innovation that I've come up with:
>
> * We already have a Client Proxy Framework.
> * PathInfo rewriting (like URL rewriting, but only the path and only
> with JAX-RS expressions)
> * Client Framework support for CacheControl
> * ServerSide CacheControl support.  Annotate a JAX-RS method with
> default CacheControl options.  Cache the marshalled response on the
> server to avoid reprocessing and re marshalling.
> * Asynchronous HTTP (COMET) support.  Ability to suspend within a  
> JAX-RS
> request.
> * Asynchrnous JAX-RS.  Basically implement a Job Queue with asyncrnous
> JAX-RS endpoints.  (See RESTFul Web Services book).
> * Combine ideas from Resteasy MOM (the JMS facade I wrote) with Asych
> JAX-RS and JBoss Cache and basically create a lightweight, RESTful
> ESB-like thingy.
> * Provide Ruby, Python, and PHP versions of JAX-RS.  (Not sure if this
> is even possible :) )  (Groovy and Scala should just work).
>

In regards to Ruby, we should take a look RoR's ActiveResource:

http://wiki.rubyonrails.org/rails/pages/ActiveResource

They've been doing some cool stuff and there's some ideas in there we  
might want to consider ourselves.

>
>
> Another big thing to differentiate ourselves is with exactly what  
> you're
> doing.  Provide examples on how to integrate with various  
> technologies.
>  In your case Spring + Hibernate + OAuth.  I was thinking of writing  
> an
> Adobe Flex application using JAX-RS as the backend.
>

I've already got the foundation for such an app that I just need to  
repackage. With that said, I'd like to propose that we create project  
for some examples. We'd have a subdirectory in the repo such that:

resteasy-examples
	+- pom.xml
	+- example1
		+- pom.xml
	+-example2
		+- pom.xml

Ideally, I'd like to have a suite of examples much like the Seam  
project has. If people are cool with this, I'll have this set up by  
the end of the week.

> Another way to differentiate is to have a shitload of connectors.   
> Some
> ideas I have are POI readers/writers (for MS docs).

Agreed. I have a few that I started from the original RESTEasy that  
didn't get into SVN. They are:

IIOImageProvider
PDFProvider
SVGProvider

Some will take a bit more time that others.

> Another way to is to have cool applications on top of Resteasy.  i.e.
> Resteasy MOM, maybe a automatic Hibernate RESTful interface.
>

Can you elaborate on the automatic part?

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

Re: [Resteasy-developers] Multipart

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

On Jun 20, 2008, at 4:14 PM, Bill Burke wrote:
>
> I think you'll need a Multipart abstraction where the resource methods
> can inject what type they want marshalled into.
>
> public void post(Multipart parts) {
>
>    MyJaxb jaxb = parts.getPart(0).read(MyJaxb.class);
>    JPEG jpg = parts.getPart(1).read(JPEG.class);
>
> or
>
>    MyJaxb jaxb = parts.get("myField").read(MyJaxb.class);

I was even thinking a bit more direct for read operations:

MyJaxb jaxb = parts.get(0,MyJaxb.class);

This variation seems to work out the best in my tests so far. I've  
gotten the basic reader details functioning, but it'll require more  
parts as we'll need our own Multipart and BodyPart classes. But it  
should be much more flexible than having the developer have to parse  
each part themselves.


>
> Alternatively, you could do:
>
> public void post(@Multipart({MyJaxB.class, JPEG.class}) List parts);
> But that only works if the format of the buffer is fixed and defined  
> and
> it seems kinda quirky and quickly unreadable.

I tried a variation on this whereby you'd have:

void post(@MimePart(0) String partOne, @MimePart(1) MyJAX object) {...

This still has the same limitations as you pointed out, but it's a bit  
more akin to @QueryParam, etc. The problem is that reading the data  
for the 2nd part was always failing. As of now, a JavaMail multipart  
provider has already.

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

[Resteasy-developers] DataSourceProvider and MimeMultipartProviders commited

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

I just committed 2 new providers:

DataSourceProvider: this satisfies one of the standard entity providers

MimeMultipartProvider: works withe the  
javax.mail.internet.MimeMultipart to provide multipart functionality.

AbstractEntityProvider: a shared base class between both new provider  
classes.

Because of the abstract class, i had to make some tweaks to the  
MessageBodyKey constructor in ResteasyProviderFactory so that it could  
work an abstract class as well as interfaces. The root pom.xml was  
also updated to include the java mail dependency.

Ryan-

[Resteasy-developers] Innovation WAS Re: Back to RestEasy

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

olivier brand wrote:
> I will get to it. in the meantime, I as discussing with a friend of mine and a few questions were raised
> 
> 1) why didn't they include regexp capabilities with the GET or PATH annotations?


No regexp capabilities were added because there is a W3C rft on it.  The 
problem with the RFC though is a) Its not finished, b) It really is only 
useful for something like URL rewriting.  JAX-RS does have a limited 
form of expressions, i.e.:

/a/something{foo}-{bar}/{param}xxxxx

Basically inserting @PathParams anywhere within a URI string.

You also have:

@Path(value="/stuff", limited = false)

limited is like "*".  So the expression would be /stuff/* in reality.

With that you can probably do *most* things, but not all.  Personally, 
I'd like to add the ability to specify query strings in @Path.  It would 
allow people to overload @POST.  (Maybe that isn't such a good thing 
though...)


> 2) why cont negociation just based on mime types and not any header fields?
> 

Can you give an example of what you mean?  There are some variant 
processing where you can do matches based on ACCEPT, ACCEPT_LANGUAGE, 
and ACCEPT_ENCODING parameters, but it is manual.




> if these make sense, would it make sense to provide that in resteasy and have a way to differentiate the package with the others?
Here's a few ideas for innovation that I've come up with:

* We already have a Client Proxy Framework.
* PathInfo rewriting (like URL rewriting, but only the path and only 
with JAX-RS expressions)
* Client Framework support for CacheControl
* ServerSide CacheControl support.  Annotate a JAX-RS method with 
default CacheControl options.  Cache the marshalled response on the 
server to avoid reprocessing and re marshalling.
* Asynchronous HTTP (COMET) support.  Ability to suspend within a JAX-RS 
request.
* Asynchrnous JAX-RS.  Basically implement a Job Queue with asyncrnous 
JAX-RS endpoints.  (See RESTFul Web Services book).
* Combine ideas from Resteasy MOM (the JMS facade I wrote) with Asych 
JAX-RS and JBoss Cache and basically create a lightweight, RESTful 
ESB-like thingy.
* Provide Ruby, Python, and PHP versions of JAX-RS.  (Not sure if this 
is even possible :) )  (Groovy and Scala should just work).


Another big thing to differentiate ourselves is with exactly what you're 
doing.  Provide examples on how to integrate with various technologies. 
  In your case Spring + Hibernate + OAuth.  I was thinking of writing an 
Adobe Flex application using JAX-RS as the backend.

Another way to differentiate is to have a shitload of connectors.  Some 
ideas I have are POI readers/writers (for MS docs).

Another way to is to have cool applications on top of Resteasy.  i.e. 
Resteasy MOM, maybe a automatic Hibernate RESTful interface.

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

[Resteasy-developers] Multipart

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

Ryan J. McDonough wrote:
>> Still working on multipart 
>> stuff? 
> 
> Yeah and I'm wrapping it up too. I'm finalizing the basic Multipart 
> stuff now and I was using JAF and JavaMail. I have the basic multipart 
> stuff working and now moving on to being able to do the idea you 
> had originally with a List:
> 
> @PUT
> @ConsumeMime("multipart/form-data")
> @ProduceMime("text/plain")
> public String putData(List<?> parts) {
> 
> Here's the kinks with that one:
> 
> in the read case, we don't have the class information for the different 
> parts. If every element is the same in the List, it could be ok. 
> However, most of the time I've had to work with Multipart, I've always 
> dealt with multiple data types. So you'd have 2 XML documents, an image, 
> etc. In that case, we only have the data and mime type and no class 
> info. With that said, we can't use createMessageBodyReader() to locate a 
> suitable MessageBodyReader. With JAXB, this would be a real challenge 
> because you can't say: here's some XML, now unmarshall it and find the 
> appropriate class. Now using JAF kinda works, but then you end up with a 
> ByteArrayInputStream. Any thoughts? 
> 

I think you'll need a Multipart abstraction where the resource methods 
can inject what type they want marshalled into.

public void post(Multipart parts) {

    MyJaxb jaxb = parts.getPart(0).read(MyJaxb.class);
    JPEG jpg = parts.getPart(1).read(JPEG.class);

or

    MyJaxb jaxb = parts.get("myField").read(MyJaxb.class);

}

Alternatively, you could do:

public void post(@Multipart({MyJaxB.class, JPEG.class}) List parts); 
But that only works if the format of the buffer is fixed and defined and 
it seems kinda quirky and quickly unreadable.



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

[Resteasy-developers] Seam and RESTeasy blog

[Jay B. <te...@gm...>]

Here is a quick blog of some of my thoughts on $SUBJECT

http://in.relation.to/Bloggers/SeamAndRESTeasy

-Jay

-- 
blog: http://in.relation.to/Bloggers/Jay

Re: [Resteasy-developers] RESTeasy and Hot Deployed Seam Components

[Jay B. <te...@gm...>]

It sounds like this is similar to what I was thinking about with seam at the
NEJUG talk .  It is not really integration, more compatibility.

Take this example : I have a Seam component (EJB or POJO does not matter -
but most likely stateless) and I also want to have if accessible through a
restful call, I should be able to put the correct annotations on it with
resteasy and have it work.  This would mean either a combined WAR with seam
app, and resteasy servlet, or separate wars in an EAR, or something like
that.

I see seam and resteasy working together really two primary ways.  Either
the way described above -  as different ways to access/manipulate the
underlying component.  The other would be Seam using restful calls
internally as a result of a user action, or to pull data for the UI.  These
internal restful calls would not really be integration either, but more like
a data source, or remote EJB call via rest.

The question is - do the co-exist well, not do work together and know about
each other.

My $.02,

-Jay

On Wed, Jun 18, 2008 at 9:30 PM, Bill Burke <bb...@re...> wrote:

> No, I don't have Seam integration.  I'm also not sure it fits.  Seam
> maintains a conversation between the client and the server which is kind
> of against the REST principal of statelessness.  If you're just looking
> to be able to use the @PersistenceContext annotation to inject JPA
> references, you could use an EJB to do this.  Just use the JAX-RS
> annotations on the EJB's business interface and use the
>
> resteasy.jndi.resources
>
>
> http://wiki.jboss.org/wiki/RESTeasyEJBIntegration
>
> for more information.
>
> da kna wrote:
> > Hello,
> >
> > I'm trying to get RESTeasy to work with Seam hot-deployed components,
> > but I can't figure it out. Because this is a mailing list, I will copy
> > my posting from seamframework.org
> > <
> http://seamframework.org/Community/HotDeploymentEntityManagerAndRESTeasyProblem
> >.
> > If someone can give me some hints,  I will post them to the seam forum
> > as well.
> >
> > My project is using seam components, no EJBs. So all my action classes
> > go to WEB-INF/dev and therefore are not visible for classes deployed
> > outside, because of the custom seam class loader, right?
> >
> >
> > So when I want to use a Seam and JAX-RS annotated action class (@NAME,
> > @PATH at Class, and @GET at method) with RESTeasy, it fails to find it,
> > because it scans in WEB-INF/classes by default. Even when I configure
> > RESTeasy with context param resteasy.resources including the fully
> > qualified class name, I get a ClassNotFoundException.
> >
> >
> > Ok, then I tried to put the action class in model directory, changed
> > package name and corresponding resteasy.resources param. Now RESTeasy
> > finds the class and tries to process the @GET marked action method, but
> > it fails with an NPE when using the injected EntityManager. I guess
> > there is no DI happening? But I want to load the RESTeasy/JAXB annotated
> > entity...
> >
> >
> > So, the questions are:
> >
> >
> > Is there a way for RESTeasy to load seam components in WEB-INF/dev?
> >
> >
> > If not, can I use the @In Annotation for the EntityManager to get access
> > to seam managed persistence context in RESTeasy?
> >
> >
> > All the examples I found are using EJB/Seam components, not regular seam
> > beans. Anyone got this to work? Thanks for any pointers...
> >
> >
> > Regen
> >
> >
> > PS: I'm using RESTeasy Beta 5, Seam 2.0.2.SP1, JBoss 4.2.2.GA
> >
> >
> > ------------------------------------------------------------------------
> > Gesendet von Yahoo! Mail
> > <
> http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52427/*http://de.overview.mail.yahoo.com
> >.
> >
> > Dem pfiffigeren Posteingang.
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > 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
>



-- 
blog: http://in.relation.to/Bloggers/Jay

Re: [Resteasy-developers] RESTeasy and Hot Deployed Seam Components

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

No, I don't have Seam integration.  I'm also not sure it fits.  Seam 
maintains a conversation between the client and the server which is kind 
of against the REST principal of statelessness.  If you're just looking 
to be able to use the @PersistenceContext annotation to inject JPA 
references, you could use an EJB to do this.  Just use the JAX-RS 
annotations on the EJB's business interface and use the

resteasy.jndi.resources


http://wiki.jboss.org/wiki/RESTeasyEJBIntegration

for more information.

da kna wrote:
> Hello,
> 
> I'm trying to get RESTeasy to work with Seam hot-deployed components, 
> but I can't figure it out. Because this is a mailing list, I will copy 
> my posting from seamframework.org 
> <http://seamframework.org/Community/HotDeploymentEntityManagerAndRESTeasyProblem>. 
> If someone can give me some hints,  I will post them to the seam forum 
> as well.
> 
> My project is using seam components, no EJBs. So all my action classes 
> go to WEB-INF/dev and therefore are not visible for classes deployed 
> outside, because of the custom seam class loader, right?
> 
> 
> So when I want to use a Seam and JAX-RS annotated action class (@NAME, 
> @PATH at Class, and @GET at method) with RESTeasy, it fails to find it, 
> because it scans in WEB-INF/classes by default. Even when I configure 
> RESTeasy with context param resteasy.resources including the fully 
> qualified class name, I get a ClassNotFoundException.
> 
> 
> Ok, then I tried to put the action class in model directory, changed 
> package name and corresponding resteasy.resources param. Now RESTeasy 
> finds the class and tries to process the @GET marked action method, but 
> it fails with an NPE when using the injected EntityManager. I guess 
> there is no DI happening? But I want to load the RESTeasy/JAXB annotated 
> entity...
> 
> 
> So, the questions are:
> 
> 
> Is there a way for RESTeasy to load seam components in WEB-INF/dev?
> 
> 
> If not, can I use the @In Annotation for the EntityManager to get access 
> to seam managed persistence context in RESTeasy?
> 
> 
> All the examples I found are using EJB/Seam components, not regular seam 
> beans. Anyone got this to work? Thanks for any pointers...
> 
> 
> Regen
> 
> 
> PS: I'm using RESTeasy Beta 5, Seam 2.0.2.SP1, JBoss 4.2.2.GA
> 
> 
> ------------------------------------------------------------------------
> Gesendet von Yahoo! Mail 
> <http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52427/*http://de.overview.mail.yahoo.com>. 
> 
> Dem pfiffigeren Posteingang.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] RESTeasy and Hot Deployed Seam Components

[Ryan M. <rmc...@sa...>]

Regan,

 

Seam support is something that I'd like to get in at some point, and I
did have it working in some of the very early versions of RESTEasy. I
doubt we'd be able to get Seam support in 1.0, but it's on my radar for
a future release. 

 

To answer your question about the use of a Seam-managed EntityManager in
a Resource: you've have to be able to have the Resource double as a Seam
component otherwise you will get an NPE. Once I get the MultipartData
support wrapped up, I'll have a look at the class loader stuff and
proper Seam integration.

 

Ryan-

 

Ryan J. McDonough 
Platform, Specialist Java EE | Sapient 
25 First Street
Cambridge, MA 02141
desk:  +1 617 761 1611
mobile: +1 508 735 4503
fax: +1 617 621 1300


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer. 

________________________________

From: res...@li...
[mailto:res...@li...] On Behalf Of
da kna
Sent: Wednesday, June 18, 2008 8:46 AM
To: res...@li...
Subject: [Resteasy-developers] RESTeasy and Hot Deployed Seam Components

 

Hello,

I'm trying to get RESTeasy to work with Seam hot-deployed components,
but I can't figure it out. Because this is a mailing list, I will copy
my posting from seamframework.org
<http://seamframework.org/Community/HotDeploymentEntityManagerAndRESTeas
yProblem> . If someone can give me some hints,  I will post them to the
seam forum as well.

My project is using seam components, no EJBs. So all my action classes
go to WEB-INF/dev and therefore are not visible for classes deployed
outside, because of the custom seam class loader, right? 

 

So when I want to use a Seam and JAX-RS annotated action class (@NAME,
@PATH at Class, and @GET at method) with RESTeasy, it fails to find it,
because it scans in WEB-INF/classes by default. Even when I configure
RESTeasy with context param resteasy.resources including the fully
qualified class name, I get a ClassNotFoundException. 

 

Ok, then I tried to put the action class in model directory, changed
package name and corresponding resteasy.resources param. Now RESTeasy
finds the class and tries to process the @GET marked action method, but
it fails with an NPE when using the injected EntityManager. I guess
there is no DI happening? But I want to load the RESTeasy/JAXB annotated
entity... 

 

So, the questions are: 

 

Is there a way for RESTeasy to load seam components in WEB-INF/dev? 

 

If not, can I use the @In Annotation for the EntityManager to get access
to seam managed persistence context in RESTeasy? 

 

All the examples I found are using EJB/Seam components, not regular seam
beans. Anyone got this to work? Thanks for any pointers...

 

Regen


PS: I'm using RESTeasy Beta 5, Seam 2.0.2.SP1, JBoss 4.2.2.GA

 

________________________________

Gesendet von Yahoo! Mail
<http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http:/us.rd.yahoo.c
om/evt=52427/*http:/de.overview.mail.yahoo.com> . 
Dem pfiffigeren Posteingang.

[Resteasy-developers] RESTeasy and Hot Deployed Seam Components

[da k. <reg...@ya...>]

Hello,

I'm trying to get RESTeasy to work with Seam hot-deployed components, but I can't figure it out. Because this is a mailing list, I will copy my posting from seamframework.org . If someone can give me some hints,  I will post them to the seam forum as well.


My project is using seam components, no EJBs. So all my action classes
go to WEB-INF/dev and therefore are not visible for classes deployed
outside, because of the custom seam class loader, right? 



So when I want to use a Seam and JAX-RS annotated
action class (@NAME, @PATH at Class, and @GET at method) with RESTeasy,
it fails to find it, because it scans in WEB-INF/classes by default.
Even when I configure RESTeasy with context param resteasy.resources including the fully qualified class name, I get a ClassNotFoundException. 




Ok, then I tried to put the action class in model directory, changed package name and corresponding resteasy.resources
param. Now RESTeasy finds the class and tries to process the @GET
marked action method, but it fails with an NPE when using the injected
EntityManager. I guess there is no DI happening? But I want to load the
RESTeasy/JAXB annotated entity... 




So, the questions are: 




Is there a way for RESTeasy to load seam components in WEB-INF/dev? 




If not, can I use the @In Annotation for the EntityManager to get access to seam managed persistence context in RESTeasy? 



All the examples I found are using EJB/Seam
components, not regular seam beans. Anyone got this to work? Thanks for
any pointers...
Regen
PS: I'm using RESTeasy Beta 5, Seam 2.0.2.SP1, JBoss 4.2.2.GA




      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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