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

Re: [Resteasy-developers] Seam integration

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

Cool! I'm very interested as to how this is being implemented. Also,  
is this integration going to be part of Seam, RESTEasy, or as a sub- 
module of RESTEasy?

Ryan-

On Jul 11, 2008, at 11:40 AM, Bill Burke wrote:

> FYI,  Christian Bauer is doing the Seam integration for Resteasy.   
> It is
> mostly done.
> -- 
> 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

Re: [Resteasy-developers] ClientResponse + '303' See Other

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

Adam Jordens wrote:
> Perfect, thanks for the timely responses.
> 
> I think I was getting hung up on wanting to keep the interface of the
> resource the same as the client.
> 

I originally thought that this was possible (same interface for client 
and server), but it just can't be done all the time.  Default and/or 
optional parameters screw things up.  There's no need for Subresource 
locators on the client (I can't really support them either).

Bill

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

Re: [Resteasy-developers] ClientResponse + '303' See Other

[Adam J. <Ada...@ge...>]

Perfect, thanks for the timely responses.

I think I was getting hung up on wanting to keep the interface of the
resource the same as the client.

Once I separated the two, things look good.


Cheers,
Adam

On 11/07/08 3:47 PM, "Bill Burke" <bb...@re...> wrote:

> 
> 
> Adam Jordens wrote:
>> Heh.  I was wondering if I was going to confuse anyone.
>> 
>> Essentially what I want to do is have the value of a Response (with a status
>> of 303) returned to the caller of the client framework.
>> 
>> From what I had seen (and read?), if the client framework caller wanted
>> access to the actual response itself, it needed to be actually returned as a
>> ClientResponse.  Am I mistaken?
>> 
>> The interaction is as follows:
>> 
>> Client A (via ClientFramework) POSTS to the '/searches/' resource and gets a
>> ClientResponse (or Response) back with a status code and ideally an entity.
>> 
> 
> The client and server would be seperate classes/interfaces:
> 
> client
> 
> @Path("/search")
> public interface SearchEngineClient {
> 
> 
>     @POST
>     @ConsumeMime("application/xml")
>     @ProduceMime("*/*")
>     ClientResponse<Long> createSearch(ExtQuery);
> }
> 
> 
> server:
> 
> @Path("/search")
> public class SearchEngine {
> 
>     @POST
>     @ConsumeMime("application/xml")
>     @ProduceMime("*/*")
>     Response createSearch(ExtQuery) {
>       ...
>     }
> }
> 
> 
> Is the problem that you can't get at a ClientResponse that has no entity
> within it?
> 
> Bill

Re: [Resteasy-developers] ClientResponse + '303' See Other

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

Adam Jordens wrote:
> Heh.  I was wondering if I was going to confuse anyone.
> 
> Essentially what I want to do is have the value of a Response (with a status
> of 303) returned to the caller of the client framework.
> 
> From what I had seen (and read?), if the client framework caller wanted
> access to the actual response itself, it needed to be actually returned as a
> ClientResponse.  Am I mistaken?
> 
> The interaction is as follows:
> 
> Client A (via ClientFramework) POSTS to the '/searches/' resource and gets a
> ClientResponse (or Response) back with a status code and ideally an entity.
> 

The client and server would be seperate classes/interfaces:

client

@Path("/search")
public interface SearchEngineClient {


    @POST
    @ConsumeMime("application/xml")
    @ProduceMime("*/*")
    ClientResponse<Long> createSearch(ExtQuery);
}


server:

@Path("/search")
public class SearchEngine {

    @POST
    @ConsumeMime("application/xml")
    @ProduceMime("*/*")
    Response createSearch(ExtQuery) {
      ...
    }
}


Is the problem that you can't get at a ClientResponse that has no entity 
within it?

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

Re: [Resteasy-developers] ClientResponse + '303' See Other

[Adam J. <Ada...@ge...>]

Heh.  I was wondering if I was going to confuse anyone.

Essentially what I want to do is have the value of a Response (with a status
of 303) returned to the caller of the client framework.

>From what I had seen (and read?), if the client framework caller wanted
access to the actual response itself, it needed to be actually returned as a
ClientResponse.  Am I mistaken?

The interaction is as follows:

Client A (via ClientFramework) POSTS to the '/searches/' resource and gets a
ClientResponse (or Response) back with a status code and ideally an entity.

Client B (via Web Browser) POSTS to '/searches/' and gets redirected to the
target of the Location header.


Does that make any more sense?

As for the CustomClientResponse, it's nothing more than a dummy
implementation of the ClientResponse interface to save me from doing a new
ClientResponse(response.getEntity(), response.getStatus(), etc.).

It's probably ignorable.


Regards,
Adam


On 11/07/08 3:16 PM, "Bill Burke" <bb...@re...> wrote:

> I'm confused on what you're trying to do.  You're creating a
> ClientResponse on the serverside?  Why?  Why do you need a custom
> ClientResponse object?  ClientResponse should only be used with a client
> interface.
> 
> Adam Jordens wrote:
>> Currently running beta5 and have run into a bit of an issue surrounding
>> a resource that returns a ClientResponse with a /303 ­ See Other/
>> response code and the appropriate /Location: /header.
>> 
>> Essentially I¹m trying to implement a POST then GET.
>> 
>> @POST
>> @ConsumeMime("application/xml")
>> @ProduceMime(³*/*²)
>> @Path("/search")
>> public ClientResponse<Long> createSearch(ExtQuery query)
>> {
>>     ...
>>     return new 
>> CustomClientResponse(Response.seeOther(uri).entity(specimenSearch.getId()).bu
>> ild());
>> }
>> 
>> CustomClientResponse is just an implementation of a /ClientResponse
>> /that effectively wraps the status, entity and headers from a normal
>> Response.
>> 
>> What I¹m hoping to be able to do is 2 things:
>> 
>>     * Use the client-side framework to invoke this createSearch() and
>>       have access to the returning ClientResource.  I could either look
>>       at the headers for the redirected location or just grab the entity
>>       and invoke a GET on another resource.
>>     * Use a web browser and POST to /search and have the browser
>>       automatically redirect with a GET request to the /303 ­ See Other/
>>       resource.
>> 
>> 
>> Strangely enough, I¹ve been able to make get them both working (/not
>> having the @ProduceMime(³*/*²) was causing some grief/).
>> 
>> To get things working I had to do a minor patch to the /MethodInjectorImpl/.
>> 
>> *Added *(/to MethodInjectorImpl.java.invoke()/):
>> if (method.getReturnType().equals(ClientResponse.class))
>> {
>>     ClientResponse clientResponse = (ClientResponse) rtn;
>>     ResponseImpl response = new ResponseImpl();
>>     response.setEntity(rtn);
>>     response.setStatus(clientResponse.getStatus());
>>     response.setMetadata(clientResponse.getHeaders());
>>     return response;
>> }
>> 
>> Previously it looked like it was just creating a normal Response that
>> wrapped the ClientResponse but didn¹t inherit any of its status or headers.
>> 
>> At this stage, the client-side framework is able to POST to /search and
>> get back the appropriate ClientResponse, and the web browser was able to
>> POST to /search and get redirected to the appropriate resource.  Success!
>> 
>> 
>> Now my biggest question is around whether or not these types of
>> operations should be supported?
>> 
>> 
>> 
>> Thanks,
>> Adam
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> -------------------------------------------------------------------------
>> 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

