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?
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 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.
TC3.3b1: can't find action servlet on start-up
See the SAXEception. I'm not sure if this is a bug in Tomcat or from something not configured properly or maybe its normal behavior. Since I have only example war files from Tomcat and Struts loaded I don't even know where this action servlet is supposed to come from. I thought I would report it here just in case it is relevant to TC3.3 b1's code: Tomcat: setAttribute home=J:\webdev\tomcat33b1 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-127.0.0.1.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-admin.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-examples.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-strutsdoc.xml 2001-08-05 14:50:05 - AutoWebApp: Already loaded: DEFAULT:/admin 2001-08-05 14:50:05 - AutoWebApp: Already loaded: DEFAULT:/examples 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/perfproj1 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry1 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry2 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry3 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/ 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/struts-documentation 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/admin 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/examples 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/strutsdoc 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/perfproj1 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry1 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry2 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry3 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/ROOT 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/struts-documentation 2001-08-05 14:50:05 - LoadOnStartupInterceptor: cannot load servlet name: action - java.lang.No ClassDefFoundError: org/xml/sax/SAXException at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.apache.tomcat.facade.ServletHandler.getServlet(ServletHandler.java:348) at org.apache.tomcat.facade.ServletHandler.preInit(ServletHandler.java:402) at org.apache.tomcat.facade.ServletHandler.init(ServletHandler.java:227) at org.apache.tomcat.facade.LoadOnStartupInterceptor.contextInit(LoadOnStartupIntercept or.java:136) at org.apache.tomcat.core.Context.init(Context.java:501) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:588) at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:310) at org.apache.tomcat.startup.Tomcat.startTomcat(Tomcat.java:176) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:120) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) at org.apache.tomcat.startup.Main.execute(Main.java:305) at org.apache.tomcat.startup.Main.main(Main.java:191) 2001-08-05 14:50:05 - ContextManager: Init time 1132 2001-08-05 14:50:05 - Http10Interceptor: Starting on 8080 2001-08-05 14:50:05 - Ajp12Interceptor: Starting on 8007 2001-08-05 14:50:05 - Ajp13Interceptor: Starting on 8009 2001-08-05 14:50:05 - ContextManager: Startup 50
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/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: An alternative to JSP
Glenn, Speaking of which: Yes, we need a place where the various templating and tagging approaches that somehow involve Java can be discussed. A thread like this thread needs a logical place for it to take place and right now there doesn't seem to be one as each list or Usenet group seems too specific to particular approaches.. Well, it just so happens that over in comp.lang.java.programmer we've just had a couple of long discussions about the need to add some new Usenet comp.lang.java.* groups. If anyone here has a good idea for a group name or two that would relate Java to the various template and tag languages for developing HTML pages that have active content I'd like to hear about them. Our discussion has moved to private e-mail involving sime regular heavy posters on comp.lang.java.* groups and we are hashing out exactly what is going to be voted on. I'd like a place that is a logical place for the users of various competing technologies in this area (JSP, WebMacro, Velocity/Turbine, Cocoon, FreeMarker, etc) to talk about the sorts of things this thread just discussed. We are working on some formal proposal write-usp for some new Usenet groups. But one of the proposed group names is comp.lang.java.servlet+jsp and that just seems too narrow and with the wrong emphasis. Among the alternatives we've kicked around: comp.lang.java.html+template comp.lang.java.template+tag comp.lang.java.servlet+template comp.lang.java.template-tech comp.lang.java.web-tech Again, any suggestions welcome either here or in private e-mail. On Fri, 26 Jan 2001 11:44:17 -0600, Glenn Nielsen wrote: This list is for discussing issues related to developing the Tomcat servlet container, not design of web applications. Could this discussion get moved elsewhere? Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
Peter, Amazingly expensive. Calling from the US to Australia is incredibly cheap by comparison. Check out: http://1010phonerates.com/aus_etc.html As for the openness of the meetings, I have a few suggestions. This is the internet age. We are internet kinds of guys. How about using it: 1) Record the meetings for WAV or MPEG download afterward. Then people can go back and find out what decisions were made and why. 2) Have a live feed for those whose connections are high enough. Heck, even put in a camera or three and feed them live as well. 3) Allow people to use internet phone chat s/w to add their comments in some parts of the meeting set aside for remote participants. On Mon, 15 Jan 2001 13:42:36 +1100, Peter Donald wrote: $1000 for a couple hour phone call? I find that impossible to believe. What phone company are you using? Either $4 or $8 a minute from Melbourne, Australia during daytime using telstra (Australias main provider). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
