Ummmm... I've already cracked open the wars to remove the "we recommend
tomcat" comments as well as remove the invoker reference. The updated
wars were published to svn.apache.org/repository/geronimo/wars and there
is a patch in JIRA 1299 to pickup the new dependency.
David Jencks wrote:
Thinking about this again, I think (4) is the best option. I think we
can do this by adding a gbean to the plan for this app that deploys the
invoker servlet "by hand", similarly to the default servlets in the
jetty deployer plan. You need to include a reference to the web-app
gbean so the servletholder gbean realizes it is really part of a web app
and not a default. I think you need to specify the gbeanName completely
also since the j2eeType should be Servlet (?) rather than DefaultServlet(?)
thanks
david jencks
On Dec 6, 2005, at 5:46 AM, Dave Colasurdo wrote:
Well, looks like options 3 and 4 have been eliminated from the list
below. I'd prefer option 1. While not the ideal resolution, it does
allow for a quick resolution and provides the examples for both tomcat
and jetty. Are there any major objections to this approach?
1) Crack open geronimo-servlet-examples-tomcat-5.5.12.war in ibiblio
and remove the invoker reference.
If we do this we should also remove the following reference from the
jsp-examples main page: "These examples will only work when these
pages are being served by a servlet engine; of course, we recommend
Tomcat"
We can do this ourselves or ask Tomcat to do it..
2) Only make the example(s) available on Tomcat distributions.
3) Install on Jetty and live with the "WARNING: Some GBeans were not
started successfully:" Or find a way to ignore and/or suppress the
WARNING.
4) Figure out a way to leverage the invoker servlet in Jetty. It
seems they do have one. Is the web.xml syntax different?
Greg Wilkins wrote:
David Jencks wrote:
When I wrote the jetty deployer I studied the spec and could not
find any support for this kind of dynamic servlet that isn't listed
in web.xml, so I didn't try to put any in. If someone has a good
argument that it is consistent with the spec (I thought it was not),
we could try something. We might be able to use another default
servlet like the static content one. If we do this I think we need
a way to turn it on and off: this seems like it will lead us to
having the deployer know about all or many of the default servlets,
something I am not entirely thrilled with.
thanks
david jencks
+1. The invoker is not a very secure mechanism - it allows any servlet
on the classpath to be run - even if you have not configured it.
It is hard to know exactly all the servlets that may lurk on a
classpath or
even to know what the full classpath is.
Jetty and Tomcat by default have the invoker servlet turned off and
nobody
every complains (to Jetty anyway).
So I would suggest either living with the warning or removing the
invoker
mapping from the demos.
Also might be an idea to check the tomcat deployer - because either
it is suppressing a warning or it has the invoker servlet configured
by default.
neither are optimal cheers
