thanks, and a quick web.xml question

[Jeffrey Chiu <jc...@panix.com>]

Thanks for the quick replies from Danno and Sam, they were -extremely- 
helpful in getting me looking in the right places....

Quick question, though: When/where/how does /etc/web.xml get loaded? The 
stock installation loads web.xml from the ./examples and ./webpages 
directories, and if I put in a "jsp" servlet definition in those files my 
newly added init-params, I can get my code to work.

But changing _only_ /etc/web.xml doesn't seem to propagate across all the 
context definitions listed in server.xml.

What am I overlooking or not understanding?

Thanks again, a patch is in the works (as soon as I figure out how to use 
cvs diff)...

Jeff

Re: thanks, and a quick web.xml question

[Danno Ferrin <sh...@earthlink.net>]

My comment was based on a way too quick evaluation of the code tree.  Craig
is right that .../etc/web.xml is not loaded.   It is created by the build
process to reflect what it uses as a default web.xml.  The default web.xml
is actually a resource named "org/apache/tomcat/deployment/web.xml" This
resourse tends to live under the classes dir for a simple "build" build and
in the webserver.jar file in the main directory for a distribution "build
dist" build.  This default web.xml creates some default servlets and
settings that are used unless overridden by the web applications
WEB-INF/web.xml file.  Hence the web-app values take presidence.

So if you need a default init param then change the resource in the code
tree, but it is good to make the compiler plug-in have an implied value that
goes to the current sun-servlet implementation if none is provided by
init-params.  The end-user could either manipulate the jar or the web-apps
themselves if they want a global impact.

--Danno

Craig R. McClanahan wrote:
> Jeffrey Chiu wrote:
>
> > Thanks for the quick replies from Danno and Sam, they were -extremely-
> > helpful in getting me looking in the right places....
> >
> > Quick question, though: When/where/how does /etc/web.xml get loaded? The
> > stock installation loads web.xml from the ./examples and ./webpages
> > directories, and if I put in a "jsp" servlet definition in those files
my
> > newly added init-params, I can get my code to work.
> >
>
> It is not clear to me that "/etc/web.xml" is ever actually loaded by
Tomcat
> -- I think it is there only as an example.
> >
> > But changing _only_ /etc/web.xml doesn't seem to propagate across all
the
> > context definitions listed in server.xml.
> >
> > What am I overlooking or not understanding?
> >
>
> The key concept is that there is one web.xml file for each web application
> you define with a <Context> element in the "server.xml" file.  For each
app,
> this file is located in the WEB-INF directory under the document base that
> you specify.  Also, each application is supposed to be independent of any
> other application.
>
> Therefore, if you want to add new servlets or set initialization
parameters,
> you need to do one of the following:
>
> * Add your settings to the "web.xml" file for one of the
>   two existing Contexts.
>
> * Create a new web application (with it's own WEB-INF
>   subdirectory and "web.xml" file).
>
> >
> > Thanks again, a patch is in the works (as soon as I figure out how to
use
> > cvs diff)...
> >
> > Jeff
> >
>
> Craig McClanahan
>
>

Re: thanks, and a quick web.xml question

[Assaf Arkin <ar...@exoffice.com>]

> futures ramblings ...
> 
> i had hoped to provide a smoother melding of the "internal/system" web.xml
> data and that which is provided by the context author (eg WEB-INF/web.xml)
> since as it stands one can't readily add new attributes/elements/data to
> internally
> defined data (eg jsp engine) w/o redefining the whole thing all over again ...
> kind'a sucks.

I think it would make sense to override a default web.xml coming from
the Servlet JAR with one specified at deployment time outside the
Servlet JAR. The Servlet engine will read the default one from the JAR,
then the overriding one from a configuration directory.

That's something I'm doing right now in Tyrex to override env-entry
values. A Servlet may (or may not) specify a value for an env-entry that
it plans to use. The deployer can (or must) override it with a value
that's specific to the server not the Servlet.

For example, a Servlet may use an environment entry called ldap-url to
decide which LDAP server it should talk to. web.xml will specify that
such an env-entry exists, but not it's value. At deployment time, a
resources file external to the Servlet (which is never modified
directly) will provide the suitable value for ldap-url, which will
change from server to server.

Something like that could be added for the Servlet properties as well.
(environment entries are the J2EE model that requires you use JNDI to
obtain them)

arkin


