I agree. I think it would good for Geronimo to construct the
metadata-complete web.xml and pass it to Tomcat to handle the rest.

Btw, in TomcatModuleBuilder.addGBeans() there is a bit of code that
(re)writes a web.xml. Does anybody know why is that (still) needed?
The comment above that bit of code talks about when web.xml is missing
(in jaxws case) but the code seems to be writing an empty web.xml even
if web.xml is present and has Java EE namespace.

Jarek

On Mon, Jan 25, 2010 at 1:31 PM, David Jencks <david_jen...@yahoo.com> wrote:
>
> On Jan 25, 2010, at 7:20 AM, Ivan wrote:
>
>> Hi,
>>    Recently, I am looking at the annoation  and web fragment in Servlet
>> 3.0. After checking some integration codes, it seems that we have different
>> strategy for Tomcat and Jetty, in Tomcat plugin, after doing some
>> verification and web service process work, Geronimo will pass the web.xml
>> file directly to Tomcat, and then Tomcat will parse the web.xml file and
>> call the addChild method to register all the servlets to context. While in
>> Jetty plugin, all the work is done in Servlet GBean and Jetty will not check
>> the web.xml file (At least for servlet configurations).
>>    So in Geronimo 3.0, who will be resposible for the annotation and web
>> fragment scanning. For Tomcat, one way is still to let Tomcat does it,
>> actually I found some related codes are added in ContextConfig class.
>> Although I found some errors while trying it, it should be easy to solve.
>> Another way is to scan by Geronimo, then create a gbean for each servlet
>> like Jetty, or just generate a full web.xml file.
>>    Personally, I wish to do it by Geronimo, so that Geronimo could have a
>> full control of it, which keeps the same way with Jetty. Also, I have
>> another idea about improving the class scanning, IIRC, many builders require
>> annoation scanning or file scanning, like web-builder, webservice-builder,
>> etc. I am thinking that whether we could do all the scanning work in one
>> round, not a new round search would be triggered by each builder. Maybe, we
>> could add some methods like registerScanningHandler in the
>> DeploymentContext, and once the temp bundle is installed, all the scanning
>> work be will done in one round.
>>    Any comment ? Thanks !
>
> In tomcat, I think we have to let tomcat create the servlet wrapper objects.
>  Several people have tried to turn them into gbeans but it conflicts with
> tomcat's attempt to manage the component lifecycle.  I think we could write
> a jaxb-based processor to replace the tomcat digester one and this might
> simplify our code.
>
> I would prefer that geronimo scan for annotations and construct a complete
> web.xml from them and then process the web.xml either through our code (like
> in jetty) or through the web containers code (like in tomcat).
>
> Another possibility would be to use the new servlet 3.0 apis for adding
> servlets etc to a web app.  We might be able to write a single processor to
> read through the metadata-complete web.xml and call the appropriate methods
> to construct the web app.  At the moment I don't recall any
> geronimo-specific configuration that applies to specific servlets, filters,
> or listeners so this code might not need to look in geronimo plans very
> much.
>
> I like your idea of combining the annotation scanning.
>
> thanks
> david jencks
>
>
>> Ivan
>
>

Reply via email to