Menu
▾
▴
resteasy-developers
|
From: Christian B. <chr...@gm...> - 2008-08-14 12:51:26
|
I'm trying to integrate exception handling with Seam, a few issues: Resteasy doesn't implement the JAX RS exception handling nearest-type search: https://jira.jboss.org/jira/browse/RESTEASY-69 - so I can't write a generic ExceptionMapper<Exception> and delegate all of that to Seam. The second issue is that Resteasy swallows exceptions (and worse, it writes ugly logs): https://jira.jboss.org/jira/browse/RESTEASY-105 Seam has an ExceptionFilter, we need it to destroy contexts, end transactions, and so on. That filter will not run if dispatcher.invoke() does not throw an exception. I'm not sure how to best solve both issues. It's hard to implement a cleanup routine in Seam as a generic ExceptionMapper<Exception>, so I'd really like the regular ExceptionFilter to run. But that means that ExceptionMapper invocation has to occur outside of dispatcher.invoke(). Probably the best solution would be to implement ExceptionMapper handling in Resteasy as some kind of filter I could enable/disable/ extend. |
|
From: Christian B. <chr...@gm...> - 2008-08-15 05:43:02
|
> 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.
|
|
From: Ryan J. M. <ry...@da...> - 2008-08-19 13:07:38
|
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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|
|
From: Ryan J. M. <ry...@da...> - 2008-08-19 13:09:18
|
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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
|
|
From: Bill B. <bb...@re...> - 2008-08-20 00:23:29
|
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
>> Res...@li...
>> 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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Christian B. <chr...@gm...> - 2008-08-20 05:35:04
|
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. |
|
From: Bill B. <bb...@re...> - 2008-08-21 00:28:39
|
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 |
Thanks for helping keep SourceForge clean.
X