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
