|
Hey All, Thought I would throw this out to see if anyone would care to comment on some ideas/work I've done on the InjectionProvide system in the RI. Currenly, vendors can implement the InjectionProvider interface and explicitly configure it via a context initialization parameter or system property. The above system is fine, however, it's somewhat limiting if I want to add InjectionProvider implementations for Tomcat6 and Jetty6. We'd have to document how to configure the provider for their container. Ideally, it would just work without any steps by the developer. To that end, I have the following coded up in my local workspace: Added a new Abstract class called DiscoverableInjectionProvider that implements InjectionProvider and provides a static method: /** * @param delegateClass the name of the delegate used by the * <code>InjectionProvider</code> implementation. * @return returns <code>true</code> if the * <code>InjectionProvider</code> instance * is appropriate for the container its currently * deployed within, otherwise return <code>false</code> */ public static boolean isProviderAppropriate(String delegateClass) This method would be called by the InjectionProviderFactory (see below) to determine if this particular InjectionProvider could be used. More on the 'delegateClass' argument later. Modifications to InjectionProviderFactory: * The factory algorithm will check the following, in order, to provide the appropriate provider - If explicitly configured, return that InjectionProvider - If no explicit configuration, check META-INF/services/com.sun.faces.spi.injectionprovider. The format of the entries within the 'com.sun.faces.spi.injectionprovider file is: <InjectionProviderImplementation>:<DelegateClass> So an example for GlassFish would be: com.sun.faces.vendor.GlassFishInjectionProvider:com.sun.enterprise.InjectionManager When processing, the factory will split the two, and pass the <DelegateClass> portion to DiscoverableInjectionProvider.isProviderAppropriate(String). If it returns true, then we return this InjectionProvider. NOTE: Any InjectionProvider declared in the services file must extends DiscoverableInjectionProvider. The appropriate messages would be logged if this was not the case - If no provider is found in the services configuration, check to see if the PostConstruct and PreDestroy annotations are present, if so, provide support for those two annotations *only*. - If no provider has been found at this point, no resource injection will be provided. I've tested the above locally, and so far, it all seems to work. The other part to this issue, is how to handle the build if we provide these InjectionProvider implementations for other containers. These providers will obviously be dependent on container specific classes, so I see a two options: 1. Have a separate set of targets to build a jsf-ri-iprovider.jar that is checked into the workspace. When the RI itself is built, then the classes contained in the jsf-ri-provider.jar would be included. 2. Update the dependencies.xml to download tomcat6, glassfish, and jetty so that the classes are always built. Number one so far seems like the best choice. There are issues with choice 2 and the glassfish installation with regards to automation as there is a graphical popup to accept the CDDL licence. Number 2 means a little more overhead in ensuring that that particular part of the build doesn't break - so it would have to be a manual step done once a week or so to ensure it's valid. The other question I had - do we want to include the provider implementations within the RI jar itself, or have it as a separate project of sorts where it has a JAR (jsf-ri-iproviders.jar) that people can install separately. This could allow for more flexibility if the vendors happen to change their internal API. I think this covers all of what I had in my notes. Comments? |