Ryan Lubke's Blog

« JSF 1.2_03 now avail... | Main | Jetty6, JSF 1.2 and... »

JSF RI 1.2 and Resource Injection

Monday Jan 08, 2007

In the first release of JSF 1.2 up to the latest version, 1.2_03, we've only supported Resource Injection in GlassFish. I'm happy to say that in the next nightly, we'll have improved this support.

How it used to work: The JSF implementation uses a delegation model in order to provide resource injection to managed beans. This was done by providing an implementation of the InjectionProvider interface. Container vendors could then configure this provider via a context initialization parameter in their web.xml, or via a system property. If no provider was configured, then we'd default to a no-op InjectionProvider and no resource injection would be performed.

This was fine for the interim, but not that Jetty and Tomcat are up to speed to the new specifications (or at least getting close to being compliant), having a configuration step to enable resource injection within the JSF-RI seemed a bit too much.

How it now works: Explicit configuration of InjectionProviders is, of course, still supported, however, if there is no explicit configuration, then the implementation will query for a META-INF/services entry com.sun.faces.spi.injectionprovider. This service entry file may contain one or more entries using the following format:

      <InjectionProvider Implementation>:<Injection Delegate>

So an example for GlassFish would be:

      com.sun.faces.vendor.GlassFishInjectionProvider:com.sun.enterprise.InjectionManager

InjectionProviders configured this way must extend the DiscoverableInjectionProvider abstract class. This class adds a static method isInjectionFeatureAvailable(String delegate) which will be called by the factory passing in the delegate as configured in the service entry. If this method returns true, then we put the InjectionProvider into service.

So, for those of you kicking the tires of Tomcat 6.0.2 beta, if you drop in the jsf implementation nightly, resource injection will now work without any configuration steps. I'll be adding an InjectionProvider for Jetty in the coming days.

So what about folks on Tomcat 5.x using Facelets? Well, we do support a certain degree of resource injection in that environment as well. If your application includes the annotation-api.jar (JSR 250), the nightly will support handling methods marked with the @PostConstruct and @PreDestroy annotations.

Please give the nightlies a shot and [7] Comments

Like this post?

Posted at 04:41PM Jan 08, 2007 by rlubke in Sun
Tags:

Comments:

Hi Ryan, I am trying to use the EL functions capability and trying to define a function using the varargs feature. i.e. public static String format(String a, Object... args) { } However the EL resolver does not seem to support this as when I try to pass more than 2 arguments to the method I get an error.. Any idea when EL will support varargs method arguments?

Posted by Girish on February 07, 2007 at 05:14 PM PST #

Hi Ryan, Can you please elaborate on "having a configuration step to enable resource injection within the JSF-RI seemed a bit too much"? If I understand you correctly, the RI delagates all resource injection, @PostConstruct and @PreDestroy to the servlet container? Me and a few others on the MyFaces list are debating how this should be done. If both Apache and Sun end up delegating everything to the container, why are @PostConstruct and @PreDestroy in the JSF spec? Any help here would be appreciated. Does the JSF RI still trigger @PreDestroy from [Scope]AttributeListener.attributeRe[moved,placed]? If so, what can we do about changing the wording in the spec? The spec specifically says this is to happen *before* the bean is removed from scope.

Posted by Dennis Byrne on March 03, 2007 at 10:39 AM PST #

The configuration step I spoke of was explicitly configuring the InjectionProvider in a the web.xml (in the case of say, GlassFish, Tomcat, JBoss, etc - this would be the default-web.xml that gets applied to all web applications). As to the timing of the @PreDestory, I agree, the spec should be a little more accomodating. The RI uses both attribute and scope listeners. In the case where, say a request goes out of scope, we keep to the spec working. That listener is only called before the request is about to expire. But what about the case where a user explicitly removes or replaces a scoped attribute associated with a managed bean? They may or may not be using the ExternalContext to handle to removal/replacement, so it seemed, wording aside, that the attribute listeners were the best way to handle this. Lastly, the RI may not necessarily delegate everything to the container. We try to degrade gracefully. We use any suitable InjectionProvider we can find. If one can't be found, but the callback annotation classes are present, then we'll use an InjectionProvider that supports the callback annotations only (no delegation to the container at all). If the annotations aren't present, then we perform no actions at all.

Posted by Ryan Lubke on March 03, 2007 at 11:18 AM PST #

Thanks, that makes it more clear.

Today I am wearing the implementation hat, not designer hat. But personally I wouldn't make @PreDestroy the responsibility of j2ee when an app developer chooses to remove the bean from scope programmatically. Does the container rollback a user transaction? Oh well.

Posted by Dennis Byrne on March 03, 2007 at 01:53 PM PST #

Hi Ryan, the InjectionProvider interface looks very similar to Tomcat's AnnotationProcessor interface. Is that a coincidence or was this similarity intended to make Tomcat integration more straight forward? In either case it seems like a standardized interface somewhere under javax. would be quite useful.

Posted by Paul McMahan on March 27, 2007 at 11:57 AM PDT #

This is a test.

Posted by A on March 27, 2007 at 12:34 PM PDT #

Hi. Ryan We are using JSF 1.2 in Eclipse WTP 1.5. I had Installed : - jsf-api.jar - jsf-impl.jar - Cardemo Application. I have problems compiling the class "FormatValidatorTag". the reported error is : " the type javax.servlet.jsp.JspException can not be resolved. it is indirectly referenced from require .class file" best regards