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. 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.
-----
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
>
>