On Feb 10, 2009, at 6:38 PM, Roytman, Alex wrote:
> 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 there lies the problem because Jersey is not a general IoC
framework. It only supports life-cycle management for resource and
provider classes. And i think we are using the term "resource"
differently. By resource i mean Web resource and not a general thing
that is required to be managed.
> 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
>
Add the following as a field or constructor parameter of your
injectable provider class:
@Context HttpContext hc;
An InjectableProvider, or any provider, is managed under the
singleton scope.
> 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.
OK.
> I hope very much that @PreDestroy is guaranteed no matter what
> exceptions are thrown along the way. Is it?
>
Yes. The logic is performed in a finally block.
> 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
>
Agreed, but to do this you need to use an IoC framework like Guice or
Spring in conjunction with Jersey.
Paul.