On Feb 6, 2009, at 6:18 PM, Roytman, Alex wrote:
> 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!
>
Agreed, this is a job for a fully functional IoC container.
> 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?
You can inject
@Context HttpContext hc;
A thread local proxy will be injected.
>
> Also Not sure if using ContainerResponseFilter will guarantee PM de-
> allocation unless Jersey guarantees its invocation regardless of any
> exceptions within Resource invocation.
Any exception thrown by a request filter or a resource that can be
mapped to a response will be processed by the response filter chain.
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.
> 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?
You can as long as no response filter is invoked before your response
filter that throws an exception.
What you can do is in your injectable provider add injected PM
instances to a property of the HttpContext.
Then the response filter can get the same property from the
ContainerRequest.
An alternative is to support this as a servlet attribute. You can
inject:
@Context HttpServletRequest r;
Then you can override the ServletContainer.service method to defer to
the super class wrapped around a try/finally block. Or use a servlet
filter.
Note that if you want to inject on Jersey-managed per-request and
singleton resources then you need to provide per-request and singleton
injectables. In the case of the latter a thread local proxy would be
required.
>
> 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?
Not yet, it will be in the 1.0.3-SNAPSHOT by the end of this week or
the start of next week.
> And anyway even with it how it will help tying Guice injected things
> with Jersey lifecycle.
When Guice is used the life-cycle of resource classes will be fully
managed by Guice. It is still possible to use the Jersey injection
mechanisms correctly as Jersey knows the scope of the things it will
inject on to.
Paul.
>
> 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
>