Hello Paul,
Thank you very much for your suggestion. I do not believe @PreDestroy is a good option - if a java resource is allocated by framework implicitly, clean up must be done by the framework as well and be guaranteed (think leaking database connections). It would be nice to be able to subscribe injected PM to PreDestroy mechanizm automatically though!
Yes, I am mostly interested in per request scenario and as of yesterday I switched to 1.0.2-SNAPSHOT builds as they seem to add few nice features (Resource filters and role based security ...). We just started the project and deployment is 6 months away so I think we can adopt 1.0.2 branch use any upcoming APIs
The second approach is what I was trying to implement but InjectableProvider does not give me access to request context so I can subscribe my PM for future cleanup. Should I use some other way to provide injection? Could you please elaborate on your suggestion a bit?
Also Not sure if using ContainerResponseFilter will guarantee PM de-allocation unless Jersey guarantees its invocation regardless of any exceptions within Resource invocation. Thought maybe there is a way to utilize Resource lifecycle events rather than request level events for tighter control. As a last resort approach I thought of using ServletFilters to do cleanup as long as I can subscribe injected PMs to HttpRequest itself. Servlet filter semantics let's me wrap filter call chain in try/finally so I know PMs will be closed but can I rely on ContainerResponseFilter to be invoked no matter what?
In general I think it would be nice to provide a clear way to cleanup injected java resources (database or any other connections, persistent managers basically anything Closeable ....) in accord with Resource lifecycle, it would be very convenient and useful. In other words, if we can acknowledge that injected java resources must be able to participate in Resource lifecycle so they can be cleaned up properly and provide a standard simple mechanizm for it, I think it would be very useful!
Is Guice support in 1.0.2-SNAPSHOT now? And anyway even with it how it will help tying Guice injected things with Jersey lifecycle.
Thanks again,
Alex
From: Paul Sandoz [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Friday, February 06, 2009 3:38 AM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] Destroying injected context at the end of resource lifecycle
Hi Alex,
If you are using Jersey 1.0.1 you can annotate a method with @PreDestroy on a resource class and when the resource goes out of scope that method will get called.
If you do not want to use @PreDestroy on a resource classes an alternative is to add ContainerResponseFilter to do the clean up of any persistent managers that have been injected and utilized. The injection provider could add the injected persistence manager instances to a List that is a property on the HttpContext.
In the above I presuming that the injection of PersistenceManager instances are pre-request. Is that correct? If not then it will be necessary to override the ServletContainer and the destroy method to clean up singleton-based instances.
Note that Jersey is not a generic framework for life-cycle and injection. If you need that then I recommend using Spring (Guice support will be available in the next release).
Paul.
On Feb 6, 2009, at 12:39 AM, Roytman, Alex wrote:
Hello,
I am very new to Jersey, so forgive me if my question is silly.
I would like to annotate some resources with a custom annotation to inject JDO PersistenceManager but I must have some way to close it at the end of resource lifecycle. I was browsing source code but could not find any way to accomplish it.
Could you point me in right direction?
Thank you,
Alex