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
<[email protected]> 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 <[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