> 
> >
> >
> > >
> > > But changing _only_ /etc/web.xml doesn't seem to propagate across all the
> > > context definitions listed in server.xml.
> > >
> > > What am I overlooking or not understanding?
> > >
> >
> > The key concept is that there is one web.xml file for each web application
> > you define with a <Context> element in the "server.xml" file.  For each app,
> > this file is located in the WEB-INF directory under the document base that
> > you specify.  Also, each application is supposed to be independent of any
> > other application.
> >
> > Therefore, if you want to add new servlets or set initialization parameters,
> > you need to do one of the following:
> >
> > * Add your settings to the "web.xml" file for one of the
> >   two existing Contexts.
> >
> > * Create a new web application (with it's own WEB-INF
> >   subdirectory and "web.xml" file).
> >
> > >
> > > Thanks again, a patch is in the works (as soon as I figure out how to use
> > > cvs diff)...
> > >
> > > Jeff
> > >
> >
> > Craig McClanahan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: thanks, and a quick web.xml question

[James Todd <jw...@pacbell.net>]

"Craig R. McClanahan" wrote:

> Jeffrey Chiu wrote:
>
> > Thanks for the quick replies from Danno and Sam, they were -extremely-
> > helpful in getting me looking in the right places....
> >
> > Quick question, though: When/where/how does /etc/web.xml get loaded? The
> > stock installation loads web.xml from the ./examples and ./webpages
> > directories, and if I put in a "jsp" servlet definition in those files my
> > newly added init-params, I can get my code to work.
> >
>
> It is not clear to me that "/etc/web.xml" is ever actually loaded by Tomcat
> -- I think it is there only as an example.

yep ... unless things have changed as of late the
org.apache.tomcat.deployment.web.xml
is the "internal" config file to which tomcat's resolver is registered. the
reference
to ../etc/web.xml is provided as a pointer for curious eyes ... from my
perspective.

futures ramblings ...

i had hoped to provide a smoother melding of the "internal/system" web.xml
data and that which is provided by the context author (eg WEB-INF/web.xml)
since as it stands one can't readily add new attributes/elements/data to
internally
defined data (eg jsp engine) w/o redefining the whole thing all over again ...
kind'a sucks.

>
>
> >
> > But changing _only_ /etc/web.xml doesn't seem to propagate across all the
> > context definitions listed in server.xml.
> >
> > What am I overlooking or not understanding?
> >
>
> The key concept is that there is one web.xml file for each web application
> you define with a <Context> element in the "server.xml" file.  For each app,
> this file is located in the WEB-INF directory under the document base that
> you specify.  Also, each application is supposed to be independent of any
> other application.
>
> Therefore, if you want to add new servlets or set initialization parameters,
> you need to do one of the following:
>
> * Add your settings to the "web.xml" file for one of the
>   two existing Contexts.
>
> * Create a new web application (with it's own WEB-INF
>   subdirectory and "web.xml" file).
>
> >
> > Thanks again, a patch is in the works (as soon as I figure out how to use
> > cvs diff)...
> >
> > Jeff
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: thanks, and a quick web.xml question

["Craig R. McClanahan" <cm...@mytownnet.com>]

Jeffrey Chiu wrote:

> Thanks for the quick replies from Danno and Sam, they were -extremely-
> helpful in getting me looking in the right places....
>
> Quick question, though: When/where/how does /etc/web.xml get loaded? The
> stock installation loads web.xml from the ./examples and ./webpages
> directories, and if I put in a "jsp" servlet definition in those files my
> newly added init-params, I can get my code to work.
>

It is not clear to me that "/etc/web.xml" is ever actually loaded by Tomcat
-- I think it is there only as an example.

>
> But changing _only_ /etc/web.xml doesn't seem to propagate across all the
> context definitions listed in server.xml.
>
> What am I overlooking or not understanding?
>

The key concept is that there is one web.xml file for each web application
you define with a <Context> element in the "server.xml" file.  For each app,
this file is located in the WEB-INF directory under the document base that
you specify.  Also, each application is supposed to be independent of any
other application.

Therefore, if you want to add new servlets or set initialization parameters,
you need to do one of the following:

* Add your settings to the "web.xml" file for one of the
  two existing Contexts.

* Create a new web application (with it's own WEB-INF
  subdirectory and "web.xml" file).

>
> Thanks again, a patch is in the works (as soon as I figure out how to use
> cvs diff)...
>
> Jeff
>

Craig McClanahan