Re: [Resteasy-developers] ClientResponse + '303' See Other

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

I'm confused on what you're trying to do.  You're creating a 
ClientResponse on the serverside?  Why?  Why do you need a custom 
ClientResponse object?  ClientResponse should only be used with a client 
interface.

Adam Jordens wrote:
> Currently running beta5 and have run into a bit of an issue surrounding 
> a resource that returns a ClientResponse with a /303 – See Other/ 
> response code and the appropriate /Location: /header.  
> 
> Essentially I’m trying to implement a POST then GET.
> 
> @POST
> @ConsumeMime("application/xml")
> @ProduceMime(“*/*”)
> @Path("/search")
> public ClientResponse<Long> createSearch(ExtQuery query)
> {
>     ...
>     return new 
> CustomClientResponse(Response.seeOther(uri).entity(specimenSearch.getId()).build());
> }
> 
> CustomClientResponse is just an implementation of a /ClientResponse 
> /that effectively wraps the status, entity and headers from a normal 
> Response.
> 
> What I’m hoping to be able to do is 2 things:
> 
>     * Use the client-side framework to invoke this createSearch() and
>       have access to the returning ClientResource.  I could either look
>       at the headers for the redirected location or just grab the entity
>       and invoke a GET on another resource.
>     * Use a web browser and POST to /search and have the browser
>       automatically redirect with a GET request to the /303 – See Other/
>       resource.
> 
> 
> Strangely enough, I’ve been able to make get them both working (/not 
> having the @ProduceMime(“*/*”) was causing some grief/).
> 
> To get things working I had to do a minor patch to the /MethodInjectorImpl/.
> 
> *Added *(/to MethodInjectorImpl.java.invoke()/):
> if (method.getReturnType().equals(ClientResponse.class))
> {
>     ClientResponse clientResponse = (ClientResponse) rtn;
>     ResponseImpl response = new ResponseImpl();             
>     response.setEntity(rtn);
>     response.setStatus(clientResponse.getStatus());
>     response.setMetadata(clientResponse.getHeaders());
>     return response;
> }
> 
> Previously it looked like it was just creating a normal Response that 
> wrapped the ClientResponse but didn’t inherit any of its status or headers.
> 
> At this stage, the client-side framework is able to POST to /search and 
> get back the appropriate ClientResponse, and the web browser was able to 
> POST to /search and get redirected to the appropriate resource.  Success!
> 
> 
> Now my biggest question is around whether or not these types of 
> operations should be supported?
> 
> 
> 
> Thanks,
> Adam
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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] RES: Reiner

