dev@glassfish.java.net

Re: Resource Injection and Lifecycles

From: Bill Shannon <bill.shannon_at_Sun.COM>
Date: Thu, 25 Aug 2005 14:05:42 -0700

Jacob Hookom wrote:
> I was looking at @Resource in relation to lifecycles represented in the
> web tier. Outside of the EJB spec, there's opportunity to cause
> conflicts between gained resources and the lifecycles of application or
> session scoped beans. On top of that, gained resources aren't often
> Serializable, so assigning them to clusterable instances may cause
> issues for developers.

I'm not sure what conflict you're referring to.

Yes, injecting resources that aren't serializable will have the same
issues as looking up and saving resources that aren't serializable.

> The code within InjectionManagerImpl does a fine job of injecting
> resources, but they are set as literal instances on the member
> variables. This leaves you with shared DataSources or JMS entities that
> would live beyond their expected lifespans with traditional
> InitialContext use.
>
> Really, what is the purpose of @Resource? To shortcut the lookup against
> the InitialContext-- not to retain references to stateless resources.
> To me, there seems to be a impendance mismatch under the current
> implementation.
>
> Would it be suitable to instead assign serializable, proxy references to
> Fields/Methods such that any time they are accessed, they go back to the
> InitialContext?
>
> public class ResourceInvocationHandler implements InvocationHandler,
> Serializable {
>
> private final String envName;
>
> public ResourceInvocationHandler(String envName) {
> this.envName = envName;
> }
>
> public Object invoke(Object proxy, Method method, Object[] args) throws
> Throwable {
> InitialContext namingCtx = new InitialContext();
> Object base = namingCtx.lookup(envName);
> return method.invoke(base, args);
> }
> }
>
> Granted there would need to be better exception handling, but this
> basically outlines support for traditional, stateless resources,
> independent of the client beans' lifecycle.

I'm not sure what problem this is solving.

Retaining a reference to a DataSource (for example) shouldn't be a problem,
as long as the component gets and releases a Connection appropriately.