?? Yet Another Tomcat Documentation Bug ??
If you go here: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/host.html#Automatic%20Application%20Deployment The first bullet point starts out: Any XML file in the $CATALINA_HOME/conf/[engine_name]/[host_name] directory is assumed... I believe this should say, Any XML file in the $CATALINA_BASE/conf/[engine_name]/[host_name] directory is assumed... Is that right? It's another typo, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
?? Does META-INF/context.xml Work ??
All, I'm using TC 5.0.30. I'm looking at this quote regarding META-INF/context.xml from the TC docs (http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html): Instead, put them in the META-INF/context.xml directory of your WAR file or the conf directory as described above. These instruction, by my interpretation, are saying we can arrange a web application's directory structure like this: ROOT/ | | + WEB-INF/ + META-INF/ | | + context.xml Context.xml would then contain the Context element. Has anyone gotten this to work? When I arrange my directory structure as shown above it seems the Context.xml file is simply ignored. I'm not using a WAR file, this is just the directory structure. I hope someone can try this -- arrange your directory structure as shown above and make sure your context.xml is being processed. Mine is not. If I put the context.xml in $CATALINA_BASE/conf/[enginename]/[hostname]/, however, it is picked up just fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Yet Another Tomcat Documentation Bug ??
Yea, I know, I saw that note. It's in the Host element description but references to $CATALINA_HOME (which should be $CATALINA_BASE) are all over the place -- not just under Host documentation. What's more, a reader could easily think that the note you mentioned *only* referred to the Host element description since it says, The description below IMHO, instead of asking the reader to do a mental substitution I think the documentation should be updated s.t. it uses $CATALINA_BASE when $CATALINA_BASE is appropriate. This documentation anomaly has bothered me for a long time and I felt I needed to mention it. - Original Message - From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Monday, February 21, 2005 10:20 PM Subject: RE: ?? Yet Another Tomcat Documentation Bug ?? From: Tony LaPaso [mailto:[EMAIL PROTECTED] Subject: ?? Yet Another Tomcat Documentation Bug ?? The first bullet point starts out: Any XML file in the $CATALINA_HOME/conf/[engine_name]/[host_name] directory is assumed... I believe this should say, Any XML file in the $CATALINA_BASE/conf/[engine_name]/[host_name] directory is assumed... Is that right? It's another typo, right? There's a fairly prominent note at the introduction to the host element: The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 5, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 5 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FOLLOW-UP: Sharing the JSTL JARs and Classloading
Hi all, On Jan. 22 I posted a message to this group, ?? Sharing the JSTL JARS and Classloading ??, where I described a problem I was having with the JSTL JARs. It seemed that when I put the JSTL JARs (standard.jar and jstl.jar) in Tomcat's shared/lib TC could not find them, contrary to the TC documentation. I know what the problem was. It turns out it was my fault. I was using a value of CATALINA_BASE that was not the same as CATALINA_HOME. Tomcat's documentation says that Shared/lib is relative to CATALINA_BASE. So, I'm sorry to all you who read my post and tried to help me solve the problem. It was all my fault after all for not having read the Tomcat documentation well enough. I am sorry to those of you whose time I wasted. I'll be more careful in the future. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oracle JDBC
When you say, when I moved it to a context..., what exactly did you move? Did you move the JDBC JAR or just the web app? Did you delete the web-app from jsp-examples? This all goes back to the poor Tomcat documentation on classloading. This is interesting. Do you think you could show me the directory/JAR layouts before (when it worked) and after (when it didn't)? - Original Message - From: Nathan Aaron [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Thursday, January 27, 2005 10:31 AM Subject: Oracle JDBC I have the Oracle jdbc driver installed in Tomcat's shared/lib directory. I have a JSP file that resides in the webapps/jsp-examples that connects to an Oracle database successfully. When I move it to a context (/opt/application/appname) outside one of the contexts that are included with Tomcat 5.0.28 the jsp stops connecting to the database. I get java.sql.SQLException: No suitable driver like it can't load the JDBC driver. What is odd is that I have a servlet that connects to the database fine and it is in the /opt/application/appname/WEB-INF/lib directory. Any help would be greatly appreciated. Nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Mark, When you cleaned out the caches (by deleting the work directory) were you able to move the standard.jar and jstl.jar to shared/lib and then be able to use JSTL? I did that -- I deleted the 'work' directory and then moved the JARs from common/lib to shared/lib and re-started TC. Now I have the exception below. Is the JSP compiler not looking using shared/lib classloader, I wonder? org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:50) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:411) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:118) org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:316) org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:147) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:418) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:483) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1539) org.apache.jasper.compiler.Parser.parse(Parser.java:126) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:220) org.apache.jasper.compiler.ParserController.parse(ParserController.java:101) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203) org.apache.jasper.compiler.Compiler.compile(Compiler.java:495) org.apache.jasper.comp! iler.Compiler.compile(Compiler.java:476) org.apache.jasper.compiler.Compiler.compile(Compiler.java:464) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:511) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:295) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802)- Original Message -From: Mark Thomas [EMAIL PROTECTED]To: Tomcat Users List tomcat-user@jakarta.apache.orgSent: Sunday, January 23, 2005 9:21 AMSubject: Re: ?? Sharing the JSTL JARS and Classloading ?? Tony LaPaso wrote: Incidentally, in reading the Tomcat docs for Classloading, it seemsthat any classes in a web app's lib directory *should* be able to seeclasses in the shared/lib directory. Similarly, any classes inshared/lib *should* be able to see what's in common/lib. This works as you ! expect. I just tested it with a clean TC5 build fromCVS. That being sa id I noticed the following whilst I was testing which mayhelp: - I needed to clean out the work directory for my app between each test. - I needed to restart Tomcat for each test. If I didn't do both of the above then various caches (already loadedclasses, JSPs that have already been compiled, etc) all contributed to weirdresults. angry-rant The crappy, incomplete Tomcat documentation strikes again. One of the badthings about these open source projects is that since no one owns them noone has responsibility to work on anything except what they're interestedin. The result is often neglected, shoddy and incomplete documentation. /angry-rant You are as much of the Tomcat community as anyone else. If you knowsomewhere where the docs are wrong (which you must do to be able to callthem crappy and incomplete - and by implication neglected and shoddy) whynot redirect your energy from futile ranting into creating patches toimprove the documentation and contribute t! o the community. So, again, it seems weird that putting the JSTL JARs in common/libworks fine while putting them in shared/lib doesn't. When I put them inshared/lib I get the exception shown below. From the exception below itseems to me that the classes in common/lib (e.g.,javax.servlet.http.HttpServlet) do not have access to classes inshared/lib (e.g., org.apache.taglibs.standard.tag.rt.core.ForEachTag)although the classes in common/lib *DO* obviously have access to classesin a web app's lib directory. If only the classloader docs were better In terms of the hierarchy, the docs are right. Perhaps what needs to beadded is the circumstances where restarts (app or tomcat) are required forchanges to take effect. For the record, my own view is that the increased effort required tomanage shared jars is rarely worth the disk space and memory it saves. Mark - To unsubscribe, e-mai! l: [EMAIL PROTECTED] For additional commands , e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
- Original Message - From: Nikola Milutinovic [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Sunday, January 23, 2005 12:32 PM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? One other note - Tomcat gives you a framework contract, a contract defined by JSP/Servlet specification. There is no mention of JSTL in it. Thus, it is unwise to make it shared, since it involves making the JSTL more internal than external, from Tomcat's point of view. Nic, You are right: Tomcat provides a contract via it's implementation of the Servlet/JSP spec and the JSTL has absolutely nothing to do with it. Tomcat *also*, however, provides an alleged facilty (shared/lib) for the sharing of JAR file across web applications. This capability is independent of the Servlet/JSP specs but it is supposed to work with Tomcat. There's a more important issue at work here than whether or not I have to put the JARs in common/lib or shared/lib: When writing code it's considered a bad practice (and I think, rightfully so) to copy and paste the same code to various locations. Instead, we factor out common behavior into separate classes or methods. There's an analogous idea involved here -- instead of copying and pasting the same JARs across many web applications it makes more sense (to me, anyway), to factor out these JARs and make them centrally available. Having said that, I also realize the code within the JARs must be written such that the classes can be shared. Think of .so files or .DLL files. With .DLL files, for example, Windows will share the library's contents across several processes rather than load the same DLL each time for every process. I think this is a good strategy, again, assuming the classes in the JAR were written so as to be shared. It's not a matter of disk or memory space, per se, it's more a matter of administrative convenience. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
Call me a minimalist but I don't like the idea of having the same JAR file duplicated if I don't have to. It takes more memory since each web app's classloader needs to have the same classes in memory. It seems much cleaner to have the JARs in one central location. - Original Message - From: QM [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Saturday, January 22, 2005 8:57 AM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? On Sat, Jan 22, 2005 at 01:24:54AM -0600, Tony LaPaso wrote: : The problem is that I have several web applications that use JSTL and : therefore several WEB-INF/lib directories. Rather than copy the : aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put : them in one central location and have them available for *ALL* web : applications. Webapps are supposed to be self-contained, and as such, it's considered a best practice to pack up a webapp with all the JARs it needs. If it's a hassle to copy the JARs around by hand, why not fold that into an automated build process? -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Sharing the JSTL JARS and Classloading ??
You have some good points, Jake. Thank you for the response. If you happen to run across the statement from Craig M. regarding Struts I'd like to see it. Incidentally, in reading the Tomcat docs for Classloading, it seems that any classes in a web app's lib directory *should* be able to see classes in the shared/lib directory. Similarly, any classes in shared/lib *should* be able to see what's in common/lib. angry-rant The crappy, incomplete Tomcat documentation strikes again. One of the bad things about these open source projects is that since no one owns them no one has responsibility to work on anything except what they're interested in. The result is often neglected, shoddy and incomplete documentation. /angry-rant So, again, it seems weird that putting the JSTL JARs in common/lib works fine while putting them in shared/lib doesn't. When I put them in shared/lib I get the exception shown below. From the exception below it seems to me that the classes in common/lib (e.g., javax.servlet.http.HttpServlet) do not have access to classes in shared/lib (e.g., org.apache.taglibs.standard.tag.rt.core.ForEachTag) although the classes in common/lib *DO* obviously have access to classes in a web app's lib directory. If only the classloader docs were better exception javax.servlet.ServletException: org.apache.taglibs.standard.tag.rt.core.ForEachTag org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:846) org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779) org.apache.jsp.index_jsp._jspService(Unknown Source) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause java.lang.NoClassDefFoundError: org.apache.taglibs.standard.tag.rt.core.ForEachTag org.apache.jsp.index_jsp.class$(Unknown Source) org.apache.jsp.index_jsp._jspx_meth_c_forEach_0(Unknown Source) org.apache.jsp.index_jsp._jspService(Unknown Source) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) - Original Message - From: Jacob Kjome [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Saturday, January 22, 2005 10:30 AM Subject: Re: ?? Sharing the JSTL JARS and Classloading ?? Not all libraries are written in a way that allows for them to be used from different webapps. Struts has a statement on this written by Craig McClanahan, but I can't find it at the moment. The gist of it is that Struts (at least with 1.1) cannot be guaranteed to work properly if placed in a shared classloader. One example of where this might be problematic is with non-final static variables. If it they get changed by one app, the other app sees the change. Usually, this is not the desired behavior as it will make each app using the shared library behave in unpredictable ways. Anyhow, what error are you getting when you add the library to the shared classloader? I haven't looked at the classloader hierarchy in Tomcat for a little while, but it is possible that shared/lib cannot see common/lib, and if there are libraries that standard.jar and jstl.jar depend on libraries that exist in common/lib, then you might get the error you are seeing. Jake At 01:24 AM 1/22/2005 -0600, you wrote: Hi all, I'm using TC 5.0.30. JSTL Is working fine -- I have the standard.jar and jstl.jar files in my WEB-INF/lib directory. The problem is that I have several web applications that use JSTL and therefore several WEB-INF/lib directories. Rather than copy the aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put them in one central location and have them available for *ALL* web applications. According to the crappy Tomcat documentation that's never updated, I should be able to put the JARs in $CATALINA_HOME/shared/lib. Unfortunately, that doesn't seem to work with these two JARs for some reason. Instead, I have to put them in $CATALINA_HOME/common/lib (which seems to work, for some reason). Why can't I just put these two JARs in $CATALINA_HOME/shared/lib and have them shared across all web applications, as the Tomcat documentation on Classloading indicates I should be able to? It seems very odd that I can either copy the JARs to every WEB-INF/lib directory *OR*
?? Sharing the JSTL JARS and Classloading ??
Hi all, I'm using TC 5.0.30. JSTL Is working fine -- I have the standard.jar and jstl.jar files in my WEB-INF/lib directory. The problem is that I have several web applications that use JSTL and therefore several WEB-INF/lib directories. Rather than copy the aforementioned JAR files to *every* WEB-INF/lib directory I'd rather put them in one central location and have them available for *ALL* web applications. According to the crappy Tomcat documentation that's never updated, I should be able to put the JARs in $CATALINA_HOME/shared/lib. Unfortunately, that doesn't seem to work with these two JARs for some reason. Instead, I have to put them in $CATALINA_HOME/common/lib (which seems to work, for some reason). Why can't I just put these two JARs in $CATALINA_HOME/shared/lib and have them shared across all web applications, as the Tomcat documentation on Classloading indicates I should be able to? It seems very odd that I can either copy the JARs to every WEB-INF/lib directory *OR* put them in $CATALINA_HOME/common/lib, but not put them $CATALINA_HOME/shared/lib. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC 5.0.14 Breaks UTF-8 Content via HTTP Header
Hi everyone, It seems a change to TC v5.0.14 may have broken the serving of UTF-8 documents. Specifically, one of the HTTP headers seems wrong. I'd like to describe what I'm seeing TC v5.0.14 compared with v5.0.12. For both v5.0.12 and v5.0.14 I'm running TC as it comes out of the box i.e., with no changes to the default configurations. In both cases I tested with four browsers (IE 5, IE 6, Netscape 7.1 and Firebird 0.7), all on Win 2K. Here's What I Did - In both versions of TC, I added an em dash character to the /tomcat-docs/cgi-howto.html documents that come with the TC documentation. The UTF-8 representation for the em dash character is the three bytes 0xE28094. I also made sure both documents had the following META tag in its head: meta http-equiv='Content-Type' content='text/html; charset=utf-8'/ I then saved the documents as UTF-8 (without a BOM). Finally, I brought the document into a hex editor to check that the em dash was properly encoded as three bytes (which it was). This indicated to me that the document was indeed encoded as UTF-8. Here's What I Saw (TC v5.0.12) -- Under TC v5.0.12, everything looked great using all browsers -- the em dash was rendered correctly. I put a sniffer on the HTTP stream. The v5.0.12 Coyote Connector was sending this HTTP response header: Content-Type: text/html Here's What I Saw (TC v5.0.14) -- Under TC v5.0.14 the em dash character was rendered as *THREE SEPARATE CHARACTERs* (one for each byte). Moreover, putting a sniffer on the HTTP stream indicated the following response header was being sent by the v5.0.14 Coyote Connector: Content-Type: text/html;charset=ISO-8859-1 Aside - For the heck of it I re-saved the v5.0.14 UTF-8 document with a BOM (0xEFBBBF). Doing this made IE correctly render it but Netscape and Firebird still had problems. I'm pretty sure that Unicode says the BOM is optional anyway. Conclusion (?) -- It seems that v5.0.14 of the Coyote Connector is incorrectly sending the wrong response header. I'm not sure what the HTTP spec says *should* be sent for the header if the document's head contains: meta http-equiv='Content-Type' content='text/html; charset=utf-8'/ My guess is that either the response header in v5.0.14 needs to be changed to: Content-Type: text/html;charset=UTF-8 or possibly: Content-Type: text/html as it was with TC v5.0.12. Can anyone comment? Is this a TC v5.0.14 bug? It would seem to be. Thanks, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
$CATALINA_HOME/shared/lib is *STILL* Ignored....
Hi all, I posted a similar question a couple days ago but it seems the well-intended responses I received were incorrect. And let me first say that I have RTFMs -- more than once -- and this *SHOULD* work, at least according to TFMs. I'm using TC v5.0.9 on Linux with J2SE 1.4.2_01. Very simply, I have a Jar with some custom classes in $CATALINA_HOME/shared/lib/. These classes are not being found in my web application. Instead, I get a NoClassDefFoundError. If I move the Jar to $CATALINA_HOME/common/lib/, the classes are found with no problem. Somebody, please, just do what I described above and tell me if you can get classes to load from a jar in $CATALINA_HOME/shared/lib. According to the Tomcat docs, Jar files in $CATALINA_HOME/shared/lib/ *SHOULD BE AVAILABLE* to a web app. See the TC documentation at: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html I'm wondering if the TC docs are once again in error Thanks very much.sincerely. Tony - side-note Finally, for the sake of completeness, I'd like to correct something someone said in response to my previous post. A NoClassDefFoundError does *NOT* mean the class was found. It means the class was *NOT* found, as does ClassNotFoundException. The difference between these two errors has to do with the mechanism by which the class load operation was initiated. ClassNotFoundException is thrown when a class cannot be found and the programmer tried to load the class *explicitly* using Class.forName() or a ClassLoader method. For example: Class c = Class.forName(MyClass); NoClassDefFoundError is thrown when a class cannot be found and the programmer tried to load the class *implicitly* by referring to the class name. For example: MyClass x = new MyClass(); Both exceptions mean the class cannot be found. I am assuming that when Tomcat throws one of these two errors it is following the usage guidelines laid out in the javadocs for these errors. /side-note - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
$CATALINA_HOME/shared/lib is Ignored, Doc Grip
Hi all, I'm seeing behavior that seems contrary to the TC Documentation (seems to happen a lot). I'm running TC 5.0.9 on Win 2k, J2SDK 1.4.2_01. I have some JAR files (for JavaMail) in the $CATALINA_HOME/shared/lib directory. I expect my web app will be able to use classes out of these JARs with no problem. Unfortunately, I get a NoClassDefFoundError when refering to classes in these JARs. If I move the JAR files to the $CATALINA_HOME/common/lib directory, however, the classes are found with no problem. According the (often innacurate) Tomcat documention, the $CATALINA_HOME/shared/lib should be searched. See: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html Does anyone have an explanation for why $CATALINA_HOME/shared/lib is not being searched? And just what the heck is the difference between $CATALINA_HOME/shared/lib vs. $CATALINA_HOME/common/lib?? angry-gripe The TC documentation refers to a directory, $CATALINA_HOME/lib and says that the following JARs are located there: jasper-compiler.jar, jasper-runtime.jar and naming-factory.jar. This is just another example of the shoddy TC documentation. These JAR files are all located in $CATALINA_HOME/common/lib. In fact, $CATALINA_HOME/lib doesn't even exist! /angry-gripe Thanks! Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best Tomcat Book, Recommendations??? PART 2
First, as I said, my comment about the Wrox books was a generalization. There's nothing illogical about making generalizations. The Wrox books I've seen were pure garbage. When I'm at the bookstore now I don't even bother to browse those big red books, knowing my effort will probably be a waste of time. I usually stick with O'Reilly and Manning. Perhaps Wrox's quality has improved and I should browse them again. As for what I'm looking for -- basically, Tomcat Admin. There are other books that teach servlets/JSPs/JSTL/XML, etc. I'm interested in all aspects of using TC from an admin's point of view and from a programmer's point of view. I guess that's another generalization. :) Specifically, setting up TC, using it w/Apache and IIS, TC Security, clustering TC servers, setting up JNDI resources. I suspect any good TC book will have a good deal of overlap w/the servlet spec v2.4 which is fine. I know several books cover these topics (and others) but as I said, I was hoping to get some recommendations on the best ones. Perhaps the Wrox one is the best. Thanks very much for all the input. I really appreciate everyone taking the time to write. Tony - Original Message - From: John Turner [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 7:28 AM Subject: Re: Best Tomcat Book, Recommendations??? PART 2 What, exactly is it that you want to know? You say I want a Tomcat book but then you say I don't want anything about servlets. So what is it you want? An admin reference (the Wrox book is focused that way)? A performance tuning book? People can't answer you or help you unless you are specific! Do you have specific questions? Have you asked them here or on tomcat-dev? Why wait for a book? You have access to the people who are actually writing Tomcat and using Tomcat in heavy-duty production situations right here, right now. John Tony LaPaso wrote: Sorry, but I forgot to mention: I'm really only interested in Tomcat specifically, not how to program servlets/JSPs. Some of the TC books I've seen like to make themselves nice and plump by describing servlet programming, what HTTP is, what XML is, etc., etc. I don't need that extra fat. Thanks again... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best Tomcat Book, Recommendations???
Hi all, Can some of you recommend a good Tomcat book? In the archives I've read that the Wrox book, Professional Apache Tomcat, is pretty good but my overall impression of Wrox books is that they're generally not worth the paper they're printed on. I know O'Reilly has a relatively new TC book that looks pretty good. I was also hoping to find something that covered TC 5, although this is a nice to have. Any suggestions? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best Tomcat Book, Recommendations??? PART 2
Sorry, but I forgot to mention: I'm really only interested in Tomcat specifically, not how to program servlets/JSPs. Some of the TC books I've seen like to make themselves nice and plump by describing servlet programming, what HTTP is, what XML is, etc., etc. I don't need that extra fat. Thanks again... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Simple Newbie Question about Root Context ??
Well, it sounds like a guess... - Original Message - From: Micael [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, March 31, 2003 12:33 AM Subject: Re: ?? Simple Newbie Question about Root Context ?? The reason has to be, then, that the startup of the webapp creates a default context on its own, because it cannot happen magically. I hope that does not sound smart-alexey but, rather, clear. At 08:14 PM 3/30/03 -0600, you wrote: But my point is that everything works fine even *with* the comment. THAT is what's confusing. - Original Message - From: Carol Carrick [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 4:20 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? The website I sent tells you to take the comments out. - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 5:01 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? Well, I don't have to create pages under ROOT as you did, but that's a separate issue from what I'm asking. - Original Message - From: Carol Carrick [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 3:50 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? Although I am really a newbie, I have the same o/s system. I have trouble loading my pages until I created them under the ROOT path and uncommented the section you are referring to. Here is a good web reference. http://www.moreservlets.com/Using-Tomcat-4.html - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: Tomcat User [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 4:00 PM Subject: ?? Simple Newbie Question about Root Context ?? My Tomcat skills are rusty -- I must be missing something easy here. I just installed TC v4.1.24 on Win 2k. The installation worked right out of the box. I didn't have to make any changes to the server.xml. TC is up and running but I'm seeing something strange I was hoping someone could explain: Here's a quote from the TC documentation: ...you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Okay, that's fine, but when I look at conf/server.xml I see this: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- Why is this commented out? According to the documentation there must be a context path equal to a zero-length string. The quote I cited seems to contradict what I'm seeing in server.xml. Even though this is commented out everything seems to work fine. In other words, if I browse to localhost:8080 I do indeed see webapps/ROOT/index.jsp. Is the docBase named ROOT the default? If so, then the documentation should mention that I think. Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you
?? Trying Again: Newbie Question about Root Context ??
Hi all, I posted this question over the weekend but nobody really seemed to know the answer. Several people speculated but nobody knew. Altough I'm sincerely hoping for an answer, please, if you don't know for sure, don't guess. :) I just installed TC v4.1.24 on Win 2k. The installation worked right out of the box. I didn't have to make any changes to the server.xml. TC is up and running just fine but I'm seeing something strange I was hoping someone could explain: Here's a quote from the TC documentation: ...you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Okay, that's fine, but when I look at conf/server.xml I see this: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- Why is this commented out? According to the documentation cited above there must be a context path equal to a zero-length string. The quote I cited seems to contradict what I'm seeing in server.xml. As I said, even though this is commented out everything seems to work fine. In other words, if I browse to localhost:8080 TC does indeed serve up webapps/ROOT/index.jsp. Is the docBase named ROOT the default? If so, then the documentation seems out of date. I believe in past versions of TC it was definitely necessary to have a context path equal to a zero-length string. If anybody knows (for sure), I would really appreciate an explanation. Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Trying Again: Newbie Question about Root Context ??
Here it is, straight from tomcat-4.1.24-LE-jdk14.zip - Original Message - From: Kwok Peng Tuck [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, March 31, 2003 9:07 PM Subject: Re: ?? Trying Again: Newbie Question about Root Context ?? Send a copy of your server.xml file, I don't see that commented out in mine. I'm pretty sure it isn't though. Tony LaPaso wrote: Hi all, I posted this question over the weekend but nobody really seemed to know the answer. Several people speculated but nobody knew. Altough I'm sincerely hoping for an answer, please, if you don't know for sure, don't guess. :) I just installed TC v4.1.24 on Win 2k. The installation worked right out of the box. I didn't have to make any changes to the server.xml. TC is up and running just fine but I'm seeing something strange I was hoping someone could explain: Here's a quote from the TC documentation: ...you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Okay, that's fine, but when I look at conf/server.xml I see this: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- Why is this commented out? According to the documentation cited above there must be a context path equal to a zero-length string. The quote I cited seems to contradict what I'm seeing in server.xml. As I said, even though this is commented out everything seems to work fine. In other words, if I browse to localhost:8080 TC does indeed serve up webapps/ROOT/index.jsp. Is the docBase named ROOT the default? If so, then the documentation seems out of date. I believe in past versions of TC it was definitely necessary to have a context path equal to a zero-length string. If anybody knows (for sure), I would really appreciate an explanation. Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !-- Example Server Configuration File -- !-- Note that component elements are nested corresponding to their parent-child relationships with each other -- !-- A Server is a singleton element that represents the entire JVM, which may contain one or more Service instances. The Server listens for a shutdown command on the indicated port. Note: A Server is not itself a Container, so you may not define subcomponents such as Valves or Loggers at this level. -- Server port=8005 shutdown=SHUTDOWN debug=0 !-- Comment these entries out to disable JMX MBeans support -- !-- You may also configure custom components (e.g. Valves/Realms) by including your own mbean-descriptor file(s), and setting the descriptors attribute to point to a ';' seperated list of paths (in the ClassLoader sense) of files to add to the default list. e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml -- Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ !-- Global JNDI resources -- GlobalNamingResources !-- Test entry for demonstration purposes -- Environment name=simpleValue type=java.lang.Integer value=30/ !-- Editable user database that can also be used by UserDatabaseRealm to authenticate users -- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved /Resource ResourceParams name=UserDatabase parameter namefactory/name valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value /parameter parameter namepathname/name valueconf/tomcat-users.xml/value /parameter /ResourceParams /GlobalNamingResources !-- A Service is a collection of one or more Connectors that share a single Container (and therefore the web applications visible within that Container). Normally, that Container is an Engine, but this is not required. Note: A Service is not itself a Container, so you may not define subcomponents such as Valves or Loggers at this level. -- !-- Define the Tomcat Stand-Alone Service -- Service name=Tomcat-Standalone !-- A Connector represents an endpoint by which requests are received and responses are returned. Each Connector passes requests on to the associated Container (normally an Engine) for processing. By default
?? Simple Newbie Question about Root Context ??
My Tomcat skills are rusty -- I must be missing something easy here. I just installed TC v4.1.24 on Win 2k. The installation worked right out of the box. I didn't have to make any changes to the server.xml. TC is up and running but I'm seeing something strange I was hoping someone could explain: Here's a quote from the TC documentation: ...you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Okay, that's fine, but when I look at conf/server.xml I see this: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- Why is this commented out? According to the documentation there must be a context path equal to a zero-length string. The quote I cited seems to contradict what I'm seeing in server.xml. Even though this is commented out everything seems to work fine. In other words, if I browse to localhost:8080 I do indeed see webapps/ROOT/index.jsp. Is the docBase named ROOT the default? If so, then the documentation should mention that I think. Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Simple Newbie Question about Root Context ??
Well, I don't have to create pages under ROOT as you did, but that's a separate issue from what I'm asking. - Original Message - From: Carol Carrick [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 3:50 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? Although I am really a newbie, I have the same o/s system. I have trouble loading my pages until I created them under the ROOT path and uncommented the section you are referring to. Here is a good web reference. http://www.moreservlets.com/Using-Tomcat-4.html - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: Tomcat User [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 4:00 PM Subject: ?? Simple Newbie Question about Root Context ?? My Tomcat skills are rusty -- I must be missing something easy here. I just installed TC v4.1.24 on Win 2k. The installation worked right out of the box. I didn't have to make any changes to the server.xml. TC is up and running but I'm seeing something strange I was hoping someone could explain: Here's a quote from the TC documentation: ...you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Okay, that's fine, but when I look at conf/server.xml I see this: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- Why is this commented out? According to the documentation there must be a context path equal to a zero-length string. The quote I cited seems to contradict what I'm seeing in server.xml. Even though this is commented out everything seems to work fine. In other words, if I browse to localhost:8080 I do indeed see webapps/ROOT/index.jsp. Is the docBase named ROOT the default? If so, then the documentation should mention that I think. Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ?? Simple Newbie Question about Root Context ??
But my point is that everything works fine even *with* the comment. THAT is what's confusing. - Original Message - From: Carol Carrick [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 4:20 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? The website I sent tells you to take the comments out. - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 5:01 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? Well, I don't have to create pages under ROOT as you did, but that's a separate issue from what I'm asking. - Original Message - From: Carol Carrick [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 3:50 PM Subject: Re: ?? Simple Newbie Question about Root Context ?? Although I am really a newbie, I have the same o/s system. I have trouble loading my pages until I created them under the ROOT path and uncommented the section you are referring to. Here is a good web reference. http://www.moreservlets.com/Using-Tomcat-4.html - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: Tomcat User [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 4:00 PM Subject: ?? Simple Newbie Question about Root Context ?? My Tomcat skills are rusty -- I must be missing something easy here. I just installed TC v4.1.24 on Win 2k. The installation worked right out of the box. I didn't have to make any changes to the server.xml. TC is up and running but I'm seeing something strange I was hoping someone could explain: Here's a quote from the TC documentation: ...you MUST define a Context with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Okay, that's fine, but when I look at conf/server.xml I see this: !-- Tomcat Root Context -- !-- Context path= docBase=ROOT debug=0/ -- Why is this commented out? According to the documentation there must be a context path equal to a zero-length string. The quote I cited seems to contradict what I'm seeing in server.xml. Even though this is commented out everything seems to work fine. In other words, if I browse to localhost:8080 I do indeed see webapps/ROOT/index.jsp. Is the docBase named ROOT the default? If so, then the documentation should mention that I think. Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
?? Can Taglib JARs be Global ??
Hi, I've found something curious and was wondering if anyone had an explanation or comment. I'm using Tomcat v4.1.12 but this also happens on TC v4.1.16 beta. Here's the situation: I have several Taglib JARs that I would like to make available to *all* web applications (i.e., all contexts). In other words, I do *not* want to have separate copies of each and every JAR in each web app's /WEB-INF/lib directory. I'd rather just put the JARs in Tomcat's common/lib directory. What I'm finding is that if I pre-compile my JSPs, I *can* have only one set of JARs in common/lib, just as I want. On the other hand, if my JSPs are compiled on request (i.e., they are not pre-compiled), then the JARs *must* be in the /WEB-INF/lib directory for the particular web app. Is this correct behavior? I wonder if it's a limitation of the JSP compiler and if so, should it be fixed? Any comments?? Thanks, Tony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
TC Takes Several Minutes to Start
Hi All, I'm running TC 4.1.12 on Win 2k. For some reason, starting TC takes about 2-3 minutes and during this entire time my CPU is pinned at 100%. It never used to take this long. I recently used the TC Administration Tool and I am wondering if maybe I changed something that caused to long start-up delay. Any ideas? Thanks. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Logging to console not working with Tomcat 4.1.9
So you mean output to System.out System.err? As of 4.1.9 that's been changed to go to a log file. - Original Message - From: Michael [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 9:20 AM Subject: BUG: Logging to console not working with Tomcat 4.1.9 I uninstalled 4.1.9 and installed 4.0.4. When I start tomcat I get pages and pages of debug log messages on the console from the apache tools I'm using (Struts, messenger, etc.) and my own classes. I uninstalled 4.0.4 and installed 4.1.9 and when I run it I only get 4 lines. I haven't changed anything in my code or the tomcat directory. So I'm 100% positive something is broken in 4.1.9 regarding outputing messages to the console. For now I've switched back to 4.0.4 and logging to the console is working just fine. I filed a bug on Bugzilla, I'll post any responses I get to the mailing list. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12113 Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging to console not working with Tomcat 4.1.9
Well, honestly, I don't know about log4j. I know that prior to v4.1.9 I would use System.out/err to do light logging to the console and as of v4.1.9 it quit working. I'm not sure if System.out/err are routed to log4j. sorry... - Original Message - From: Michael [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 9:47 AM Subject: RE : Logging to console not working with Tomcat 4.1.9 No I mean log4j's ConsoleAppender. So are you saying that Tomcat now routes the log4j ConsoleAppender to a logfile as well? If so I think that's a big problem for debugging. While running my app in the IDE I want to see all the console output without having to switch to a text editor and reload the log file. Can I configure Tomcat 4.1.9 to do this?? Michael -Original Message- From: Tony LaPaso [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 4:38 PM To: Tomcat Users List Subject: Re: Logging to console not working with Tomcat 4.1.9 So you mean output to System.out System.err? As of 4.1.9 that's been changed to go to a log file. - Original Message - From: Michael [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 9:20 AM Subject: BUG: Logging to console not working with Tomcat 4.1.9 I uninstalled 4.1.9 and installed 4.0.4. When I start tomcat I get pages and pages of debug log messages on the console from the apache tools I'm using (Struts, messenger, etc.) and my own classes. I uninstalled 4.0.4 and installed 4.1.9 and when I run it I only get 4 lines. I haven't changed anything in my code or the tomcat directory. So I'm 100% positive something is broken in 4.1.9 regarding outputing messages to the console. For now I've switched back to 4.0.4 and logging to the console is working just fine. I filed a bug on Bugzilla, I'll post any responses I get to the mailing list. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12113 Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
TC is Returning Stale Content
Hi all,
This has nothing to do w/servlets or browsers but simply with
Tomcat. I'm wondering if it might be a bug in the way Tomcat
performs caching or handles HTTP headers. I'm using Tomcat v4.1.9
with JDK v1.4.1 on Win 2k.
This is a very simple situation. I have a Java client program
(see code below) that performs the following steps:
1. Writes a file to a web context directory.
2. Uses a URLConnection to request the file in #1.
3. Sleeps for a few seconds.
4. Overwrites the file in #1 with a new contents.
5. Uses a URLConnection to request the file in #1.
In step 5, I find that Tomcat is returning the contents of the
file that was written in step 1 -- BUT ONLY IF THE SLEEP TIME IS
LESS THAN 5 SECONDS. If I sleep for 5 or more seconds, then the
contents returned in step 5 is that which was written in step 4,
which is what I would expect.
The problem then is that Tomcat returns stale content if the
sleep time is less than 5 seconds. Why?!!
The code below includes the full client that connects to Tomcat.
Notice the Cache-Control header is set to max-age=0 which
should eliminate any caching on Tomcat. Just for grins,
Pragma:no-cache is used too. Since I'm connecting directly to
Tomcat (i.e., localhost) there is no proxy involved. I've checked
the HTTP headers using a sniffer and they look fine.
Here is the client codeIf you run this make sure you are
writing the file to the same directory from which TC will serve
it (obviously).
Thanks,
Tony
import java.io.*;
import java.net.*;
public class TestURL {
public static void writeToFile (String filename, String text)
throws IOException {
FileWriter fw = new FileWriter(filename);
PrintWriter pw = new PrintWriter(fw);
pw.print(text);
pw.close();
System.out.println (writeToFile() wrote: + filename);
System.out.println (writeToFile() text: + ' + text +
');
System.out.println (---);
} // writeToFile()
public static String readURL (String url)
throws IOException, MalformedURLException {
StringBuffer sb = new StringBuffer();
URL srcurl = new URL(url);
URLConnection urlc = srcurl.openConnection();
urlc.setDoInput(true);
urlc.setUseCaches(false);
urlc.setDefaultUseCaches(false);
urlc.setRequestProperty(Cache-Control, max-age=0);
urlc.setRequestProperty(Cache-Control, no-cache);
urlc.setRequestProperty(Cache-Control, no-store);
urlc.setRequestProperty(Pragma, no-cache);
InputStream is = urlc.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
char[] buffer = new char[100];
int charCount = 0;
while((charCount = isr.read(buffer, 0, buffer.length)) != -1)
sb.append(buffer, 0, charCount);
isr.close();
System.out.println (readURL() read: + url);
System.out.println (readURL() text: + ' + sb.toString()
+ ');
System.out.println (---);
return sb.toString();
} // readURL()
public static void main (String[] args)
throws Exception {
int sleepTime = 5;
if (args.length = 1)
sleepTime = Integer.parseInt (args[0]);
System.out.println (- TOMCAT TEST -);
String basedir =
C:\\Development\\Projects\\Tester\\Servlets\\web\\junk\\;
String baseurl = http://localhost/t/junk/;;
String testfile = testurl.txt;
String first = The first text;
String second = The second text;
String filepath = basedir + testfile;
String fileurl = baseurl + testfile;
writeToFile(filepath, first);
String s1 = readURL(fileurl);
System.out.println (Sleeping + sleepTime + seconds...);
Thread.sleep(sleepTime * 1000);
writeToFile(filepath, second);
String s2 = readURL(fileurl);
if(s2.equals(second))
System.out.println(The second file was properly served.);
else
System.out.println(The second file was *NOT* properly
served.);
} // main()
} // TestURL()
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
?? Tomcat and System.out ??
Hello all, I'm using TC 4.1.9 on Win 2k. I know in the past (earlier versions of TC) I could send output to System.out and/or System.err and it would show up in the console window where TC was running. It seems this output is either being ignored now or perhaps being buffered. Is there a way (in TC 4.1.9) to get System.out data to appear in the console? Thanks very much... Tony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ?? Tomcat and System.out ??
YEP! Thanks! - Original Message - From: Ekkehard Gentz [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, August 19, 2002 4:53 PM Subject: RE: ?? Tomcat and System.out ?? hi tony, look into your tomcat/logs folder there you'll find your system.out you can configure this in the server.xml look at..Logger className=org.apache.catalina.logger.FileLogger Ekkehard -Original Message- From: Tony LaPaso [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 10:07 PM To: Tomcat User Subject: ?? Tomcat and System.out ?? Hello all, I'm using TC 4.1.9 on Win 2k. I know in the past (earlier versions of TC) I could send output to System.out and/or System.err and it would show up in the console window where TC was running. It seems this output is either being ignored now or perhaps being buffered. Is there a way (in TC 4.1.9) to get System.out data to appear in the console? Thanks very much... Tony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
?? JSP and request.getPathInfo() in Tomcat ??
Hi all, I was hoping someone could explain something. I'm not sure if this is a Tomcat issue or a JSP issue. I'm using Tomcat v4.1.8 on Win 2k. It seems I cannot obtain the extra path information at the end of a URL from within a JSP. But, if I run the servlet that was generated from the JSP, I *can* get the extra path information with no problem. For example, below is a simple JSP (named Test.jsp) which I invoke using the URL below. Notice /extra/path/info is the extra path information at the end of the URL: http://localhost/t/Test.jsp/extra/path/info: htmlheadtitleTest/title/head body p This is a test... %= Path Info: + request.getPathInfo() % /p /body/html When I run this JSP it produces the output: This is a test... Path Info: null Notice the request.getPathInfo() is returning null. Now, if I take the generated servlet class file and place it in my WEB-INF/classes directory, and I run the servlet with this URL: http://localhost/t/servlet/org.apache.jsp.Test_jsp/extra/path/inf o I get this output: This is a test... Path Info: /extra/path/info So, why can a JSP not have access to the extra path information? Is this a Tomcat configuration issue or something else? Thanks... Tony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
?? JSP and request.getPathInfo() in Tomcat ??
Hi all, I was hoping someone could explain something. I'm not sure if this is a Tomcat issue or a JSP issue. I'm using Tomcat v4.1.8 on Win 2k. It seems I cannot obtain the extra path information at the end of a URL from within a JSP. But, if I run the servlet that was generated from the JSP, I *can* get the extra path information with no problem. For example, below is a simple JSP (named Test.jsp) which I invoke using the URL below. Notice /extra/path/info is the extra path information at the end of the URL: http://localhost/t/Test.jsp/extra/path/info: htmlheadtitleTest/title/head body p This is a test... %= Path Info: + request.getPathInfo() % /p /body/html When I run this JSP it produces the output: This is a test... Path Info: null Notice the request.getPathInfo() is returning null. Now, if I take the generated servlet class file and place it in my WEB-INF/classes directory, and I run the servlet with this URL: http://localhost/t/servlet/org.apache.jsp.Test_jsp/extra/path/inf o I get this output: This is a test... Path Info: /extra/path/info So, why can a JSP not have access to the extra path information? Is this a Tomcat configuration issue or something else? Thanks... Tony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
??? Bug in Tomcat Response Headers ???
Hello all, I posted this a few days ago but received no responseIf someone intimately familiar with Tomcat internals (liek Craig M.) could comment I'd appreciate it. I'm not 100% sure about this but I think I found a problem with the way Tomcat encodes characters. First I'll explain what I think the problem is and then I'll say why I think it's a problem. Please keep in mind that I'm not looking for alternative solutions (i.e., please don't tell me to use UTF-8). I want to stay focused on the problem. The behavior I'm seeing is not correct, IMHO. Assume I have these three lines of code in my doGet(): response.setContentType(text/html;charset=UTF-16); PrintWriter pw = response.getWriter(); pw.print(htmlheadtitleTest/title + /headbody/body/html); The PrintWriter returned from response.getWriter() will encode all characters as UTF-16. This means that all the response body (i.e., the HTML) gets encoded as UTF-16 before being sent to the client. So far, so good. Here's the problem: The reponse headers generated from the servlet *ALSO* get encoded as UTF-16, which, I believe is in violation of the HTTP spec. In reading the HTTP spec, response headers should be encoded as US-ASCII. So, it seems that Tomcat (or perhaps the Servlet API implementation) needs to be modified so that the response headers are *always* encoded as US-ASCII, regardless of the encoding for the response body. Again, please do not offer ways around this or ask me why I'm sending UTF-16 encoded characters. I know UTF-8 can be used but that's not the point. Is this a bug or am I buggy? Thanks, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
??? Tomcat Bug? -- Throws NullPointerException ???
Hello,
I was hoping somebody could run this on a non-Tomcat server. I've
used TC v4.0.4 and v4.1.7 and both result in NPEs being thrown
when I call getServletContext() from within the readObject()
method of an inner class. Below is a very simple servlet that
shows the problem.
As you can see, the init() method is able to call
getServletContext() with no problem. BUT, when init() tries to
de-serialize an object which is an inner class, the object's
readObject() method cannot call getServletContext().
I'm not looking for work-arounds -- I just want to know if this
is a Tomcat bug.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(text/html);
PrintWriter out = response.getWriter();
out.write(htmlheadtitleHello/title/headbody);
out.println(Hello there/body/html);
} // doGet()
private class Inner implements Serializable {
private Inner() {}
private void readObject(ObjectInputStream ois)
throws Exception {
System.out.println(In Inner.readObject()...);
ois.defaultReadObject();
System.out.println(defaultReadObject completed...);
ServletContext sc = getServletContext(); // BOOM!!
System.out.println(Got the servlet context!!!);
} // readObject()
} // Inner
public void init() {
try {
System.out.println(The servlet context is: +
getServletContext());
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(new Inner());
oos.close();
// Now, deserialize it
ObjectInputStream ois = new ObjectInputStream(new
ByteArrayInputStream(baos.toByteArray()));
Inner inner = (Inner)ois.readObject();
System.out.println(Got the inner object...);
} catch(IOException e) {
System.err.println(Got an exception in init()... + e);
e.printStackTrace();
} catch(ClassNotFoundException e) {
System.err.println(Got an exception in init()... + e);
e.printStackTrace();
}
} // init()
} // HelloWorld
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ??? Tomcat Bug? -- Throws NullPointerException ???
Actually, you are wrong but your comments helped me find the general cause of the problem...it is not a bug in Tomcat...comments below - Original Message - From: Jacob Kjome [EMAIL PROTECTED] Just because you are creating an inner class within a servlet does not mean that that inner class now gets access to the ServletConfig. Yes, I should have access to it -- inner classes have access to their parent's fields. In this case my inner class *should* have complete access to the ServletConfig object stored in GenericServlet. By the time my init() is called, the ServletConfig object has already beens set by GenericServlet.init(ServletConfig config). The problem is that the ServletConfig object in GenericServlet is transient. When I serialize the Inner object the following objects get serialized as well: 1. My Servlet 2. GenericServlet (contains the transient ServletConfig object) I have more investigation to do -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
READ FIRST ??? Tomcat Bug? -- Throws NullPointerException ??? READ FIRST
Hi all,
You can disregard my message about Tomcat -- it's not a Tomcat
issue. It's a subtle serialization issue
Thnaks
- Original Message -
From: Tony LaPaso [EMAIL PROTECTED]
To: Tomcat User [EMAIL PROTECTED]
Sent: Wednesday, July 17, 2002 7:53 PM
Subject: ??? Tomcat Bug? -- Throws NullPointerException ???
Hello,
I was hoping somebody could run this on a non-Tomcat server.
I've
used TC v4.0.4 and v4.1.7 and both result in NPEs being thrown
when I call getServletContext() from within the readObject()
method of an inner class. Below is a very simple servlet that
shows the problem.
As you can see, the init() method is able to call
getServletContext() with no problem. BUT, when init() tries to
de-serialize an object which is an inner class, the object's
readObject() method cannot call getServletContext().
I'm not looking for work-arounds -- I just want to know if
this
is a Tomcat bug.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(text/html);
PrintWriter out = response.getWriter();
out.write(htmlheadtitleHello/title/headbody);
out.println(Hello there/body/html);
} // doGet()
private class Inner implements Serializable {
private Inner() {}
private void readObject(ObjectInputStream ois)
throws Exception {
System.out.println(In Inner.readObject()...);
ois.defaultReadObject();
System.out.println(defaultReadObject completed...);
ServletContext sc = getServletContext(); // BOOM!!
System.out.println(Got the servlet context!!!);
} // readObject()
} // Inner
public void init() {
try {
System.out.println(The servlet context is: +
getServletContext());
ByteArrayOutputStream baos = new
ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(new Inner());
oos.close();
// Now, deserialize it
ObjectInputStream ois = new ObjectInputStream(new
ByteArrayInputStream(baos.toByteArray()));
Inner inner = (Inner)ois.readObject();
System.out.println(Got the inner object...);
} catch(IOException e) {
System.err.println(Got an exception in init()... +
e);
e.printStackTrace();
} catch(ClassNotFoundException e) {
System.err.println(Got an exception in init()... +
e);
e.printStackTrace();
}
} // init()
} // HelloWorld
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
??? Using JSPs to Send Not-Modified-Since Header ???
Hi all,
In looking at past posts, I'm afraid I know the horrible answer
to this issue but I thought I'd ask just in case I missed
anything.
Let me start by saying I'm using Tomcat v4.0.4 beta 3.
As you know, when a client (usually a web browser) has a cached
version of a resource (usually a web page) it can send an
If-Modified-Since header to the HTTP server. The server
compares the time/date stamp specified in the header with that of
the requested resource. If the resource has *not* been modified
since the time specified in the If-Modified-Since header, the
server sends back a 304 (Not-Modified) response, effectively
telling the client (usually a web browser) that its cached
version of the resource is still valid.
When writing a servlet, it's easy to handle this sort of
scenario. The javax.servlet.http.HttpServlet class has a
service() method. This method first checks if the incoming HTTP
method is a GET. If it is, the service() method proceeds to
call the getLastModified() method of the servlet. As a
developer, you can override getLastModified() to return a long
value representing the last time the requested resource was
changed. Depending on the value returned by getLastModified()
(note that -1 is returned if you don't override the method) the
service() method may simply return a 304, Not-Modified response
rather than calling the servlet's doGet() method.
Now, the $18.32 Question: How do you ensure getLastModified()
is called in JSP?
No, you cannot simply do this:
%!
public long getLastModified() {
return xxx;
}
%
The problem is that the above method will never be called by the
container.
I traced through some of the Tomcat/Catalina/Jasper code and it
seems to me that the response code is being set to 200/OK very
early on in the processing.
I also took a cursory look at the JSP spec and didn't find any
indication of setting a Not-Modified response code...so, I am
thinking this is something that is (strangely) missing in the JSP
specification. I have a JSP page that needs to update itself once
per day. Therefore, it would be very handy to have the
getLastModified() functionality enjoyed by servlet writers.
Can anyone confirm this?
Thanks...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ??? Using JSPs to Send Not-Modified-Since Header ???
Yes, but I'd prefer not to muck w/HttpJspBase -- as you said, it
is Tomcat specific.
I was hoping ther would be a more portable, approved
way...but it looks like the JSP spec does not yet support it.
Really too bad -- getLastModified() was a big win.
- Original Message -
From: Carlos Ferreira [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday, June 04, 2002 10:33 AM
Subject: Re: ??? Using JSPs to Send Not-Modified-Since Header ???
a not so good solution would be to subclass
org.apache.jasper.runtime.HttpJspBase ( or redesign it ) with
your
required behaviour and extend your jsp pages from this new
class.
the problem is that HttpJspBase is tomcat specific. perhaps
somebody has a
better idea.
Carlos Ferreira
Gilem Informatique
Hi all,
In looking at past posts, I'm afraid I know the horrible
answer
to this issue but I thought I'd ask just in case I missed
anything.
Let me start by saying I'm using Tomcat v4.0.4 beta 3.
As you know, when a client (usually a web browser) has a
cached
version of a resource (usually a web page) it can send an
If-Modified-Since header to the HTTP server. The server
compares the time/date stamp specified in the header with
that of
the requested resource. If the resource has *not* been
modified
since the time specified in the If-Modified-Since header,
the
server sends back a 304 (Not-Modified) response, effectively
telling the client (usually a web browser) that its cached
version of the resource is still valid.
When writing a servlet, it's easy to handle this sort of
scenario. The javax.servlet.http.HttpServlet class has a
service() method. This method first checks if the incoming
HTTP
method is a GET. If it is, the service() method proceeds to
call the getLastModified() method of the servlet. As a
developer, you can override getLastModified() to return a
long
value representing the last time the requested resource was
changed. Depending on the value returned by
getLastModified()
(note that -1 is returned if you don't override the method)
the
service() method may simply return a 304, Not-Modified
response
rather than calling the servlet's doGet() method.
Now, the $18.32 Question: How do you ensure
getLastModified()
is called in JSP?
No, you cannot simply do this:
%!
public long getLastModified() {
return xxx;
}
%
The problem is that the above method will never be called by
the
container.
I traced through some of the Tomcat/Catalina/Jasper code and
it
seems to me that the response code is being set to 200/OK
very
early on in the processing.
I also took a cursory look at the JSP spec and didn't find
any
indication of setting a Not-Modified response code...so, I
am
thinking this is something that is (strangely) missing in the
JSP
specification. I have a JSP page that needs to update itself
once
per day. Therefore, it would be very handy to have the
getLastModified() functionality enjoyed by servlet writers.
Can anyone confirm this?
Thanks...
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED] For
additional
commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ??? Using JSPs to Send Not-Modified-Since Header ???
Well, simply inserting a getLastModified() method into the generated
servlet will not work due to the class inheritance involved.
With standard (non-JSP generated) servlets, the service() method in
HttpServlet calls getLastModified(). With JSP-based servlets,
HttpServlet's service() method has been overriden by Tomcat (i.e.,
Catalina stuff) so the call to getLastModified() does not occur.
Still, it might be possible to hack the JSP-based servletI hate to hack
though
I'll think about it. Thanks for the suggestion.
Tony
- Original Message -
From: Markus Kirsten [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, June 04, 2002 5:16 AM
Subject: Re: ??? Using JSPs to Send Not-Modified-Since Header ???
Hi Tony,
Isn't it possible to put in the method after the jsp file has been
rewritten (by Tomcat) to a standard java source code file? Maybe it's
quick and dirty but I can't see why it shouldn't work.
Best of luck!
Markus
On Tuesday, June 4, 2002, at 09:28 AM, Tony LaPaso wrote:
Hi all,
In looking at past posts, I'm afraid I know the horrible answer
to this issue but I thought I'd ask just in case I missed
anything.
Let me start by saying I'm using Tomcat v4.0.4 beta 3.
As you know, when a client (usually a web browser) has a cached
version of a resource (usually a web page) it can send an
If-Modified-Since header to the HTTP server. The server
compares the time/date stamp specified in the header with that of
the requested resource. If the resource has *not* been modified
since the time specified in the If-Modified-Since header, the
server sends back a 304 (Not-Modified) response, effectively
telling the client (usually a web browser) that its cached
version of the resource is still valid.
When writing a servlet, it's easy to handle this sort of
scenario. The javax.servlet.http.HttpServlet class has a
service() method. This method first checks if the incoming HTTP
method is a GET. If it is, the service() method proceeds to
call the getLastModified() method of the servlet. As a
developer, you can override getLastModified() to return a long
value representing the last time the requested resource was
changed. Depending on the value returned by getLastModified()
(note that -1 is returned if you don't override the method) the
service() method may simply return a 304, Not-Modified response
rather than calling the servlet's doGet() method.
Now, the $18.32 Question: How do you ensure getLastModified()
is called in JSP?
No, you cannot simply do this:
%!
public long getLastModified() {
return xxx;
}
%
The problem is that the above method will never be called by the
container.
I traced through some of the Tomcat/Catalina/Jasper code and it
seems to me that the response code is being set to 200/OK very
early on in the processing.
I also took a cursory look at the JSP spec and didn't find any
indication of setting a Not-Modified response code...so, I am
thinking this is something that is (strangely) missing in the JSP
specification. I have a JSP page that needs to update itself once
per day. Therefore, it would be very handy to have the
getLastModified() functionality enjoyed by servlet writers.
Can anyone confirm this?
Thanks...
--
To unsubscribe, e-mail: mailto:tomcat-user-
[EMAIL PROTECTED]
For additional commands, e-mail: mailto:tomcat-user-
[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Using JSPs to Send NOT-MODIFIED-SINCE Header
Hi all,
In looking at past posts, I'm afraid I know the horrible answer
to this issue but I thought I'd ask just in case I missed
anything.
Let me start by saying I'm using Tomcat v4.0.4 beta 3.
As you know, when a client (usually a web browser) has a cached
version of a resource (usually a web page) it can send an
If-Modified-Since header to the HTTP server. The server
compares the time/date stamp specified in the header with that of
the requested resource. If the resource has *not* been modified
since the time specified in the If-Modified-Since header, the
server sends back a 304 (Not-Modified) response, effectively
telling the client (usually a web browser) that its cached
version of the resource is still valid.
When writing a servlet, it's easy to handle this sort of
scenario. The javax.servlet.http.HttpServlet class has a
service() method. This method first checks if the incoming HTTP
method is a GET. If it is, the service() method proceeds to
call the getLastModified() method of the servlet. As a
developer, you can override getLastModified() to return a long
value representing the last time the requested resource was
changed. Depending on the value returned by getLastModified()
(note that -1 is returned if you don't override the method) the
service() method may simply return a 304, Not-Modified response
rather than calling the servlet's doGet() method.
Now, the $18.32 Question: How do you ensure getLastModified()
is called in JSP?
No, you cannot simply do this:
%!
public long getLastModified() {
return xxx;
}
%
The problem is that the above method will never be called by the
container.
I traced through some of the Tomcat/Catalina/Jasper code and it
seems to me that the response code is being set to 200/OK very
early on in the processing.
I also took a cursory look at the JSP spec and didn't find any
indication of setting a Not-Modified response code...so, I am
thinking this is something that is (strangely) missing in the JSP
specification. I have a JSP page that needs to update itself once
per day. Therefore, it would be very handy to have the
getLastModified() functionality enjoyed by servlet writers.
Can anyone confirm this?
Thanks...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
??? Where's javax.servlet.* Source Code ???
Hello all, I'm using Tomcat v4.0.4 B3. Does anyone know where I can find the soure code for the javax.servlet.* classes? I thought they used to be distributed w/Tomcat source code but it seems those days are gone. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-- A JAR For All Seasons --
Hello, I asked this question earlier in the week and I didn't get any responses...so, at the risk of being a little obnoxious, I'll ask again I'm using Tomcat v4.0.3 on Win2k. I have a few JAR files that I would like to be accessible from within *all* contexts on my web site. In other words, I do not want to duplicate these JAR files in the WEB-INF/lib directory for each and every context on my site. The company that hosts my site, however, only allows me to access the files in *my* domain so I do not have the luxury of putting JAR files in, for example, jre/lib/ext where they would be picked up by other peoples' domains. I was hoping (I even said a couple prayers) there was a place in my directory structure I could put these JARs so they would be accessible to *all* servlets in *all* contexts on *my* site but obviously not accessible to other domains. Is this possible? Thanks very much. Tony LaPaso -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ??? Sitewide JAR Files ???
As I said, I do not have access to TOMCAT_HOME. The JAR files must be located somewhere in my domain's directory structure. - Original Message - From: Chris Campbell [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Wednesday, May 15, 2002 12:44 AM Subject: RE: ??? Sitewide JAR Files ??? definitely possible: put them in TOMCAT_HOME/common/lib ChrisC -Original Message- From: Tony LaPaso [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 1:36 PM To: Tomcat User Subject: ??? Sitewide JAR Files ??? Hello, I don't think this is possible but it can't hurt to ask I'm using Tomcat v4.0.3 on Win2k. I have a few JAR files that I would like to be accessible from within *all* contexts on my web site. In other words, I do not want to duplicate these JAR files in the WEB-INF/lib directory for each and every context on my site. The company that hosts my site, however, only allows me to access the files in *my* domain so I do not have the luxury of putting JAR files in, for example, jre/lib/ext where they would be picked up by other peoples' domains. I was hoping (I even said a couple prayers) there was a place in my directory structure I could put these JARs so they would be accessible to *all* servlets in *all* contexts on *my* site but obviously not accessible to other domains. Is this possible? Thanks very much. Tony LaPaso -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
??? Sitewide JAR Files ???
Hello, I don't think this is possible but it can't hurt to ask I'm using Tomcat v4.0.3 on Win2k. I have a few JAR files that I would like to be accessible from within *all* contexts on my web site. In other words, I do not want to duplicate these JAR files in the WEB-INF/lib directory for each and every context on my site. The company that hosts my site, however, only allows me to access the files in *my* domain so I do not have the luxury of putting JAR files in, for example, jre/lib/ext where they would be picked up by other peoples' domains. I was hoping (I even said a couple prayers) there was a place in my directory structure I could put these JARs so they would be accessible to *all* servlets in *all* contexts on *my* site but obviously not accessible to other domains. Is this possible? Thanks very much. Tony LaPaso -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
?? Class Loaders, Static Initializers, Open Files ??
Hi all, This is a core Java language issue but its roots are in servlets. I have a servlet (running on Tomcat v4.0.3), MyServlet, which calls Class.forName(XXX) in it's init() method. Now class XXX has a static initializer that opens a file for output and keeps it open. Later, I change the code in MyServlet and recompile it. The Tomcat notices the change and automatically loads the new version of MyServlet, using a different class loader than was used for the previous version. But when the new version of MyServlet calls Class.forName(XXX), the static initializer in XXX cannot open the file because the previous version has it open. So even though the first class loader is being dropped/abandoned, there is still a class loaded by that class loader (class XXX) that has a file open. And of course, I do not have the code for XXX. Is there any way to specify, either to the JVM or to Tomcat, that the file opened by XXX's static initializer should be closed? I'm guessing this is just the way it works. The previous class loader will be GCed, as will the previous version of MyServlet, but the file opened by XXX stays open until the VM goes down... Thanks... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ?? Class Loaders, Static Initializers, Open Files ??
Thank you all for the replies. The unfortunate part of this is that my servlet runs in a shared Tomcat environment so I don't have the luxury of putting classes/JARs wherever I want. I *will* be able to but some code in the destroy() method to inform the XXX class that it should close the file. I was just wondering if there was a better way.. Thanks again. - Original Message - From: Cox, Charlie [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, May 07, 2002 8:05 AM Subject: RE: ?? Class Loaders, Static Initializers, Open Files ?? you can move it to \common\lib which is loaded by a different class loader, but then it will be visible to all contexts. Using a static initializer like that will also cause problems if you try to use the manager to control your app since manager drops the classloader and creates a new one when you reload. maybe instead of a static initializer, you can use a servlet's init() and have it load on startup. This way you can use a class and utilize the destroy() method to do your cleanup. Charlie -Original Message- From: tamir [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 3:36 AM To: 'Tomcat Users List' Subject: RE: ?? Class Loaders, Static Initializers, Open Files ?? Hi Tony, Here is my notion: What you're using is tomcat automatic class reloading. When you compile class MyServlet tomcat drop it's current class loader and creates a new one which loads all your classes again. I think, if you should try to remove you class XXX outside of web-inf/classes and put it tomcat_home/common/lib in a jar. Then, tomcat won't reload your XXX class, and your static file will be ok. try it. Tamir -Original Message- From: Tony LaPaso [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 8:25 AM To: [EMAIL PROTECTED] Subject: ?? Class Loaders, Static Initializers, Open Files ?? Hi all, This is a core Java language issue but its roots are in servlets. I have a servlet (running on Tomcat v4.0.3), MyServlet, which calls Class.forName(XXX) in it's init() method. Now class XXX has a static initializer that opens a file for output and keeps it open. Later, I change the code in MyServlet and recompile it. The Tomcat notices the change and automatically loads the new version of MyServlet, using a different class loader than was used for the previous version. But when the new version of MyServlet calls Class.forName(XXX), the static initializer in XXX cannot open the file because the previous version has it open. So even though the first class loader is being dropped/abandoned, there is still a class loaded by that class loader (class XXX) that has a file open. And of course, I do not have the code for XXX. Is there any way to specify, either to the JVM or to Tomcat, that the file opened by XXX's static initializer should be closed? I'm guessing this is just the way it works. The previous class loader will be GCed, as will the previous version of MyServlet, but the file opened by XXX stays open until the VM goes down... Thanks... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Servlet Names -- ?? Modify Servlet Spec -- Comments ??
Hi All, First, let me say that I'm *not* requesting creative ways to get around this behavior. I'm wondering if the Servlet Spec (sec. SRV.11.1) should be refined to address this issue. I'm using Tomcat v4.0.3 on Win 2K. Let's say I have this servlet declaration in my deployment descriptor: servlet servlet-nameHelloWorld/servlet-name servlet-classcom.abc.def.HelloWorld/servlet-class /servlet What I'm finding (and I don't like) is that I can invoke this servlet either by its servlet name or its fully-qualified class name: URL #1: http://myHost/servlet/HelloWorld OR URL #2: http://myHost/servlet/com/abc/def/HelloWorld Each URL creates a *separate instance* of the servlet. To my way of thinking, the servlet-name specified in the deployment descriptor is more or less a logical name for the physical servlet. By specifying this name in the deployment descriptor, I am providing a name by which this servlet is to be known to the world. This logical name should hide the physical name of the servlet. If some rogue client (somehow) happens to know the fully-qualified class name for the servlet, and invokes it using URL #2 above, this should *not* cause an extra instance of the servlet to be created. In fact, it should not even cause the servlet to be invoked. Off the top of my head, here are four reasons why the exisiting behavior seems bad: 1. It's wasteful in that it creates an unneeded servlet instance. 2. It complicates the logic of a servlet because now it must allow for additional instances created if the servlet is invoked by its fully qualified class name. 3. A security issue arises. If a user is able to successfully invoke the servlet using the fully qualified class name, it may give the user insight into the server's directory structure. 4. It prevents a unified set of URLs from being the *only* way of invoking a servlet. My general feel is that the server administrator should have complete control over the name(s) (i.e., URLs) by which a servlet is know to the world. I'm wondering if SRV.11.1 should be updated. Here's a plain English proposal: If a servlet-mapping element(s) exists in the deployment descriptor, the servlet is accessible *only* via the specified url-pattern element(s) and *not* by the servlet-name element(s) within the servlet element. If *no* servlet-mapping element(s) is present but a servlet element exists, the servlet is accessible *only* via the enclosed servlet-name element(s). If a servlet element does *not* exist, then the servlet is searched for using specified URL path. Comments?? Is this a dumb idea? -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
TEST -- IGNORE
Blah Blah __ Do You Yahoo!? Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
??? TC 4.0.2 Throws Exceptions ???
Hi All,
TC 4.0.2 is throwing an exception on this little
servlet. Let me emphasize -- *Tomcat* is throwing the
exception, not the sevlet. I don't believe that TC
should ever throw an exception, unless there is a bug
in TC, is that correct?
If you run the servlet below you'll see this exception
thrown by TC:
java.lang.IllegalStateException: Current state =
FLUSHED, new state = CODING_END
at
java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:933)
at
java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
at
sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.java:356)
at
sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
at
sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
at
java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
at
java.io.PrintWriter.close(PrintWriter.java:137)
at
org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBase.java:482)
at
org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpResponseBase.java:236)
at
org.apache.catalina.connector.http.HttpResponseImpl.finishResponse(HttpResponseImpl.java:288)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1039)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
at java.lang.Thread.run(Thread.java:536)
Here's the servlet...if you comment out the close()
the exception goes away.
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Tester extends HttpServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res) throws ServletException,
IOException {
res.setContentType(text/plain);
PrintWriter out = res.getWriter();
out.println(Hello #1);
out.println(Hello #2);
out.println(Hello #3);
out.println(Hello #4);
System.out.println(res.isCommitted());
res.sendError(res.SC_REQUEST_ENTITY_TOO_LARGE,
sorry dude...);
out.close();
} // doGet()
} // Tester
__
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
??? Does Tomcat 4 b3 Support Reloading ???
Hello, By reading the documentation, it seems Tomcat 4 b3 should support servlet reloading but this does not seem to be the case. After a fresh install of Tomcat 4 b3 I modified the SnoopServlet and the change was *not* picked up even though the examples Context has reloadable="true" specified. Has anyone else had this problem? Is there a version of Tomcat that *does successfully reload changed servlets? Thanks.
Re: Servlet auto-reloading under ROOT context (was RE: simple question for servlet-configuration of tomcat)
I have a *similar* problem. None of my servlets are being reloaded using Tomcat 4, b3. This includes the servlets in /examples context. The only way I've been able to get servlets to reload (aside from re-starting Tomcat) is to run /manager/reload?path=/someContext. Apparently servlet reloading is completely broke in T4 b2/3. - Original Message - From: "Joel Parramore" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 06, 2001 2:28 PM Subject: Servlet auto-reloading under ROOT context (was RE: simple question for servlet-configuration of tomcat) On a slightly related note: are servlets under the ROOT context automatically reloaded? The docs in server.xml would appear to indicate that reloadable="true" is the default, but there's no entry for the ROOT context in my server.xml file, and it appears to be inconsistent on our server with regard to reloading a servlet which has (definitely) changed in webapps/ROOT/WEB-INF/classes (i.e., Tomcat apparently reloaded the servlet each time the class was changed, then suddenly stopped doing so, with no configuration changes made). Would placing an explicit CONTEXT entry for the ROOT in the server.xml file, i.e., Context path="/" docbase="webapps/ROOT" crossContext="false" debug="0" reloadable="true" /Context resolve this issue? Has anyone else encountered a similar problem? I can supply more configuration upon request, but at least I'll note that the server configuration is with Apache 1.3.14 and Tomcat 3.2.1 running Redhat Linux 7.0 on an Intel box, JDK 1.2.2. Tomcat, aside from slight changes for mod_jk operation with Apache, is unchanged from the default configuration. Regards, Joel Parramore -Original Message- From: Mandar Joshi [mailto:[EMAIL PROTECTED]] Sent: Friday, April 06, 2001 2:51 PM To: [EMAIL PROTECTED] Subject: Re: simple question for servlet-configuration of tomcat You simply need to put your stuff uner ROOT context. - Original Message - From: "TOPO graphics GmbH" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 06, 2001 7:19 AM Subject: simple question for servlet-configuration of tomcat Hello, since several weeks I am testing tomcat as a Servlet Engine with great success. I use Win98 SE2 with PWS. Now I have a simple problem (I think): What I have to do (in the configuration files) when I want to start my servlets with the URL: http://localhost/servlet/TestServlet and not with a WEPAPP-Directory like http://localhost/example/servlet/TestServlet Which settings I have to do in the configuration-files and in which directory I have to put my Servlets ? Thanks a lot for your answer With best regards M. Thorand TOPO graphics Geographische Informationssysteme GmbH EMail: [EMAIL PROTECTED]
