You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ivan <xh...@gmail.com> on 2010/01/25 16:20:19 UTC

Web Annotation and web fragment support in Geronimo 3.0

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 !
Ivan

Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by David Jencks <da...@yahoo.com>.
On Jan 25, 2010, at 9:15 PM, Jarek Gawor wrote:

> IMHO, I don't think we should worry about the JAXB conversion now
> unless there is no other way to fix the given problem. It might help
> things in long long term but right now I think it is important to get
> things running first. I especially don't want to debug 2 versions of
> all the builders.

If we keep the same basic idea of the tomcat builder as we have now, I  
agree.  If we decide to replace digester for processing web.xml, jaxb  
is the only plausible choice IMO.  Similarly if we decide to write a  
"universal" web builder that uses the new spec "add-a-servlet" apis  
we'll need a jaxb web.xml model.

I haven't investigated thoroughly but I suspect that we could  
eliminate most of the weird convolutions in the tomcat integration if  
we did our own web.xml processing so we could easily control which  
objects get used for web context, servlet wrapper, etc.   It's  
possible that we could also do this by changing the digester rules but  
I find these very hard to understand and debug compared with modified  
jaxb objects.

And, just because I think replacing digester would simplify the code a  
lot doesn't necessarily mean that right now is the best time to do it.

thanks
david jencks

>
> Jarek
>
> On Mon, Jan 25, 2010 at 9:42 PM, David Jencks  
> <da...@yahoo.com> wrote:
>>
>> 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 <da...@yahoo.com>
>>>
>>> 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 <david_jencks@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
>>>>>
>>>>>
>>>
>>
>>
>>
>> --
>> Ivan
>>
>>


Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by Jarek Gawor <jg...@gmail.com>.
IMHO, I don't think we should worry about the JAXB conversion now
unless there is no other way to fix the given problem. It might help
things in long long term but right now I think it is important to get
things running first. I especially don't want to debug 2 versions of
all the builders.

Jarek

On Mon, Jan 25, 2010 at 9:42 PM, David Jencks <da...@yahoo.com> wrote:
>
> 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 <da...@yahoo.com>
>>
>> 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 <da...@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
>>>>
>>>>
>>
>
>
>
> --
> Ivan
>
>

Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by Ivan <xh...@gmail.com>.
Great, looking forward it !

2010/1/26 David Jencks <da...@yahoo.com>

>
> 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 <da...@yahoo.com>
>
>>
>> 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 <da...@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
>>>>>
>>>>
>>>>
>>>>
>>
>
>
> --
> Ivan
>
>
>


-- 
Ivan

Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com>
>
> 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  
> <da...@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
>
>
>
>
>
>
> -- 
> Ivan


Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by Ivan <xh...@gmail.com>.
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.

2010/1/26 David Jencks <da...@yahoo.com>

>
> 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 <da...@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
>>>>
>>>
>>>
>>>
>


-- 
Ivan

Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by David Jencks <da...@yahoo.com>.
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  
> <da...@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
>>
>>


Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by Jarek Gawor <jg...@gmail.com>.
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 <da...@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
>
>

Re: Web Annotation and web fragment support in Geronimo 3.0

Posted by David Jencks <da...@yahoo.com>.
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