RESTEasy

> Probably the best solution would be to implement ExceptionMapper  
> handling in Resteasy as some kind of filter I could enable/disable/ 
> extend.

Some pseudo code to illustrate this, current situation:

// Wrap in RESTEasy contexts
try {
   ResteasyProviderFactory.pushContext(HttpServletRequest.class,  
request);
   ...
   // Wrap in Seam contexts
   new ContextualHttpServletRequest(request) {
      UriInfoImpl uriInfo = // Do stuff
      dispatcher.getDispatcher().invoke(in, theResponse);
   }

} finally {
   ResteasyProviderFactory.clearContextData();
}

Ideally I would get access to the ExceptionMapper invocation like  
this, the exception needs to bubble out of dispatcher.invoke():

// Wrap in RESTEasy contexts
try {
   ResteasyProviderFactory.pushContext(HttpServletRequest.class,  
request);
   ...
   // Wrap in Seam contexts
   new ContextualHttpServletRequest(request) {
      UriInfoImpl uriInfo = // Do stuff
      dispatcher.getDispatcher().invoke(in, theResponse);
   }
} catch (Exception ex) {
   return exceptionMapper.getResponse(ex);
} finally {
   ResteasyProviderFactory.clearContextData();
}

Anything else is going to be significantly more effort to integrate  
into the Seam filter/call stack.

Christian,

I'll take a look at these once I wrap up the JAXB/JSON changes which I  
hope to complete this week.

Ryan-

On Aug 15, 2008, at 1:42 AM, Christian Bauer wrote:

>
>> Probably the best solution would be to implement ExceptionMapper
>> handling in Resteasy as some kind of filter I could enable/disable/
>> extend.
>
> Some pseudo code to illustrate this, current situation:
>
> // Wrap in RESTEasy contexts
> try {
>  ResteasyProviderFactory.pushContext(HttpServletRequest.class,
> request);
>  ...
>  // Wrap in Seam contexts
>  new ContextualHttpServletRequest(request) {
>     UriInfoImpl uriInfo = // Do stuff
>     dispatcher.getDispatcher().invoke(in, theResponse);
>  }
>
> } finally {
>  ResteasyProviderFactory.clearContextData();
> }
>
> Ideally I would get access to the ExceptionMapper invocation like
> this, the exception needs to bubble out of dispatcher.invoke():
>
> // Wrap in RESTEasy contexts
> try {
>  ResteasyProviderFactory.pushContext(HttpServletRequest.class,
> request);
>  ...
>  // Wrap in Seam contexts
>  new ContextualHttpServletRequest(request) {
>     UriInfoImpl uriInfo = // Do stuff
>     dispatcher.getDispatcher().invoke(in, theResponse);
>  }
> } catch (Exception ex) {
>  return exceptionMapper.getResponse(ex);
> } finally {
>  ResteasyProviderFactory.clearContextData();
> }
>
> Anything else is going to be significantly more effort to integrate
> into the Seam filter/call stack.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Resteasy-developers@...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Christian,

I'll take a look at these once I wrap up the JAXB/JSON changes which I  
hope to complete this week.

Ryan-

On Aug 15, 2008, at 1:42 AM, Christian Bauer wrote:

>
>> Probably the best solution would be to implement ExceptionMapper
>> handling in Resteasy as some kind of filter I could enable/disable/
>> extend.
>
> Some pseudo code to illustrate this, current situation:
>
> // Wrap in RESTEasy contexts
> try {
> ResteasyProviderFactory.pushContext(HttpServletRequest.class,
> request);
> ...
> // Wrap in Seam contexts
> new ContextualHttpServletRequest(request) {
>    UriInfoImpl uriInfo = // Do stuff
>    dispatcher.getDispatcher().invoke(in, theResponse);
> }
>
> } finally {
> ResteasyProviderFactory.clearContextData();
> }
>
> Ideally I would get access to the ExceptionMapper invocation like
> this, the exception needs to bubble out of dispatcher.invoke():
>
> // Wrap in RESTEasy contexts
> try {
> ResteasyProviderFactory.pushContext(HttpServletRequest.class,
> request);
> ...
> // Wrap in Seam contexts
> new ContextualHttpServletRequest(request) {
>    UriInfoImpl uriInfo = // Do stuff
>    dispatcher.getDispatcher().invoke(in, theResponse);
> }
> } catch (Exception ex) {
> return exceptionMapper.getResponse(ex);
> } finally {
> ResteasyProviderFactory.clearContextData();
> }
>
> Anything else is going to be significantly more effort to integrate
> into the Seam filter/call stack.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Resteasy-developers@...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

What I think I'm going to do is let exceptions perculate up to the 
dispatcher and write a method to handle all exceptions.  Seam can then 
just override the method that does exception handling at the dispatcher 
level.

