Re: [jetty-dev] Servlet-3.0 WebApp configuration

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Jan Bartel wrote:
> Greg,
>
> Some comments. A bit stream-of-consciousness, sorry.

> > WebInfConfiguration:
> > --------------------
> >
> >  discover WEB-INF/classes and add to class-path
> >
> >  discover WEB-INF/lib/*.jar  and for each:
> >    a) add to class-path
> >    b) scan jar index for
> >       i)   META-INF/web-fragment.xml
> >            parse (not process) for name and partial orderings
> >       ii)  META-INF/*.tld   add to list of tlds
> >       iii) META-INF/resources add to resource base.
> >
> >  set Thread context classloader
>
> If we parse all the web-fragements at this stage, we might
> do useless processing, as if metadata-complete is true in
> web.xml we don't need to - and shouldn't - look at any
> web fragments.

OK - so perhaps split this into
  WebInfConfiguration
  WebFragmentConfiguration (which is done after WebXmlConfiguration)


> > WebXmlConfiguration
> > -------------------
> >
> > discover defaultweb.xml, WEB-INF/web.xml and override web.xml
> >    a) parse (but not process) to determine
> >       i)  if meta-data complete
> >       ii) if there is a web-fragment ordering
> >
> > Apply orderings to list of WEB-INF/lib/*.jar
> > Store list of jars as attribute for later configurations.
>
> Shouldn't we store the list of jars as an attribute back
> in WebInfConfiguration when we load them onto the classpath?

yes


> > Use meta-data-complete and orderings to merge
> >    * defaultweb.xml
> >    * web.xml
> >    * web-fragment.xml s
> >    * override web.xml
> >
> > to obtain an effective web.xml that respects
> > main merging rules.   Store resulting parse
> > tree as attribute for use by subsequent configuration
>
> Good. I like having the effective web.xml. We can even
> spit that out as a diagnostic.

yep


> > process effective web.xml standard configuration
> >
> >
> > EnvConfiguration
> > ----------------
> > Process the effective web.xml looking for resources
> > and other JNDI type stuff.
> >
> > Process jetty-env.xml
>
> This would have to be done in the other order. jetty-env.xml
> defines resources in the container's environment that you want
> to be able to hook into the webapp via <resource> entries in
> web.xml or annotations. So you need to process jetty-env.xml
> first. Currently we're doing this as 2 separate configurations:
>
> 1. plus.EnvConfiguration:  sets up the webapp's java:comp/env 
>    namespace and then loads resource definitions from jetty-env.xml
>
> 2. plus.Configuration: reads web.xml and hooks up resources
>    from the container's environment into the java:comp/env 
>    namespace, and also prepares any injections that are specified
>    in web.xml (as opposed to injections specified by annotations
>    which are handled by the annotation.Configuration class)

So we need to keep this split, maybe:

  EnvXmlConfiguration
  WebXmlResourceConfiguration

with the later working off the stored effective web.xml
with another pass over it.

the alternative is to have an extensible mechanism
that handles each element from a single pass through
the effective web.xml parse tree


> > AnnotationConfiguration
> > -----------------------
> >
> > For each jar in ordered list scan classes for
> >    a) handled types for ServletContainerInitializers
> >    b) Servlets|Filters|Listeners instances with annotations
> >       i) Setup resource injection for newServlet and newFilter
>
> We also need to have pre-scanned some jars that are in jetty's
> container path (as opposed to the WEB-INF/lib jars) for @HandlesTypes
> annotations. I say pre-scanned because we don't want to re-scan
> for every webapp deployment.

Hmmm maybe.... could be done by a deployer and injected?

> Also, the @HandlesTypes annotation could be handled a little differently
> from the other annotations we scan for. The jdk6 java.util.ServiceLoader
> api will give us back a list of instances of all classes that implement
> the ServletContainerInitializer interface, so we could just use reflection
> to work out if it has a @HandlesTypes annotation as those classes are
> already loaded, unlike in the scanning for the servlet/filter/listener
> classes as we don't want to actually load those classes and therefore
> we need to use asm to look at the byte code instead.

cool

> Now, the actual value of @HandlesTypes annotation can be (quoting from
> draft spec) 
>   "The annotation will be applied on the implementation of
>    ServletContainerInitializer to express interest in classes 
>    that are either annotated with the classes specified in 
>    the value or if a class extends / implements one of those classes."
>
> So during our asm scanning of jars in WEB-INF/lib we need to look both
> at annotations that are known a priori (ie hard coded from the spec) AND
> at annotations that are dynamically discovered from the values of the
> @HandlesTypes annotation on the ServletContainerInitializers classes.
> So in fact, we have to have separately processed the @HandlesTypes
> annotation BEFORE we commence our general jar scanning anyway, so the
> reflection method outlined above seems most reasonable.

ok


> Incidentally, our asm scanning needs to be extended, as currently 
> we just use it to look for annotations, but now we need to also look at
> the class definition to find classes that extend or implement 
> the class names in @HandlesTypes.

or have annotations define in HandlerTypes


> > ContainerInitializerConfiguration
> > ---------------------------------
> >
> > user JVM service discovery to find ServletContainerInitializer classes
> > on container classpath.
> >    a) for each initialize use @HandlesTypes to discover interested classes
> >
> > For each ServletContainerInitializer
> >    i) scan ordered jar list for matching classes (or maybe all jars)
> >    i) call with list of discovered classes and allow to do programmatic
> >       configuration
>
> See comments above. At this stage, we need to loop over the map
> of ServletContainerInitializers, get their interested classes/annotations
> and then get the matching class instances out of the results of our
> asm parsing, then pass them into the onStartup() method of the 
> ServletContainerInitializer.

So I'm thinking this is a split pair of configurations as well.

hmmmmm

I'm wondering if this split configuration pairings really means that
we should have two methods on all the configuration.  Call all of their
first methods and then call all or their second methods?

I think this is better than endless pairings... need to think of
the appropriate names:

 prepareConfiguration
 performConfiguration



> > TagLibConfiguration
> > -------------------
> > Combine list of  META-INF/*.tld with
> >     * TLDs defined in effective web.xml
> >     * TLDs discovered in WEB-INF/*.tld (including
> > META-INF/resources/WEB-INF/*.tld)
> >     Parse TLDs for listeners - add to listener lists.
>
> Don't forget the jars on the container's classpath that we have to 
> also scan for tlds. See the regexp in webdefault.xml that currently
> determines which ones we scan.

Do we have to do this anymore?    I'm not so sure?
But we can have them added to the list I guess for old times!


> What are you thinking of as far as a Configuration base class looks
> like?

now I'm thinking of

interface WebAppConfiguration
{
   void prepareConfiguration(WebAppContext context);
   void performConfiguration(WebAppContext context);
}



cheers