[Rafael P. N. <raf...@me...>]

Hi,
What kind of tutorial do you looking for?
Just create a new project(Java/JEE, etc) in Eclipse with the content of the folder 'resteasy-jaxrs.war'(WEB-INF, libs and web.xml).
After that just use this as an usual web project.
With the 'jaxrs-api-1.0-beta-5.jar' inside the lib folder, you can use the annotations to create the REST services.

Is this you want to know? Or I didn´t understand the question...

Rafael

-----Mensagem original-----
De: res...@li... [mailto:res...@li...] Em nome de Bill Burke
Enviada em: quarta-feira, 9 de julho de 2008 12:59
Para: Reiner Rodriguez Alvarez
Cc: res...@li...
Assunto: Re: [Resteasy-developers] Reiner

not an eclipse user myself... maybe ryan can help u?

Reiner Rodriguez Alvarez wrote:
> Hi
> 
> I am new  on resteasy ...
> 
> I like to find some good  tutorial using resteasy in Eclipse ...any help 
> please.
> 
>  
> 
> Thanks
> 
>  
> 
> rro...@mt...
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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


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

Re: [Resteasy-developers] Interceptors

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

On 11 Jul 2008, at 17:30, Bill Burke wrote:

>
>
> Martin Algesten wrote:
>> Why is the interception done on a (for a lack of better word)  
>> "global" level rather than for the resource method. When I first  
>> read your description I envisaged something like what I'm  
>> describing below - or am I getting it all wrong?
>> public class MyResource
>> {
>>  @GET
>>  @Path("{myId}")
>>  @BeforeMarshalling(MyInterceptor.class)
>>  @AfterMarshalling(MyInterceptor.class)
>>  public SomeObject loadSomethingCool( @PathParam("myId") int myId )
>>  {
>>  }
>> }
>
> I can see wanting to do some fine-grain interceptor binding using  
> @GET, @POST, and even @Path.
>
> I don't understand why you return an object from your  
> "loadSomethingCool" method.

Uhm?

As opposed to returning a Response or void? Not sure I follow. This is  
how I normally do a resource method that returns some object I want  
marshalled to the client.

