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]
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 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: > > 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
> 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
> > 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 > 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 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
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 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
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]