Great, looking forward it ! 2010/1/26 David Jencks <[email protected]>
> > On Jan 25, 2010, at 6:30 PM, Ivan wrote: > > 1. I saw the empty web.xml file also, I would suggest that even if we > really need that file, it should be added by DeploymentContext, not directly > write to repository. > > 2. Thanks for the suggest of using JAXB, I am sure that it would be easy to > parse/generate xml file. But how about generating a full jaxb classes for > Java EE deployment descriptors. I knew that we have had a XMLBeans version, > but I wish that we should replace it in the future. > Anyway, I would first try to generate the jaxb classes for > web-3.0/web-fragment/web-common and the required reference types from javaee > schema, so that it would keep the effect in the web-builder module. > > > According to David Blevins you'll want to tweak the generated jaxb classes > to get more reasonable classes. Openejb has all of this done for ee5 xsds. > I would start with those and see how to update for the schema additions. > > Also, we'll need 2 versions of all the naming builders, one for jaxb and > one for xmlbeans, until we get everything converted. > > I was thinking of doing the same for connectors which have the advantage > that they don't call any naming builders. > > thanks > david jencks > > > 2010/1/26 David Jencks <[email protected]> > >> >> On Jan 25, 2010, at 2:51 PM, Jarek Gawor wrote: >> >> 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. >>> >> >> The only way to be sure is to take it out and see what happens :-) >> IIRC the main purpose is to write the metada-complete web.xml out for >> tomcat to find... but I may not RC. >> >> thanks >> david jencks >> >> >> >>> Jarek >>> >>> On Mon, Jan 25, 2010 at 1:31 PM, David Jencks <[email protected]> >>> 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 >>>>> >>>> >>>> >>>> >> > > > -- > Ivan > > > -- Ivan