M

[Resteasy-developers] ClientResponse + '303' See Other

[Adam J. <Ada...@ge...>]

Currently running beta5 and have run into a bit of an issue surrounding a
resource that returns a ClientResponse with a 303 ­ See Other response code
and the appropriate Location: header.

Essentially I¹m trying to implement a POST then GET.

@POST
@ConsumeMime("application/xml")
@ProduceMime(³*/*²)
@Path("/search")
public ClientResponse<Long> createSearch(ExtQuery query)
{
    ...
    return new 
CustomClientResponse(Response.seeOther(uri).entity(specimenSearch.getId()).b
uild());
}

CustomClientResponse is just an implementation of a ClientResponse that
effectively wraps the status, entity and headers from a normal Response.

What I¹m hoping to be able to do is 2 things:
* Use the client-side framework to invoke this createSearch() and have
access to the returning ClientResource.  I could either look at the headers
for the redirected location or just grab the entity and invoke a GET on
another resource. 
* Use a web browser and POST to /search and have the browser automatically
redirect with a GET request to the 303 ­ See Other resource.

Strangely enough, I¹ve been able to make get them both working (not having
the @ProduceMime(³*/*²) was causing some grief).

To get things working I had to do a minor patch to the MethodInjectorImpl.

Added (to MethodInjectorImpl.java.invoke()):
if (method.getReturnType().equals(ClientResponse.class))
{
    ClientResponse clientResponse = (ClientResponse) rtn;
    ResponseImpl response = new ResponseImpl();
    response.setEntity(rtn);
    response.setStatus(clientResponse.getStatus());
    response.setMetadata(clientResponse.getHeaders());
    return response;
}

Previously it looked like it was just creating a normal Response that
wrapped the ClientResponse but didn¹t inherit any of its status or headers.

At this stage, the client-side framework is able to POST to /search and get
back the appropriate ClientResponse, and the web browser was able to POST to
/search and get redirected to the appropriate resource.  Success!


Now my biggest question is around whether or not these types of operations
should be supported?



Thanks,
Adam

[Resteasy-developers] protocol buffers next?

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

After YAML perhaps this would be something similar to look at?

http://code.google.com/apis/protocolbuffers/docs/overview.html

M

Re: [Resteasy-developers] Interceptors

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

Martin Algesten wrote:
> 
> Why is the interception done on a (for a lack of better word) "global" 
> level rather than for the resource method. When I first read your 
> description I envisaged something like what I'm describing below - or am 
> I getting it all wrong?
> 
> 
> public class MyResource
> {
> 
>   @GET
>   @Path("{myId}")
>   @BeforeMarshalling(MyInterceptor.class)
>   @AfterMarshalling(MyInterceptor.class)
>   public SomeObject loadSomethingCool( @PathParam("myId") int myId )
>   {
>   }
> 
> 
> }
> 

I can see wanting to do some fine-grain interceptor binding using @GET, 
@POST, and even @Path.

I don't understand why you return an object from your 
"loadSomethingCool" method.

Bill


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

[Resteasy-developers] Seam integration

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

FYI,  Christian Bauer is doing the Seam integration for Resteasy.  It is 
mostly done.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Interceptors

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

Why is the interception done on a (for a lack of better word)  
"global" level rather than for the resource method. When I first read  
your description I envisaged something like what I'm describing below  
- or am I getting it all wrong?


public class MyResource
{

   @GET
   @Path("{myId}")
   @BeforeMarshalling(MyInterceptor.class)
   @AfterMarshalling(MyInterceptor.class)
   public SomeObject loadSomethingCool( @PathParam("myId") int myId )
   {
   }


}

Could also envisage putting the interceptor annotations on the class  
to work for all methods in the class.

public class MyInterceptor implements BeforeMarshallingInterecptor,  
AfterMarshallingInterceptor
{

   public void onBeforeMarshalling( Method method, Map<String,Object>  
arguments )
   {
   }

   public void onAfterMarshalling( Method method, Map<String,Object>  
arguments )
   {
   }

}


M


