On 22/09/2018 01:11, Igal Sapir wrote:
Mark,
On Fri, Sep 21, 2018 at 12:54 AM Mark Thomas <ma...@apache.org> wrote:
On 21/09/18 05:57, Igal Sapir wrote:
I want to embed Tomcat in a simple application that does not use JSP, and
that sets the default servlet's listings initParam to true.
When I use the StandardContext, Tomcat.initWebappDefaults() [1] is called
and adds the default servlet and the JSP servlet. I would like to
prevent
that, but hopefully without having to rewrite the whole Tomcat class nor
to
subclass it.
Further, when I try to override a setting in WEB-INF/web.xml, e.g. to
specify init-param of "listings" with value "true" for the servlet
"default", I get an error that "default" is not unique, but in a regular
Tomcat deployment that works just fine.
Is there an easy way to override Tomcat.initWebappDefaults() or to
prevent
it from being called?
There are a couple few options.
Sub-classing looks to be the simplest.
You can use addContext() rather than addWebapp() but then you become
responsible for all of the configuration. If the app is simple, this
shouldn't be too much effort.
The app is simple, but it is for use by other developers who may use their
own web.xml files, so I think that sub-classing would be much easier and
that's what I did.
While searching for a solution prior to asking on the mailing list, I
noticed that quite a few users were looking for a simple solution of using
addWebapp() without setting up the default servlets. What do you think
about adding a System Property that will allow to opt-out of
initWebappDefaults() and set the DefaultWebXml to null so that the web.xml
files will be parsed?
I have a huge dislike for using system properties for configuration. A
setter on the Tomcat class would be fine.
I am thinking of a property name
org.apache.catalina.startup.INIT_WEBAPP_DEFAULTS [default true], or
org.apache.catalina.startup.DISABLE_WEBAPP_DEFAULTS [default false].
Alternatively, we can add the sub-classing implementation that I used (with
the proper ASF license headers, of course). The code is pasted below in
case anyone else needs such an implementation.
I can add either solution myself if approved.
I can imagine different users wanting to do various different things
here. I am wondering if there is a better way of handling this. The
tricky part is that we want to offer lots of flexibility in what is a
potentially complex area while keeping usage really simple.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
