Tomcat Setup and configuration
I realize that this is probably a 'tomcat-user' question, but since my intention is towards dev efforts, I hope no one minds my posting it here. If necessary I'll post it to the users list. I've run into 3 issues described below. Of them, #3 is the most important to me and I really need to get it resolved rapidly. Hopefully in all cases I'm just being an idiot and someone here can nudge me with the obvious answers. :-) I'm having trouble figuring out how to setup Tomcat in the following particular manner: I've installed Tomcat 3.2.1 into /opt/local/tomcat and have set TOMCAT_HOME=/opt/local/tomcat. However I have a need to keep my actual application completely separate from the above installation. (This is not an unusual idea: keep all application-specific data, scripts and configuration independent of the COTS installation). My application is thus, for example, installed in APP_HOME=/opt/demo. I've created a server.xml file for the application and I start tomcat using the option "-f /opt/demo/conf/server.xml". So far so good. Issue#1: The comments in the server.xml file say that by setting the "home" attribute to the ContextManager element, that "...webapps/, work/ and log/tomcat_logs/ will be relative to this...". So I set this attribute to home="/opt/demo". However, because the tc_log, servlet_log and JASPER_log are all defined outside the scope of the ContextManager, I soon find that by default, tomcat still writes it's logs back to TOMCAT_HOME/logs/*. There does not seem to be a single attribute in server.xml that can tell tomcat to route all Logger output to have a different root directory (i.e., I'd prefer to write to APP_HOME/logs/*). So I am forced to edit the 'path' attribute of every Logger element to have an absolute path like so : path="/opt/demo/logs/tomcat.log". Q: Wouldn't it be easier to have a 'home' attribute on the Server element that would be used as the base for all relative paths in nested elements (i.e. Logger, ContextManager, Context, etc.) And even better, wouldn't it be nice to be able to set that at the command-line with a an option? That would make it much easier to reuse server.xml settings across multiple deployments. Basically, I think tomcat needs to have the ability to clearly separate the TOMCAT_HOME installation from the configuration and data for a particular application. Not doing so is kind of like assuming that every user wants to store all his MS Word documents into C:/Program Files/Microsoft/Word/documents/ (or wherever the MS Word application is installed). Issue#2 Having set the ContextManager home="/opt/demo" ... attribute, Tomcat does seem to be finding the work and webapps directories correctly. And it also seems to create certain output, such as the "tomcat-apache.conf" file correctly inside the "/opt/demo/conf/" directory. Q: While there are attributes (workDir, path) for changing the names used for the scratch directory and the location of a webapp context, there seems no way to change the name or location used for the conf/ directory. It is 'fixed' as relative to the home path. Since configuration data is often deployment specific, I would greatly appreciate the ability to direct tomcat to use a particular directory for conf (for example if I need to deploy to both linux and nt I might want to specify APP_HOME/conf/linux/ for one and APP_HOME/conf/nt/ for the other.). If this capability already exists, could someone please explain to me how to invoke it? At any rate, given the above, I am now able to run tomcat and launch, compile and run JSPs using the default jasper JspServlet. I am also able to invoke classes I've included in the CLASSPATH just fine. I still have some issue with referencing classes with the default JasperLoader but I think this is because the ClassPath pulled from the init-params is not set. I'm not to worried about that one. Issue#3: The documentation in the "Tomcat - A Minimalistic User's Guide" says: "Tomcat lets the user define default web.xml values for all context by putting a default web.xml file in the conf directory.". This sounds reasonable, as there needs to be some global registration of such servlets as, for example, the JspServlet. So, I promptly placed a copy of web.xml in my APP_HOME/conf directory and edited it to change the servlet class used for JSPs. I first tried doing this by simply replacing: servlet servlet-name jsp /servlet-name servlet-class org.apache.jasper.runtime.JspServlet /servlet-class /servlet with: servlet servlet-name jsp /servlet-name servlet-class com.my.package.JspServlet /servlet-class /servlet At this point, I would expect that tomcat would send all *.jsp requests to the 'jsp' servlet which should use my class as indicated above for servlet. However, it does not. At this point, I try making a
Re: Tomcat Setup and configuration
The intention ( in tc3.3 ) is to make all the configurations "explicit",
instead of using conventions like "webapps will be in home, libs in
install, etc".
Even in 3.2 we tried to allow a shared installation dir and multiple
work dirs ( i.e. you have one tomcat installed in /opt/tomcat, and each
user can run it with it's port and webapps ). This is not a "supported"
feature - i.e. it's not very well tested or documented.
For issue #1, it's a bug - logs are "special" in 3.2 and they were not
made relative to the home. The workaround is to use explicit paths.
In 3.3, the logs are corectly set relative to TOMCAT_HOME.
If nobody objects to the config changes I'll also add the ant-style syntax
for ${properties}, so you'll have more flexibility. Nacho started
a nice idea in the loggers ( adding a ${TIMESTMAP} ), and I plan to add
other pre-defined properties (like configdir, context home, context
workdir ).
Again - the current mechanism is indeed a bit confusing and complex, and
making it explicit will be a big step forward ( i.e. all paths will use
${tomcat.home}/logs/mylog.log )
better, wouldn't it be nice to be able to set that at
the command-line with a an option? That would make it
That's something I work on, but it's lower priority. ( better command line
support )
Issue #2 ( conf dir ) - again, in 3.3 most if this is configurable via
individual module options. For example the apache.conf is generated by a
module - and you'll be able to set the location to anything you want
( or any other properties that affect its behavior )
Henri proposed to make it simple to use Linux-style hierarchy ( with
all logs in /var/log, configs in /etc/tomcat, webapps in /var/tomcat,
etc). Apache also have a "layout" option.
Regarding Issue #3 - the web.xml is not used in tomcat3.2,
and will not be used in tomcat3.3. All the server config
is done using server.xml ( and the new context.xml ) files.
There shouldn't be any overlap between web.xml and sever.xml,
any setting that is part of web.xml should be part of
the web application's WEB-INF to make sure the app is
portable ( if you rely on any tomcat-specific default,
your app will work only on tomcat).
Server.xml sets server behavior. For example, the
conversion between .jsp and java is a server property.
The static interceptor is a server property. Everything
that is not defined in the web.dtd belongs in server.xml,
and it's specific to tomcat. What is defined in web.dtd
and the spec belongs to WEB-INF/web.xml.
At this point, I try making a variety of changes to
the web.xml file, including registering my servlet
Web.xml is not read - it's just a template you can
use for your applications.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
Costin - Thanks a ton for your reply. Very helpful.
--- [EMAIL PROTECTED] wrote:
The intention ( in tc3.3 ) is to make all the
configurations "explicit",
instead of using conventions like "webapps will be
in home, libs in
install, etc".
This sound great. I am a big proponent of explicit
configuration (with implicit defaults, of course).
For issue #1, it's a bug - logs are "special" in 3.2
and they were not
made relative to the home. The workaround is to use
explicit paths.
In 3.3, the logs are corectly set relative to
TOMCAT_HOME.
Shouldn't they be by default set relative to the
application home? I.E. if we have one install of
tomcat on the system, (TOMCAT_HOME =
/opt/local/tomcat) and we have two different
applications on the box (using, perhaps different
ports) with different server.xml files and
ContextManager 'home' attributes), the log output
should be consider 'of the application' in each case
and should be implicitely written to paths relative to
the application 'home', not into TOMCAT_HOME. This
is simple OO partitioning of responsibilities.
If nobody objects to the config changes I'll also
add the ant-style syntax
for ${properties}, so you'll have more flexibility.
No objection. Sounds like a good idea. The
${property} syntax is consistent with the Security
Manager policy file format as well. I've implemented
it in my own application's configuration file scheme.
Down the road an include mechanism would be a good
idea to add as well (i.e. add a server.xml element
server-include which could take a path (or even a
URL) to an external config file that could be imported
into the DOM). Having built this sort of thing
before, I realize this not trivial (recursion,
protocol for conflict resolution, etc.) but the value
is high.
Issue #2 ( conf dir ) - again, in 3.3 most if this
is configurable via
individual module options. For example the
apache.conf is generated by a
module - and you'll be able to set the location to
anything you want
( or any other properties that affect its behavior )
Is this available in the current 3.3 milestone or
nightly builds?
Regarding Issue #3 - the web.xml is not used in
tomcat3.2,
and will not be used in tomcat3.3. All the server
config
is done using server.xml ( and the new context.xml )
files.
That sounds great. At least I now know what is (not)
going on! :-)
Q1: Why does it say in the documentation that
conf/web.xml is used as a default? Needs to be
corrected.
Q2: More importantly, I'm still left with: How do I
configure the use of a different servlet to handle
*.jsp requests?
Server.xml sets server behavior. For example, the
conversion between .jsp and java is a server
property.
The static interceptor is a server property.
Everything
that is not defined in the web.dtd belongs in
server.xml,
and it's specific to tomcat. What is defined in
web.dtd
and the spec belongs to WEB-INF/web.xml.
Okay, so it sounds like I need to reconfigure the
StaticInterceptor module. And I would do this... how?
Is this possible on 3.2.1 or do I need to go to 3.3
for this? Could someone point me in the right
direction here?
Thanks again for your help.
Mel
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
In 3.3, the logs are corectly set relative to TOMCAT_HOME. and should be implicitely written to paths relative to the application 'home', not into TOMCAT_HOME. This is simple OO partitioning of responsibilities. Ok, this is a clear example of what's wrong with the current status - there are 2 directories that can be set on ContextManager, one is "home" and the other one is "installDir". The env. variable is used to set home. If one is set and the other not - both share the same value. InstallDir is the one used for jar files ( and all "shared" files ). home is supposed to be used for the local instance. ( the model is again a shared installation - /usr/local or /opt/tomcat and each user having it's own config and set of applications ). That's just a particular use case, and even for that it's too complex. By using explicit paths we can accomodate more use cases and be very clear about what goes where. Down the road an include mechanism would be a good idea to add as well (i.e. add a server.xml element server-include which could take a path (or even a URL) to an external config file that could be imported No need, it's already done ( and in 3.2 too ). ( I have no idea who did it - it's not me, and I was quite surprised to find it there :-) Any file named server-foo.xml will be read and used as addition to server.xml. In 3.3 you can use serverXmlReader to read additional files in arbitrary locations. Part of the current proposal is to formalize that and use explicit directives for what gets read. module - and you'll be able to set the location to anything you want ( or any other properties that affect its behavior ) Is this available in the current 3.3 milestone or nightly builds? The first milestone will happen soon, it's only in the nightly builds and it's not yet completed ( i.e. some of the paths are now configurable, but not all and not in all modules ). One of the goals for 3.3 release is to have all those small things that makes configuration easy ( as usability enhancements ). Q1: Why does it say in the documentation that conf/web.xml is used as a default? Needs to be corrected. I agree. Q2: More importantly, I'm still left with: How do I configure the use of a different servlet to handle *.jsp requests? In 3.3 - in JspInterceptor you have "useJspServlet" and "jspServlet" that allows you to specify it on a global level ( or per context ! ). This is strongly discuraged - as it'll be much slower than using JspInterceptor's optimizations. If your jsp processor does something special, you can bundle it with your application and use the web.xml ( from WEB-INF ) to set it. Then your app will work on any container the way you expect. Okay, so it sounds like I need to reconfigure the StaticInterceptor module. And I would do this... how? Is this possible on 3.2.1 or do I need to go to 3.3 for this? Could someone point me in the right direction here? Again - you can do it in a portable way ( using web.xml in your application ) or tomcat-specific, by replacing StaticInterceptor. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat Setup and configuration
No need, it's already done ( and in 3.2 too ). ( I have no idea who did it - it's not me, and I was quite surprised to find it there :-) Erggg, hummm, i did from code of Alex Chafee, it was inadvertly slipped in a commit many time ago ( about August or Sept ) , but it's truly useful :) so it's there .. and it's very tested a least for me :).. Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
--- [EMAIL PROTECTED] wrote: Ok, this is a clear example of what's wrong with the current status - there are 2 directories that can be set on ContextManager, one is "home" and the other one is "installDir". The env. variable is used to set home. Where is this stuff documented? There doesn't seem to be a DTD for server.xml. If one is set and the other not - both share the same value. InstallDir is the one used for jar files ( and all "shared" files ). home is supposed to be used for the local instance. ( the model is again a shared installation - /usr/local or /opt/tomcat and each user having it's own config and set of applications ). so you seem to be saying that one would set InstallDir - TOMCAT_HOME and home - APP_HOME. I'll test that out. By using explicit paths we can accomodate more use cases and be very clear about what goes where. yup. Down the road an include mechanism would be a good No need, it's already done ( and in 3.2 too ). Luv it. Thanks for pointing that out. One of the goals for 3.3 release is to have all those small things that makes configuration easy ( as usability enhancements ). These issues directly affect configuration management and are critical for managing complex deployments. I don't think enough people take this area seriously enough (code features now, worry about deployment later!). Q2: More importantly, I'm still left with: How do I configure the use of a different servlet to handle *.jsp requests? In 3.3 - in JspInterceptor you have "useJspServlet" and "jspServlet" that allows you to specify it on a global level ( or per context ! ). This is strongly discuraged - as it'll be much slower than using JspInterceptor's optimizations. Why exactly would it be 'much' slower? Does that presume that a custom JspServlet would be inherently slower or that the default org.apache.jasper.runtime.JspServlet is somehow accellerated by something JspInterceptor does? Hypothetical: If I were to modify org.apache.jasper.runtime.JspServlet (or make a replacement and pre-load it in the CLASSPATH) would that be 'much slower' (even though it should not require setting the 'useJspServlet' tag since it would appear to be the regular default class)? Just curious about your statement. If your jsp processor does something special, you can bundle it with your application and use the web.xml ( from WEB-INF ) to set it. Then your app will work on any container the way you expect. This may be suitable for some situations, but I have other situations where I need to have complete control over what JSP compiler is used by the servlet engine. This sort of configuration (specifying what servlet to route a request to) is easy with JServ, WebLogic Server and other servlet engines. I'm not sure why it shouldn't be just as simple on Tomcat. Especially since fundamentally Jasper is a standalone servlet package that runs fine on other servlet engines than Tomcat. One should be able to plug-in a different JSP processing servlet (or any default servlet) with no more work than changing a line in a configuration file. It sounds like 3.3 brings this ease in the JspInterceptor. I'm pretty intimate with the Jasper API, but still learning the Tomcat API. I'm still working on understanding how the Connector and Interceptor patterns are implemented. Thanks again for the help. Cheers, mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
status - there are 2 directories that can be set on ContextManager, one is "home" and the other one is "installDir". The env. variable is used to set home. Where is this stuff documented? There doesn't seem to be a DTD for server.xml. It's still on the TODO list, but it'll happen only after we add the ant style config directives ( since that will allow us to define all the attributes for JspInterceptor, and different attributes for StaticInterceptor - each module has it's own properties ). ( same problems as in ant - user modules can't be coded in the dtd ). BTW, there is already code checked in that will read all the .java code, and for all classes that extends BaseInterceptor it'll extract the comments for the setters and generate a xml file. The .dtd generation can be easily automated ( the goal is mostly to generate user documentation for modules that is in sync with the real code ) so you seem to be saying that one would set InstallDir - TOMCAT_HOME and home - APP_HOME. I'll test that out. Confusing, isn't it :-) ? ( it's easy for me to criticize that - I wrote a lot of this code, so I'm not at risk to offend anyone else :-) These issues directly affect configuration management and are critical for managing complex deployments. I don't think enough people take this area seriously enough (code features now, worry about deployment later!). IMHO the biggest problem is that people deploying tomcat are not providing enough feedback and are not contributing back code or documentation. Yes, we had requests for this kind of configuration ( with separate install and user dir ), and the intial code has been written way ago. I tried to do it as good as I could - but I can't guess what's easy and what isn't from a deployment perspective. Why exactly would it be 'much' slower? Does that presume that a custom JspServlet would be inherently slower or that the default org.apache.jasper.runtime.JspServlet is somehow accellerated by something JspInterceptor does? No, the overhead of using a servlet to invoke the jsp page is significant ( at least in my tests is shows a big difference ). JspInterceptor does a simple thing - after the jsp page is compiled to a servlet, the servlet will be "registered" to tomcat ( as if it was declared in web.xml ) and after that all invocations to the jsp page are identical with invocations for servlets ( with one exception - jsp_precompile param must be read on each request and if present, the request shouldn't be executed - that's the spec ). ( reloading is also done in the same way, using DependManager ). replacement and pre-load it in the CLASSPATH) would that be 'much slower' (even though it should not require setting the 'useJspServlet' tag since it would appear to be the regular default class)? Just curious about your statement. Try it yourself, send back the results :-) ( ab -n 1 -c 80 http://localhost:8080/foo.jsp with JspInterceptor in both modes ). ( useJspServlet means JspInterceptor will do nothing, just return ). ( of course, you can compare 3.3 with JspInterceptor with 3.2.1 without it - but there are other factors in that) ( as developer I do this kind of tests quite often to track if the changes are affecting the performance, and everyone should do it once in a while ) processing servlet (or any default servlet) with no more work than changing a line in a configuration file. It sounds like 3.3 brings this ease in the JspInterceptor. Well, it is possible in 3.2 also, but you need a special module that will set the jsp implementation. It's not hard to do, but it's not there by default. ( I sent to the list one that changed jasper settings, you just need to add few lines to change jasper with a different one). The module will do nothing else, just alter some settings - you add it to server.xml. I'm pretty intimate with the Jasper API, but still learning the Tomcat API. I'm still working on understanding how the Connector and Interceptor patterns are implemented. A good news - in 3.3 there is no Connector API :-) ( the Connector is just a regular module ) ( well, we are still far away from the rafinaments in Apache 2.0 where even the threads are managed by a plugable module - but the model for modularization is close ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
--- [EMAIL PROTECTED] wrote: No, the overhead of using a servlet to invoke the jsp page is significant ( at least in my tests is shows a big difference ). JspInterceptor does a simple thing - after the jsp page is compiled to a servlet, the servlet will be "registered" to tomcat ( as if it was declared in web.xml ) and after that all invocations to the jsp page are identical with invocations for servlets ( with one exception - jsp_precompile param must be read on each request and if present, the request shouldn't be executed - that's the spec ). This almost implies some special behavior on the part of the base HttpJspPage class (i.e. 'JspBase') used to build the jsp servlet. Is that so? Is there any problem for jsp pages that use the %@page extends=... tag that don't extend org.apache.jasper.runtime.JspBase but rather instead (as per spec) simply implement javax.servlet.jsp.HttpJspPage? One of the things that really gripes me about the WebLogic JSP servlet engine and JSP compiler is that it has dependencies on the proprietary base class used to generate JSP servlets. There are a lot of problems with this so I hope that we don't send tomcat/jasper down that road. Try it yourself, send back the results :-) ( ab -n 1 -c 80 http://localhost:8080/foo.jsp with JspInterceptor in both modes ). ( useJspServlet means JspInterceptor will do nothing, just return ). ( of course, you can compare 3.3 with JspInterceptor with 3.2.1 without it - but there are other factors in that) It looks like I'll need to get the 3.3 version to try this out! :-) Thanks again, Costin. mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