On 10 Jul 2008, at 15:05, Bill Burke wrote:

> Not along at all...  Wanted to ping here first.  The injection is  
> easy.
>    Already have utilities for that.
>
> Ryan J. McDonough wrote:
>> I like it! And I see where you're going with it. I think this will
>> provide a ton of flexibility in the app. I can see a lot of
>> opportunities for this kind of feature. How far along are with it?
>>
>> Ryan-
>>
>>
>> On Jul 9, 2008, at 6:53 PM, Bill Burke wrote:
>>
>>> I'm currently prototyping some asynchronous jax-rs based on some  
>>> of the
>>> asynchronous talk in the Restful Web Services book.  At first I
>>> implemented it in a non-abstract fashion.  Just brute force as I  
>>> wanted
>>> to see what patterns came up.  After this I realized that I  
>>> needed some
>>> form of interception to implement it.  (Mainly because of security).
>>>
>>> So, for interception here's some ideas:
>>>
>>> * Interceptors will be internal and not supported.  (I want us to  
>>> write
>>> a few before we even allow users to try them out).
>>>
>>> * interception would happen based on what additional annotation you
>>> provided: @BeforeUnmarshalling, @AfterUnmarshalling,  
>>> @BeforeMarshalling,
>>> and @Aftermarshalling.
>>>
>>> * Interceptors will not be called for any subresource locator  
>>> methods.
>>>
>>> * You would be able to use any JAX-RS annotation within the  
>>> intercept
>>> method.
>>>
>>> * It is an "around" pattern (like EJB's @AroundInvoke
>>>
>>> interface RequestContext
>>> {
>>>    void invokeNext();
>>> }
>>>
>>> * You must inject and call invokeNext() on a RequestContext or no  
>>> other
>>> interceptors will be called, and the request will not be dispatched.
>>>
>>> * You will be able to inject the ResourceMethod object so you can  
>>> get
>>> preprocessed information about the method you are invoking on
>>> (annotations, etc...)
>>>
>>>
>>> So here's an example:
>>>
>>> @Provider
>>> @Interceptor
>>> public class CacheControlInterceptor
>>> {
>>>    @BeforeUnmarshalling(@Context HttpRequest request,
>>>                         @Context HttpResponse response,
>>>                         @Context RequestContext ctx)
>>>    {
>>>       if (isCached(request)) {
>>>         writeCachedResponse(request, response);
>>>         return; // don't continue with dispatching
>>>       }
>>>       return invokeNext();
>>>    }
>>>
>>>
>>>    @BeforeMarshalling
>>>    public void writeCacheControlHeaders(@Context HttpResponse  
>>> response
>>>                                         @Context RequestContext ctx)
>>>    {
>>>       ... write some cache control headers...
>>>    }
>>>
>>>    @AfterMarshalling
>>>    public void grabBytesToMarshall(@Context HttpResponse response
>>>                                    @Context RequestContext) {
>>>    }
>>> }
>>>
>>>
>>>
>>> -- 
>>> 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
>>
>
> -- 
> 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

Re: [Resteasy-developers] Interceptors

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

Not along at all...  Wanted to ping here first.  The injection is easy. 
   Already have utilities for that.

Ryan J. McDonough wrote:
> I like it! And I see where you're going with it. I think this will 
> provide a ton of flexibility in the app. I can see a lot of 
> opportunities for this kind of feature. How far along are with it?
> 
> Ryan-
> 
> 
> On Jul 9, 2008, at 6:53 PM, Bill Burke wrote:
> 
>> I'm currently prototyping some asynchronous jax-rs based on some of the
>> asynchronous talk in the Restful Web Services book.  At first I
>> implemented it in a non-abstract fashion.  Just brute force as I wanted
>> to see what patterns came up.  After this I realized that I needed some
>> form of interception to implement it.  (Mainly because of security).
>>
>> So, for interception here's some ideas:
>>
>> * Interceptors will be internal and not supported.  (I want us to write
>> a few before we even allow users to try them out).
>>
>> * interception would happen based on what additional annotation you
>> provided: @BeforeUnmarshalling, @AfterUnmarshalling, @BeforeMarshalling,
>> and @Aftermarshalling.
>>
>> * Interceptors will not be called for any subresource locator methods.
>>
>> * You would be able to use any JAX-RS annotation within the intercept
>> method.
>>
>> * It is an "around" pattern (like EJB's @AroundInvoke
>>
>> interface RequestContext
>> {
>>    void invokeNext();
>> }
>>
>> * You must inject and call invokeNext() on a RequestContext or no other
>> interceptors will be called, and the request will not be dispatched.
>>
>> * You will be able to inject the ResourceMethod object so you can get
>> preprocessed information about the method you are invoking on
>> (annotations, etc...)
>>
>>
>> So here's an example:
>>
>> @Provider
>> @Interceptor
>> public class CacheControlInterceptor
>> {
>>    @BeforeUnmarshalling(@Context HttpRequest request,
>>                         @Context HttpResponse response,
>>                         @Context RequestContext ctx)
>>    {
>>       if (isCached(request)) {
>>         writeCachedResponse(request, response);
>>         return; // don't continue with dispatching
>>       }
>>       return invokeNext();
>>    }
>>
>>
>>    @BeforeMarshalling
>>    public void writeCacheControlHeaders(@Context HttpResponse response
>>                                         @Context RequestContext ctx)
>>    {
>>       ... write some cache control headers...
>>    }
>>
>>    @AfterMarshalling
>>    public void grabBytesToMarshall(@Context HttpResponse response
>>                                    @Context RequestContext) {
>>    }
>> }
>>
>>
>>
>> -- 
>> 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
> 

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

Re: [Resteasy-developers] Interceptors

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

I like it! And I see where you're going with it. I think this will  
provide a ton of flexibility in the app. I can see a lot of  
opportunities for this kind of feature. How far along are with it?

Ryan-


On Jul 9, 2008, at 6:53 PM, Bill Burke wrote:

> I'm currently prototyping some asynchronous jax-rs based on some of  
> the
> asynchronous talk in the Restful Web Services book.  At first I
> implemented it in a non-abstract fashion.  Just brute force as I  
> wanted
> to see what patterns came up.  After this I realized that I needed  
> some
> form of interception to implement it.  (Mainly because of security).
>
> So, for interception here's some ideas:
>
> * Interceptors will be internal and not supported.  (I want us to  
> write
> a few before we even allow users to try them out).
>
> * interception would happen based on what additional annotation you
> provided: @BeforeUnmarshalling, @AfterUnmarshalling,  
> @BeforeMarshalling,
> and @Aftermarshalling.
>
> * Interceptors will not be called for any subresource locator methods.
>
> * You would be able to use any JAX-RS annotation within the intercept
> method.
>
> * It is an "around" pattern (like EJB's @AroundInvoke
>
> interface RequestContext
> {
>    void invokeNext();
> }
>
> * You must inject and call invokeNext() on a RequestContext or no  
> other
> interceptors will be called, and the request will not be dispatched.
>
> * You will be able to inject the ResourceMethod object so you can get
> preprocessed information about the method you are invoking on
> (annotations, etc...)
>
>
> So here's an example:
>
> @Provider
> @Interceptor
> public class CacheControlInterceptor
> {
>    @BeforeUnmarshalling(@Context HttpRequest request,
>                         @Context HttpResponse response,
>                         @Context RequestContext ctx)
>    {
>       if (isCached(request)) {
>         writeCachedResponse(request, response);
>         return; // don't continue with dispatching
>       }
>       return invokeNext();
>    }
>
>
>    @BeforeMarshalling
>    public void writeCacheControlHeaders(@Context HttpResponse response
>                                         @Context RequestContext ctx)
>    {
>       ... write some cache control headers...
>    }
>
>    @AfterMarshalling
>    public void grabBytesToMarshall(@Context HttpResponse response
>                                    @Context RequestContext) {
>    }
> }
>
>
>
> -- 
> 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

[Resteasy-developers] Interceptors

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

I'm currently prototyping some asynchronous jax-rs based on some of the 
asynchronous talk in the Restful Web Services book.  At first I 
implemented it in a non-abstract fashion.  Just brute force as I wanted 
to see what patterns came up.  After this I realized that I needed some 
form of interception to implement it.  (Mainly because of security).

So, for interception here's some ideas:

* Interceptors will be internal and not supported.  (I want us to write 
a few before we even allow users to try them out).

* interception would happen based on what additional annotation you 
provided: @BeforeUnmarshalling, @AfterUnmarshalling, @BeforeMarshalling, 
and @Aftermarshalling.

* Interceptors will not be called for any subresource locator methods.

* You would be able to use any JAX-RS annotation within the intercept 
method.

* It is an "around" pattern (like EJB's @AroundInvoke

interface RequestContext
{
    void invokeNext();
}

* You must inject and call invokeNext() on a RequestContext or no other 
interceptors will be called, and the request will not be dispatched.

* You will be able to inject the ResourceMethod object so you can get 
preprocessed information about the method you are invoking on 
(annotations, etc...)


So here's an example:

@Provider
@Interceptor
public class CacheControlInterceptor
{
    @BeforeUnmarshalling(@Context HttpRequest request,
                         @Context HttpResponse response,
                         @Context RequestContext ctx)
    {
       if (isCached(request)) {
         writeCachedResponse(request, response);
         return; // don't continue with dispatching
       }
       return invokeNext();
    }


    @BeforeMarshalling
    public void writeCacheControlHeaders(@Context HttpResponse response
                                         @Context RequestContext ctx)
    {
       ... write some cache control headers...
    }

    @AfterMarshalling
    public void grabBytesToMarshall(@Context HttpResponse response
                                    @Context RequestContext) {
    }
}



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

Re: [Resteasy-developers] YAML MessageBodyReader/Writer?

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

Don't worry, I'll raise my hand to something very shortly. I just want  
to get through the maven bits and I'll chew into something else. Now  
I'm off, hopefully I'll have some time next week. if no one is onto  
YAML by then I may very well look at it.

M

On 10 Jul 2008, at 00:05, Bill Burke wrote:

> I was hoping Martin, Mark, or Olivier would raise their hand.  I know
> you're busy with the JavaEE example as well as the multipart stuff.
>
> Ryan J. McDonough wrote:
>> Sorry I didn't raise my hand yet, I've been looking at 2 APIs that
>> handle YAML. But before I get to that, I want to get my example apps
>> together so I have something to test against. If you want, assign  
>> it to
>> me ;)
>>
>> Ryan-
>>
>>
>>
>> On Jul 9, 2008, at 4:04 PM, Bill Burke wrote:
>>
>>> Nobody wants to do this?
>>>
>>> I've created a JIRA task for it here:
>>>
>>> http://jira.jboss.com/jira/browse/RESTEASY-76
>>>
>>> Bill Burke wrote:
>>>> Anybody want to write one?  Pretty please?  :)
>>>>
>>>> http://www.devx.com/Java/Article/38509
>>>>
>>>>
>>>
>>> -- 
>>> 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
>>
>
> -- 
> 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

Re: [Resteasy-developers] YAML MessageBodyReader/Writer?

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

I was hoping Martin, Mark, or Olivier would raise their hand.  I know 
you're busy with the JavaEE example as well as the multipart stuff.

Ryan J. McDonough wrote:
> Sorry I didn't raise my hand yet, I've been looking at 2 APIs that 
> handle YAML. But before I get to that, I want to get my example apps 
> together so I have something to test against. If you want, assign it to 
> me ;)
> 
> Ryan-
> 
> 
> 
> On Jul 9, 2008, at 4:04 PM, Bill Burke wrote:
> 
>> Nobody wants to do this?
>>
>> I've created a JIRA task for it here:
>>
>> http://jira.jboss.com/jira/browse/RESTEASY-76
>>
>> Bill Burke wrote:
>>> Anybody want to write one?  Pretty please?  :)
>>>
>>> http://www.devx.com/Java/Article/38509
>>>
>>>
>>
>> -- 
>> 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
> 

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

Re: [Resteasy-developers] YAML MessageBodyReader/Writer?

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

Sorry I didn't raise my hand yet, I've been looking at 2 APIs that  
handle YAML. But before I get to that, I want to get my example apps  
together so I have something to test against. If you want, assign it  
to me ;)

Ryan-



On Jul 9, 2008, at 4:04 PM, Bill Burke wrote:

> Nobody wants to do this?
>
> I've created a JIRA task for it here:
>
> http://jira.jboss.com/jira/browse/RESTEASY-76
>
> Bill Burke wrote:
>> Anybody want to write one?  Pretty please?  :)
>>
>> http://www.devx.com/Java/Article/38509
>>
>>
>
> -- 
> 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

Re: [Resteasy-developers] YAML MessageBodyReader/Writer?

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

Nobody wants to do this?

I've created a JIRA task for it here:

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

Bill Burke wrote:
> Anybody want to write one?  Pretty please?  :)
> 
> http://www.devx.com/Java/Article/38509
> 
> 

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

Re: [Resteasy-developers] Reiner

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

not an eclipse user myself... maybe ryan can help u?

Reiner Rodriguez Alvarez wrote:
> Hi
> 
> I am new  on resteasy …
> 
> I like to find some good  tutorial using resteasy in Eclipse …any help 
> please.
> 
>  
> 
> Thanks
> 
>  
> 
> rro...@mt...
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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] Reiner

