RE: InjectionProviders

From: <>
Date: Wed, 03 Jan 2007 13:33:25 -0500

I guess I'd rather see the implementation follow the conventions of the JSF-spec with Factory/Service/META-INF relationships-- even to piggyback on the same file for providing your injection factory. Is that possible?

> wrote:
>> It might be worthwhile to abstract this factory one step further and
>> have a single meta-inf entry for all RI-based Factories:
>> /META-INF/services/com.sun.faces.spi.factories
>> com.sun.enterprise.InjectionManager:com.sun.faces.vendor.GlassFishInjection
>> some other type: some other implementation
>Mind expanding on this idea a bit? Do you see a need for custom factories?
>> 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:
>> 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?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail: