[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] Servlet-3.0 WebApp configuration
|
Greg,
maybe it's the classic "around" aop-y trilogy:
interface WebAppConfiguration
{
void preConfigure(WebAppContext context);
void configure(WebAppContext context);
void postConfigure(WebAppContext context);
}
?
Jan
Greg Wilkins wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