Also, I'll have 4 types of exceptions each defined as a separate 
exception class:

* PreprocessingFailure - target resource method wasn't invoked (but 
Sublocators may have been invoked).
* PostprocessingFailure - failed on marshalling response
* UserException - just like InvocationTargetException, a user exception 
was thrown.

I also will pull Response writing into dispatcher as well as both 
resources, providers, and ExceptionMappers can throw 
WebApplicationException which has its own Response.

Ryan J.McDonough wrote:
> Christian,
> 
> I'll take a look at these once I wrap up the JAXB/JSON changes which I  
> hope to complete this week.
> 
> Ryan-
> 
> On Aug 15, 2008, at 1:42 AM, Christian Bauer wrote:
> 
>>> Probably the best solution would be to implement ExceptionMapper
>>> handling in Resteasy as some kind of filter I could enable/disable/
>>> extend.
>> Some pseudo code to illustrate this, current situation:
>>
>> // Wrap in RESTEasy contexts
>> try {
>> ResteasyProviderFactory.pushContext(HttpServletRequest.class,
>> request);
>> ...
>> // Wrap in Seam contexts
>> new ContextualHttpServletRequest(request) {
>>    UriInfoImpl uriInfo = // Do stuff
>>    dispatcher.getDispatcher().invoke(in, theResponse);
>> }
>>
>> } finally {
>> ResteasyProviderFactory.clearContextData();
>> }
>>
>> Ideally I would get access to the ExceptionMapper invocation like
>> this, the exception needs to bubble out of dispatcher.invoke():
>>
>> // Wrap in RESTEasy contexts
>> try {
>> ResteasyProviderFactory.pushContext(HttpServletRequest.class,
>> request);
>> ...
>> // Wrap in Seam contexts
>> new ContextualHttpServletRequest(request) {
>>    UriInfoImpl uriInfo = // Do stuff
>>    dispatcher.getDispatcher().invoke(in, theResponse);
>> }
>> } catch (Exception ex) {
>> return exceptionMapper.getResponse(ex);
>> } finally {
>> ResteasyProviderFactory.clearContextData();
>> }
>>
>> Anything else is going to be significantly more effort to integrate
>> into the Seam filter/call stack.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Resteasy-developers mailing list
>> Resteasy-developers@...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Resteasy-developers@...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

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

On Aug 20, 2008, at 02:23 , Bill Burke wrote:

> What I think I'm going to do is let exceptions perculate up to the  
> dispatcher and write a method to handle all exceptions.  Seam can  
> then just override the method that does exception handling at the  
> dispatcher level.

That's the same then as writing an ExceptionMapper right now, for Seam  
integration. That's why I wrote that I need it to bubble OUT of the  
dispatcher.

> Also, I'll have 4 types of exceptions each defined as a separate  
> exception class:
>
> * PreprocessingFailure - target resource method wasn't invoked (but  
> Sublocators may have been invoked).
> * PostprocessingFailure - failed on marshalling response
> * UserException - just like InvocationTargetException, a user  
> exception was thrown.

If you need this internally, at least don't bother your users with it.  
For users they are all the same. This kind of wrapping is what makes  
people hat the JSF RI.

> I also will pull Response writing into dispatcher as well as both  
> resources, providers, and ExceptionMappers can throw  
> WebApplicationException which has its own Response.

Out of dispatcher please.

Christian Bauer wrote:
> On Aug 20, 2008, at 02:23 , Bill Burke wrote:
> 
>> What I think I'm going to do is let exceptions perculate up to the  
>> dispatcher and write a method to handle all exceptions.  Seam can  
>> then just override the method that does exception handling at the  
>> dispatcher level.
> 
> That's the same then as writing an ExceptionMapper right now, for Seam  
> integration. That's why I wrote that I need it to bubble OUT of the  
> dispatcher.
> 

Its not the same because I need certain contextual data set (and 
eventually cleaned) for MessageBodyWriters to work.  Also, 
WebApplicationException throws a wrench in things as well as it contains 
a Response that could be marshalled by MessageBodyWriters.  Finally, 
MessageBodyWriters themselves can throw WebApplicationException.  As 
long as the request isn't committed, I have to try and write out that 
response.

All the above logic is not encapsulatable very well within an SPI. 
Which is why I want dispatcher to be self-contained and not have 
anything "bubble OUT".

>> I also will pull Response writing into dispatcher as well as both  
>> resources, providers, and ExceptionMappers can throw  
>> WebApplicationException which has its own Response.
> 
> Out of dispatcher please.
> 

See above.

There is a non-trivial amount of logic for response handling.  So, if 
you don't like dispatcher the way it turns out, feel free to write your 
own dispatcher.  I have my own requirements and schedule to deal with.

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