Hello Paul,
I have not have chance to learn request/response chain in Jersey so it is hard for me to advise on exception handling. One thing is clear that there must be some filter chain which is guaranteed to complete no matter what. I think it would be the best not to use request/response chain at all for resource handling because it might not allign well with your exception logic (forcing response to accommodate resource management might be contrary to other needs)
I think the best is to use Resource lifecycke for it! And anyway 1.0.2 InjectorProvider (or something forgot class name) does not pass HttpContext to method instantiating injected resource so I am not sure how to do what Fabio suggests in case of injection anyway
My current workaround is @PostConstruct and @PreDestroy. Instead of injection, I create a superclass - JDOResource with @PostConstruct and @PreDestroy to create/clean up my JDO PersistenceManagers. I hope very much that @PreDestroy is guaranteed no matter what exceptions are thrown along the way. Is it?
But I would like very much to be able to mark an injected resource as say @Closeable("method name default to close() of Closeable interface") to have it automatically closed on destroy!
Another tricki issue I see is returning OutputStream as result from resource. If you use any live data (ORM with lazy loading, database result set ....) to write to output stream you cannot use inside your resource method
Connection conn = ...
try {
//write to OutputStream
} finally {
con.close()
}
because of control inversion writing is happening outside of resource method so @PreDestroy is absolutely essential for such an important use case as the only guarantee that after writing to output is done, conn is closed. If I could inject connection as a closeable resource all this would be very clean and transparent. And could extend to case of injecting a closeable into method rather than instance which @PreDestroy does not cover (we would need to introduce @PreInvoke and @PostInvoke though)
Bottom line - I believe java resource management or some strong lifecycle which would allow resource management is very much needed or people will have to do all this hacks to do it on request/response lifecycle
Thank you,
Alex
-----Original Message-----
From: Paul Sandoz [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Tuesday, February 10, 2009 4:51 AM
To: users_at_jersey.dev.java.net
Cc: Roytman, Alex
Subject: Re: [Jersey] Re: Filters
Hi Fabio,
CC'ing Alex as this is related to the discussion we have been having
of the "Destroying injected context at the end of resource lifecycle"
thread.
On Feb 7, 2009, at 3:50 PM, Fabio Mancinelli wrote:
> On Fri, Feb 6, 2009 at 6:47 PM, Fabio Mancinelli
> <fabio.mancinelli_at_gmail.com> wrote:
>> Dear all,
>>
>> I am stuck with the following problem: I would like to implement a
>> "setup/cleanup" filter that, before calling any resource, must do the
>> following
>>
>> 1) Perform some initializations
>> 2) Make some environment objects available to the resource that will
>> be called after.
>> 3) Cleanup after the request has been served (no matter what, even if
>> exceptions are thrown, a bit like a finally)
>>
> I think I've found a solution to the problem, so I am sharing it
> with you.
>
> Basically I create a class that implements the ContainerRequestFilter
> and ContainerResponseFilter and setup this filter in the web.xml
>
> In the filter(ContainerRequest request) method I use the
> request.getProperties() map in order to store my environment objects.
>
> A resource willing to retrieve those object must declare a @Context
> HttpContext variable.
>
> The injected value contains a map that can be retrieved using the
> getProperties() method.
> This map will contain all the objects that I've stored in the filter
> method.
>
> That's it.
>
Yes, that is it. A technique we sometimes employ to avoid the user
having to inject HttpContext and then extract the property and cast is
to use an injectable provider to do that job. It makes the resource
class a little cleaner. Plus potentially the use of the injectable
provider means that one does not have to know upfront the environment
objects that may be utilized.
There is currently one issue i mentioned to Alex:
Currently any exception thrown by a response filter will terminate
the response filter chain. But i am wondering this is the
right thing to do and instead each filter should be wrapped around
exception checking. I would appreciate any advice on
this aspect.
Paul.