[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] Servlet-3.0 WebApp configuration
|
Greg,
Some comments. A bit stream-of-consciousness, sorry.
> UnpackConfiguration
> -------------------
> unpack war file depending on configured
> attributes of the webAppContext
> Potentially expand WEB-INF/lib/* separately
> to avoid jar locking issues.
OK.
> 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.
> TempDirConfiguration
> --------------------
>
> configure the tempdir location, potentially using a WEB-INF/work directory
OK.
> 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?
> 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.
> 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)
> 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.
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.
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.
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.
> 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.
> 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.
> ListenerConfiguration
> ---------------------
> Call all listeners (which can do programmatic configuration)
OK.
> LoadOnStartupConfiguration
> --------------------------
> Sort and instantiate all load-on-startup servlets
OK.
What are you thinking of as far as a Configuration base class looks
like?
Jan
--
Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
