Jason Lee wrote:
> Sounds good to me. With regard to packaging, I agree that #2 seems
> pretty heavy, though I think the RI build depends on glassfish anyway,
> so that one will already be installed in most, if not all, cases I would
> think.
That's one thing I have changed locally. The build itself doens't
depend on GlassFish now.
It will only use GlassFish for testing.
> Downloading tomcat and jetty would be a one-time thing, so I'm
> not really opposed to it, but option 1 does it make it a little easier
> for those not interested in working on the injection providers to get
> there environment set up. Long story short, I'd lean toward option 1,
> but I won't lose any sleep if the consensus is option 2.
>
I'm working on a way to have option 1 work, but it looks like it will
need a small script.
> -----
> Jason Lee, SCJP
> Programmer/Analyst
> http://www.iec-okc.com
>
>
>
>> -----Original Message-----
>> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
>> Sent: Tuesday, January 02, 2007 4:08 PM
>> To: dev_at_javaserverfaces.dev.java.net
>> Subject: Re: InjectionProviders
>>
>> Jason Lee wrote:
>>
>>> If I understand this correctly, this gives us out of the
>>>
>> box support
>>
>>> for basic annotations for the two most popular non-EE environments,
>>> Tomcat and Jetty.
>>>
>> Out of the box support for whatever Tomcat or Jetty supports.
>> For Tomcat 5.x environements, then it would just be
>> PostConstruct/PreDestory support.
>>
>>> "Full" EE environments (like JBoss, oc4j, etc) will need to write
>>> their own Injection handler to manage all of the EE
>>>
>> annotations, which
>>
>>> they're expected/required to do anyway, right?
>>>
>> Right, they would. And if they integrate the 1.2 RI, then
>> they implement the InjectionProvider so that JSF can take
>> advantage of it.
>>
>>>
>>> -----
>>> Jason Lee, SCJP
>>> Programmer/Analyst
>>> http://www.iec-okc.com <http://www.iec-okc.com/>
>>>
>>>
>>>
>>>
>> --------------------------------------------------------------
>> ----------
>>
>>> *From:* Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
>>> *Sent:* Tuesday, January 02, 2007 12:51 PM
>>> *To:* dev_at_javaserverfaces.dev.java.net
>>> *Subject:* InjectionProviders
>>>
>>> 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.enterp
>> rise.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?
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>