Menu
▾
▴
resteasy-developers
|
From: Bill B. <bb...@re...> - 2008-07-09 22:51:34
|
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
|
|
From: Solomon D. <sd...@gm...> - 2009-01-13 22:52:58
|
What's going on with the interceptor work? Is the work getting into the 1.1 branch? -Solomon |
|
From: Bill B. <bb...@re...> - 2009-01-14 14:03:16
|
I'm going to start working on it after 1.0 GA next tuesday. Solomon Duskis wrote: > What's going on with the interceptor work? Is the work getting into the > 1.1 branch? > > -Solomon > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan M. <ry...@da...> - 2009-01-14 23:21:30
|
Sorry guys, I've been under the weather the past several days but what I've come up with so far: I started out working with the interceptor framework that Bill had in there already and tried to use the GZip encoding as a starting point. However, with the existing mechanism is limited in the following ways: - There isn't a clean interception point that would happen before or after the MessageBodyReader. It could be done, but seems that it'd be a tad crufty. With that said, it'd be difficult to handle a @BeforeReader and @AfterReader pointcut. - The response side of things gets a bit tricky: yes, you can certainly re-create a customized response, but you don't have access the OutputStream. - Additionally, there's no way to implement @AfterWriter or @BeforeWriter pointcut. The serialization handling is outside the scope of the ResourceMethodInterceptor. - Unit testing interceptors using the existing framework will require some rework of the TWJS server. - It would also be handy to have TWJS implement annotation scanning as well. I'd like to be able to unit test the scanning portion in unit test as well just to make sure it works. Right now, we're pretty deficient in this area. In a nut shell, we may want to look at refactoring some of the Resource invocation process in order to accomodate the needs of an interceptor framework. Thoughts? Ryan- On Wed, Jan 14, 2009 at 9:03 AM, Bill Burke <bb...@re...> wrote: > I'm going to start working on it after 1.0 GA next tuesday. > > > > Solomon Duskis wrote: > > What's going on with the interceptor work? Is the work getting into the > > 1.1 branch? > > > > -Solomon > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers > -- Ryan J. McDonough http://www.damnhandy.com |
|
From: Bill B. <bb...@re...> - 2009-01-14 23:18:11
|
Ryan McDonough wrote: > In a nut shell, we may want to look at refactoring some of the Resource > invocation process in order to accomodate the needs of an interceptor > framework. Thoughts? > Yes, this needs to be done in conjunction with Spring/Seam integration refactoring/needs as they both need the same abstractions. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2009-01-14 23:27:15
|
We'll probably need to iterate a few times to get this right. Bill Burke wrote: > > Ryan McDonough wrote: >> In a nut shell, we may want to look at refactoring some of the Resource >> invocation process in order to accomodate the needs of an interceptor >> framework. Thoughts? >> > > Yes, this needs to be done in conjunction with Spring/Seam integration > refactoring/needs as they both need the same abstractions. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2009-01-20 13:25:05
|
Bill, I'm going to start taking a stab at this today. Since this is likely to create some breakage, should I make any commits to the 1.1 branch? Ryan- On Jan 14, 2009, at 6:27 PM, Bill Burke wrote: > We'll probably need to iterate a few times to get this right. > > Bill Burke wrote: >> >> Ryan McDonough wrote: >>> In a nut shell, we may want to look at refactoring some of the >>> Resource >>> invocation process in order to accomodate the needs of an >>> interceptor >>> framework. Thoughts? >>> >> >> Yes, this needs to be done in conjunction with Spring/Seam >> integration >> refactoring/needs as they both need the same abstractions. >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2009-01-20 14:17:42
|
Ryan J. McDonough wrote: > Bill, > > I'm going to start taking a stab at this today. Since this is likely to > create some breakage, should I make any commits to the 1.1 branch? > Create your own branch... Do you remember the golden rule? Trunk should be stable and never break. Same rule applies to a major branch. Let me know how far you get. I will need to dive into this as I believe it will help with Spring/Seam refactoring/integration. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2008-07-10 12:30:52
|
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
|
|
From: Bill B. <bb...@re...> - 2008-07-10 14:03:44
|
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
|
|
From: Martin A. <sp...@ma...> - 2008-07-10 15:36:58
|
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
|
|
From: Bill B. <bb...@re...> - 2008-07-11 16:30:50
|
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
|
|
From: Martin A. <sp...@ma...> - 2008-07-11 17:23:57
|
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
|
Thanks for helping keep SourceForge clean.
X