RE: TC33b1 Context path behavior: Is this a bug or by design?
Randall, It is the path of the context that makes them unique. So, Context path=/struts-documentation ... / would replace the auto-served context, where: Context path=/strutsdoc ... creates a new context. The fact that its docbase is the same as the one for the /struts-documentation context is irrelavent. If you don't want the struts-documentation.war auto-served, move it out of the webapps directory and expand it manually to a directory outside of webapps. Cheers, Larry -Original Message- From: Randall Parker [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 05, 2001 2:11 AM To: [EMAIL PROTECTED] Subject: TC33b1 Context path behavior: Is this a bug or by design? I'm seeing two different paths as being accepted for pages in the same war file. I'm wondering if the behavior I'm seeing is by design or a bug. I installed the struts-documentation.war file in webapps and restarted Tomcat 3.3 b1. As expected I was able to access such URLs as: http://127.0.0.1:8080/struts-documentation/index.html and http://127.0.0.1:8080/struts-documentation/api/org/apache/stru ts/taglib/bean/package- summary.html#package_description So the leading /struts-documentation mapped to the corresponding war file. Then I decided to add to the /conf dir the following: apps-struts-documentation.xml ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ /Context /webapps After stopping and restarting Tomcat I was then able (as expected) to access pages using the shorter /strutsdoc leading path. For instance: http://127.0.0.1:8080/strutsdoc/index.html However, when I went back and tried the original: http://127.0.0.1:8080/struts-documentation/index.html that still worked. I even did Refresh and fired up a different brand of browser that hadn't previously visited either page to make sure the browser wasn't just loading the older URL from cache. Well, I'd expect that when one defined the Context path in the xml file that that path would _replace_ the default path named after the war file. Is that not the case? Is this normal behavior or incorrect behavior?
RE: TC33b1 Context path behavior: Is this a bug or by design?
Please ignore. Didn't see the other discussion that already deal with this issue. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 9:26 AM To: '[EMAIL PROTECTED]' Subject: RE: TC33b1 Context path behavior: Is this a bug or by design? Randall, It is the path of the context that makes them unique. So, Context path=/struts-documentation ... / would replace the auto-served context, where: Context path=/strutsdoc ... creates a new context. The fact that its docbase is the same as the one for the /struts-documentation context is irrelavent. If you don't want the struts-documentation.war auto-served, move it out of the webapps directory and expand it manually to a directory outside of webapps. Cheers, Larry -Original Message- From: Randall Parker [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 05, 2001 2:11 AM To: [EMAIL PROTECTED] Subject: TC33b1 Context path behavior: Is this a bug or by design? I'm seeing two different paths as being accepted for pages in the same war file. I'm wondering if the behavior I'm seeing is by design or a bug. I installed the struts-documentation.war file in webapps and restarted Tomcat 3.3 b1. As expected I was able to access such URLs as: http://127.0.0.1:8080/struts-documentation/index.html and http://127.0.0.1:8080/struts-documentation/api/org/apache/stru ts/taglib/bean/package- summary.html#package_description So the leading /struts-documentation mapped to the corresponding war file. Then I decided to add to the /conf dir the following: apps-struts-documentation.xml ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ /Context /webapps After stopping and restarting Tomcat I was then able (as expected) to access pages using the shorter /strutsdoc leading path. For instance: http://127.0.0.1:8080/strutsdoc/index.html However, when I went back and tried the original: http://127.0.0.1:8080/struts-documentation/index.html that still worked. I even did Refresh and fired up a different brand of browser that hadn't previously visited either page to make sure the browser wasn't just loading the older URL from cache. Well, I'd expect that when one defined the Context path in the xml file that that path would _replace_ the default path named after the war file. Is that not the case? Is this normal behavior or incorrect behavior?
Re: TC33b1 Context path behavior: Is this a bug or by design?
Hi Randall, I believe the behavior is correct - you have 2 contexts with the same docbase ( one defined in a config file, one automatically ). They are completely independent of each other ( you can look into work and you'll see one work dir for each ). If you write a simple test servlet, you'll see the 2 contexts have different ServletContext objects, and behave like 2 separate webapps. The same thing would happen if you copy or do a (symbolic)link between 2 dirs in /webapps, or you add 2 app-XXX.xml files pointing to the same docbase. BTW, thanks for investigating this :-) Costin On Sat, 4 Aug 2001, Randall Parker wrote: I'm seeing two different paths as being accepted for pages in the same war file. I'm wondering if the behavior I'm seeing is by design or a bug. I installed the struts-documentation.war file in webapps and restarted Tomcat 3.3 b1. As expected I was able to access such URLs as: http://127.0.0.1:8080/struts-documentation/index.html and http://127.0.0.1:8080/struts-documentation/api/org/apache/struts/taglib/bean/package- summary.html#package_description So the leading /struts-documentation mapped to the corresponding war file. Then I decided to add to the /conf dir the following: apps-struts-documentation.xml ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ /Context /webapps After stopping and restarting Tomcat I was then able (as expected) to access pages using the shorter /strutsdoc leading path. For instance: http://127.0.0.1:8080/strutsdoc/index.html However, when I went back and tried the original: http://127.0.0.1:8080/struts-documentation/index.html that still worked. I even did Refresh and fired up a different brand of browser that hadn't previously visited either page to make sure the browser wasn't just loading the older URL from cache. Well, I'd expect that when one defined the Context path in the xml file that that path would _replace_ the default path named after the war file. Is that not the case? Is this normal behavior or incorrect behavior?
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001 00:30:03 -0700 (PDT), [EMAIL PROTECTED] wrote: Hi Randall, I believe the behavior is correct - you have 2 contexts with the same docbase ( one defined in a config file, one automatically ). So is there a way to turn off the creation of that automatic context? I'd also like a way to say If a Context tag is defined then do not also generate an automatic context. I'd also like a way to say Only generate contexts for those which are explicitly defined with a Context tag. Is either of these possible now? They are completely independent of each other ( you can look into work and you'll see one work dir for each ). If you write a simple test servlet, you'll see the 2 contexts have different ServletContext objects, and behave like 2 separate webapps. Its certainly neat that this is possible. One could customize the same WAR to run in two contexts with two different sets of properties. The same thing would happen if you copy or do a (symbolic)link between 2 dirs in /webapps, or you add 2 app-XXX.xml files pointing to the same docbase. BTW, thanks for investigating this :-) You're quite welcome. I really like the apps-XXX.xml feature btw. Costin
Re: TC33b1 Context path behavior: Is this a bug or by design?
So is there a way to turn off the creation of that automatic context? I'd also like a way to say If a Context tag is defined then do not also generate an automatic context. The name of the path attribute and the name of the dir in /webapps have to be the same. You can rename one or the other. I'd also like a way to say Only generate contexts for those which are explicitly defined with a Context tag. There's a way to completely disable automatic Context creation. IIRC, it's by removing one of the elements in server.xml. - r
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001, Randall Parker wrote: So is there a way to turn off the creation of that automatic context? Remove AutoDeploy src=webapps / to disable all automatic contexts ( from webapps ). Move the app out of webapps. AutoDeploy takes all the files from the specified dir and add them. I'd also like a way to say If a Context tag is defined then do not also generate an automatic context. If you place the app under webapps, AutoDeploy will add it. But webapps/ is just a dir, designed to simplify configuration - you can place your webapp anywhere. ( another usefull feature of AutoDeploy is that it can set the virtual host for all the apps loaded from a dir - AutoDeply src=/myHost host=my.host.com / ) You are free to add other modules doing what you want - it's quite easy to write a module that will remove all the modules that are duplicated, or anything like that. All the configuration happens via configuration modules that add other modules, add contexts (manually - via ContextXmlReader config=apps.xml or automatically ). You can play as much as you want at this stage - remove, replace, add modules/contexts/properties. After the context manager moves to STATE_CONFIG, things are different, it means tomcat is in a stable state ( i.e. the config is stable ). I'd also like a way to say Only generate contexts for those which are explicitly defined with a Context tag. Not sure what you mean by that, but if you're not happy with AutoDeploy behavior, it's quite easy to replace it with YourAutoDeploy. The set of modules that is included with 3.3 is supposed to just implement the servlet container, without too much complications or featurs. Is either of these possible now? Anything is possible now ( and if it's not, you can file a bug !). Just write a module that configures it the way you want it ( for most stuff, it should be as easy as writing an ant task, maybe just a bit more difficult ). Tomcat provides the basic container with as-simple-as-possible configurabilty, the behavior of AutoDeploy and other modules is just what we believed is simple enough ( but not simpler :-). It doesn't mean tomcat is limited to only what AutoDeploy can do ( or we don't want other features), it's just that we want manageable code to maintain and the place for features is in modules. You're quite welcome. I really like the apps-XXX.xml feature btw. Then contribute a small html describing what you discover. Costin
Re: TC33b1 Context path behavior: Is this a bug or by design?
Costin, If one does define a context in apps-.xml can one sent context-param tags in it that are then accessible as part of that ServletContext? More generally, can anything from webl.xml be put in server.xml inside a Context tag's scope? See for example the context-param below where this file is an apps-.xml that is in the conf directory. Is this legal and will it work when one does a getInitParameter in a doPost below? If one does this and it works then a further question: Suppose the web.xml defines the pdf-out-path and then the server.xml/apps-.xml redefines it again for the same context. Will the latter value _replace_ the former value? ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ context-param param-namepdf-out-path/param-name param-value\reports\graphics\/param-value /context-param /Context Then in a doPost do: String PdfOutPath = this.getServletContext().getInitParameter(pdf-out-path); javax.servlet.ServletConfig.getServletContext(); javax.servlet.jsp.PageContext On Sun, 5 Aug 2001 00:30:03 -0700 (PDT), [EMAIL PROTECTED] wrote: I believe the behavior is correct - you have 2 contexts with the same docbase ( one defined in a config file, one automatically ). They are completely independent of each other ( you can look into work and you'll see one work dir for each ). If you write a simple test servlet, you'll see the 2 contexts have different ServletContext objects, and behave like 2 separate webapps.
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001, Randall Parker wrote: Costin, If one does define a context in apps-.xml can one sent context-param tags in it that are then accessible as part of that ServletContext? More generally, can anything from webl.xml be put in server.xml inside a Context tag's scope? No, and that's premeditated :-) Keep in mind server.xml ( and apps.xml ) is an ad-hoc format, and just one of the ways to configure tomcat ( there is absolutely nothing in tomcat that cares about server.xml except a small module that happens to read it). Tomcat doesn't care how is configured - it can be ServerXmlReader module, or it can read the modules from a properties file or from an LDAP server. Web.xml on the other side is a clearly specified format. If something can be done in web.xml, it should be done there. But of course, that's just how proper jakarta-tomcat works - i.e. how the current set of modules operate. This is what we provide and support - for anything fancy you can write your own modules, the way you want them. It would be trivial to enhance ContextXmlReader - the module that deals with Context definitions - to support what you want ( but I'm -1 on adding any such enhancement to tomcat3.3 - we already have more than we need, the 'proper' tomcat should have 1/2 of the modules it has today ). If one does this and it works then a further question: Suppose the web.xml defines the pdf-out-path and then the server.xml/apps-.xml redefines it again for the same context. Will the latter value _replace_ the former value? It's up to you and your module. Again, IMHO whatever can be specified in web.xml should be specified there. Tomcat3.3 ( and 3.2 ) already removes another odity - the default web.xml that generated so many bugs and mess in 3.1. If you want your application to be portable, make sure it has all the information it needs in its web.xml - anything you put in apps-XXX.xml, server.xml, etc is specific to tomcat3.x and will be lost if you move your app to a different container. Costin
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001 10:48:31 -0700 (PDT), [EMAIL PROTECTED] wrote: More generally, can anything from webl.xml be put in server.xml inside a Context tag's scope? No, and that's premeditated :-) Okay. Keep in mind server.xml ( and apps.xml ) is an ad-hoc format, and just one of the ways to configure tomcat ( there is absolutely nothing in tomcat that cares about server.xml except a small module that happens to read it). Tomcat doesn't care how is configured - it can be ServerXmlReader module, or it can read the modules from a properties file or from an LDAP server. Well, suppose one wanted to use something else instead of or in addition to the ServerXmlReader module. Would one need to hack Tomcat to do it? Web.xml on the other side is a clearly specified format. If something can be done in web.xml, it should be done there. Well, here's the problem I see with web.xml: It comes as part of a war file. Okay, well and good. But it seems to me that the servlets in a given war have some context that is war-specifc but in some cases the context is going to be site-specific (eg the name of a printer to use or a file path to use to access data or the name of a JDBC database source and so on). Well, shouldn't a war contain nothing that is site-specific? I mean, isn't it the whole idea that a war is like a redistributable application? So how to provide context to servlets when that context is site-specific? This seems like a really basic need. But of course, that's just how proper jakarta-tomcat works - i.e. how the current set of modules operate. This is what we provide and support - for anything fancy you can write your own modules, the way you want them. It would be trivial to enhance ContextXmlReader - the module that deals with Context definitions - to support what you want ( but I'm -1 on adding any such enhancement to tomcat3.3 - we already have more than we need, the 'proper' tomcat should have 1/2 of the modules it has today ). I can appreciate that. Then I need another solution to my problem. What do you think of these ideas: 1) Create a directory that is relative to webapps that is not under webapps where settings for a given war can go in some settings file. so %TOMCAT_HOME%/webapps/reportsystem would be matched %TOMCAT_HOME%/settings/reportsystem/ Then in the web.xml one could do: context-param param-namereportsettings/param-name param-value../../settings/reportsystem/rptconfig.xml/param-value /context-param and after installing the war one would create a relevant file: %TOMCAT_HOME%/settings/reportsystem/rptconfig.xml In the initializatoin of a servlet one would then need to do: String ReportSettingsXMLPath = this.getServletContext().getInitParameter(reportsettings); Then have the servlet's init method open and parse the xml file at ReportSettingsXMLPath in order to get this out of it: context-param param-namepdf-out-path/param-name param-valuereports/graphics/param-value /context-param The idea is to have the web.xml point to a relative path that is outside of the subdirectory where the war gets expanded. This location should be a location that wouldn't get overwritten by war file overwrites. The first time a war file is 2) Similar to the previous item but instead is there some way for the web.xml to have an include to go get a file that is relative to it htat would insert the original xml snippet so that the originally desired info could be put into the servlet context? I don't know XML well enough but I don't think file includes can be done like this without XSLT and I'm guessing that isn't used in reading web.xml. The class that reads in web.xml would need to be able to recognize and deal with a relative include path to some file pathed relative to web.xml or to the curr dir that the web.xml reader uses. Then that relative pathed file would have this in it: context-param param-namepdf-out-path/param-name param-valuereports/graphics/param-value /context-param Basically, I need some way tell a web.xml where to find resources that isn't an absolute path since it has to be portable to different operating systems and sites. If one does this and it works then a further question: Suppose the web.xml defines the pdf-out-path and then the server.xml/apps-.xml redefines it again for the same context. Will the latter value _replace_ the former value? It's up to you and your module. Again, IMHO whatever can be specified in web.xml should be specified there. Tomcat3.3 ( and 3.2 ) already removes another odity - the default web.xml that generated so many bugs and mess in 3.1. If you want your application to be portable, make sure it has all the information it needs in its web.xml - anything you put in apps-XXX.xml, server.xml, etc is specific to tomcat3.x and will be lost if you move your app to a different container.