[Reiner R. A. <rro...@mt...>]

Hi

I am new  on resteasy ...

I like to find some good  tutorial using resteasy in Eclipse ...any help
please. 

 

Thanks 

 

rro...@mt...

 

 

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

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

On 9 Jul 2008, at 00:35, Bill Burke wrote:

> 2) I believe, after looking at those broken tests, that I ported the  
> test from Jersey's testsuite.  This means that we might have to  
> change the behavior back to the way it was.  We'll see what happens  
> with the TCK.


I've reverted back so that we're once again getting 400 when we  
encounter bad numbers. This means I've changed the test suites back as  
well.

So currently Ryan does not get a 404 for the resource method taking an  
integer.

M

Re: [Resteasy-developers] request: can we publish source artifacts to the maven repo

[Adam J. <Ada...@ge...>]

As of beta5, I¹m running against the released artifacts.

>From the subsequent follow-ups to this post, it sounds like the next beta
release will have released sources, so I¹m happy.


Thanks,
Adam

On 09/07/08 12:11 AM, "Martin Algesten" <sp...@ma...> wrote:

> 
> Hi Adam,
> 
> Are you running against "released" beta versions or building your own jar from
> the source tree? I'm about to sort out releases using the maven-release-plugin
> which means the source code would be bundled anyway - doesn't help if you're
> compiling your own though.
> 
> M
> 
> On 9 Jul 2008, at 03:04, Adam Jordens wrote:
> 
>>  Essentially I¹m asking if we can add the maven-source-plugin to the
>> resteasy-jaxrs-all parent artifact POM.
>>  
>>  Something similar to the following would probably suffice:
>>  
>>  <plugin>
>>    <groupId>org.apache.maven.plugins</groupId>
>>    <artifactId>maven-source-plugin</artifactId>
>>    <version>2.0.2</version>
>>    <executions>
>>      <execution>
>>        <goals>
>>          <goal>jar</goal>
>>        </goals>
>>      </execution>
>>    </executions>
>>  </plugin>
>>  
>>  It¹s always nice to be able to debug with source code in your IDE (IntelliJ
>> in my case) and this helps automate that.
>>  
>>  
>>  Cheers,
>>  Adam 
>>   -------------------------------------------------------------------------
>> 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
> 
> 

Re: [Resteasy-developers] grizzly?

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

you need to pull in grizzlly it is for embedded only

Martin Algesten wrote:
> I'm a Grizzly nuub... when you run in Grizzly do you get our grizzly  
> dependencies provided by the servlet container or do you need to  
> include them in your war?
> 
> 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