JSP error with standard Javac (and a workaround) with Tomcat 4.1.27
Hi, I've just upgraded from Tomcat 4.1.24 to 4.1.27, and am using the default out-of-the-box configuration (see below). Tomcat now refuses to compile JSPs with the default settings. I need to modify conf/web.xml such that the fork init-param for the JSP servlet is set to true (not false, which is the default)... and then it works. Basically, without fork=true, it complains that it can't resolve JAVA_HOME. When it forks, all goes well. See the output below for more information. Here's my config: - Win2000 SP4 (no other web servers running/installed) - Sun's J2SE 1.4.2 SDK, installed in d:\java\jdk1.4.2 - JAVA_HOME is set as a system environment variable, pointing to d:\java\jdk1.4.2 - tools.jar is in the lib subdirectory of JAVA_HOME. - Tomcat 4.1.27, downloaded as a binary release from main website http://jakarta.apache.org/tomcat/ Hope this helps iron out a wee problem! - Chris B. 2003-08-07 15:29:24 Info: Compile: javaFileName=D:\inetpub\tomcat\work\Standalone\localhost\open\/login_jsp.jav a classpath=/D:/inetpub/tomcat/webapps/open/WEB-INF/classes/;D:/inetpub/tomcat /common/lib/ant.jar;D:/inetpub/tomcat/common/lib/commons-collections.jar;D:/ inetpub/tomcat/common/lib/commons-logging-api.jar;D:/inetpub/tomcat/common/l ib/jasper-compiler.jar;D:/inetpub/tomcat/common/lib/jasper-runtime.jar;D:/in etpub/tomcat/common/lib/naming-common.jar;D:/inetpub/tomcat/common/lib/namin g-factory.jar;D:/inetpub/tomcat/common/lib/naming-resources.jar;D:/inetpub/t omcat/common/lib/servlet.jar cp=D:\inetpub\tomcat\webapps\open\WEB-INF\classes cp=D:\inetpub\tomcat\common\lib\ant.jar cp=D:\inetpub\tomcat\common\lib\commons-collections.jar cp=D:\inetpub\tomcat\common\lib\commons-logging-api.jar cp=D:\inetpub\tomcat\common\lib\jasper-compiler.jar cp=D:\inetpub\tomcat\common\lib\jasper-runtime.jar cp=D:\inetpub\tomcat\common\lib\naming-common.jar cp=D:\inetpub\tomcat\common\lib\naming-factory.jar cp=D:\inetpub\tomcat\common\lib\naming-resources.jar cp=D:\inetpub\tomcat\common\lib\servlet.jar work dir=D:\inetpub\tomcat\work\Standalone\localhost\open srcDir=D:\inetpub\tomcat\work\Standalone\localhost\open include=login_jsp.java Exception compiling Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK 2003-08-07 15:29:24 Exception: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK at org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(C ompilerAdapterFactory.java:139) at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:835) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:320) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:4 73) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:1 90) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jikes 1.18 JSP compiler support broken in TC 4.1.27
Hi, I tried switching to Jikes with Tomcat release 4.1.27 (LE-JDK1.4), and it would appear that the version of ant.jar you use internally in Tomcat to compile JSP pages is out of date with regards to the latest versions of Jikes (which have been around for a while now). The Javac Ant task is specifying an -encoding option for Jikes, which Jikes is refusing. I'm using Jikes Compiler - Version 1.18 - 21 November 2002 (according to the jikes -version command) on Win2000. See below for Jasper's output. I have no problem using Jikes standalone, or with Ant 1.5.3's Javac task (outside of Tomcat). I'm using Sun's JDK 1.4.2 on Win2000 SP4. Hope this helps, Chris B. org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Compiling 1 source file [javac] use: jikes [options] [EMAIL PROTECTED] file.java... [javac] For more help, try -help or -version. [javac] Error: The option -encoding is unsupported in this build. at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandle r.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:2 93) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:353) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:4 73) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:1 90) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Suggestion for DefaultServlet (easier spidering by search engines)
Hello, Just a little suggestion to help search engines spider Tomcat websites easier... Could somebody add the following to the directory listings generated by tomcat ? meta name=robots content=noindex,follow/ Thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why unpackWars=true default?
To clarify, when I said I consider WARs as if they were EXEs, I mean that in many cases I think it's good practice to have a WAR file that doesn't try to modify itself internally (bit like having an EXE or whatever that modifies its contents or self-modifying assembler code...). Some webapps benefit from customisation, and are good candidates for unpacking, others are best left as a single unit which store environment settings externally. My main gripe with the unpackWARs setting is that if WARs are unpacked, it makes it more troublesome to upgrade, because a newer version of the WAR file is ignored if any previous version has already been unpacked (until the unpacked files are deleted). If the WAR file is updated, it's *probably* safe to assume that this was done voluntarily, and so any previous unpacked version should be removed then replaced. I don't really care if it's considered a deployment format or an executable format ; whether it's unpacked on disk, in memory, or whatever is irrelevant, as long as it works : it's up to the servlet engine to implement this as it wants (given that JSPs need to be compiled, obviously something needs to be created outside the WAR). Having said that, if we're meant to deploy as unpacked files, why bother with methods such as ServletContext.getResource() (when we could just use getRealPath if we systematically unpacked these files) ? - Chris - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, January 22, 2003 1:31 AM Subject: Re: Why unpackWars=true default? On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote: consider the .war file like an .exe or executable JAR file. And I think this is where my interest comes from. Your considerations are exactly the opposite of Costin's (I think it was Costin anyways), who considers the .war file a *deployment* format only, like an RPM or a Windows Installer file, not to be run as an executable. I thought the raison d'etre of war's was acting like a single .exe. Or at least the default -- just as you're not expected to unpack jars. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Why unpackWars=true default?
Would it be better to remove unpackWARs from tomcat5 since there isn't that much of a concern for backwards compatibilty on major releases? -Tim It should always be at least an option to deploy WAR files without unpacking them. Systematically unpacking WARs would cause problems: the unpacked version is always used in preference to the packed version by Tomcat, so if unpackWARs=true, then overwriting the original .war file has no effect (because of the preference for using the directory if it exists), making upgrade deployment of webapps very problematic, leading to lots of support calls for us (I replaced the WAR file, but nothing happens!). It seems like a bad idea in many cases (obviously not all) to allow modifications within the webapp itself on production deployments (small sites and development releases of webapps are examples where this wouldn't always apply). All custom data in our apps is either stored in the user.home directory, the preferences API, JNDI, or whatever. We tend to consider the .war file like an .exe or executable JAR file. - Chris -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Input optimization
If you could come up with a better name for the substract method ;-) It's supposed to be the opposite of append. prepend() ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat and JSDK 1.4
This is really a user question... In answer to your question, I have tried it on Windows 2000 and Windows XP, with Sun's JDK 1.4.0 (final, not the _01 patch or 1.4.1 beta). It crashes quite often, i.e.: the JVM just dies, not a Tomcat exception. It happened frequently with Tomcat 4.0.x, but I didn't have time to track the bug exactly. I suspect a problem in the JDK however, as the I/O implementation has changed a lot. Hopefully the problem will have gone away in more recent releases. -Chris B - Original Message - From: Bracken, William (Contractor) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 17, 2002 8:34 PM Subject: Tomcat and JSDK 1.4 Okay, Tomcat 4 has been extensively tested with JDK 1.3.1, which is recommended. My question is, have any of you gurus out there worked with JSDK 1.4? If so, on what platforms? Have any problems? Sorry to give a 'do my homework for me' question, but I have no time to do all those tests, and I'm sure quite a few of you out there have larger projects that you've moved (or attempted to move) to 1.4. Will -- 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: [JK2] Trying 4.1.3 Beta + IIS
See intermixed. - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, June 26, 2002 12:33 PM Subject: RE: [JK2] Trying 4.1.3 Beta + IIS De: Chris Brown [mailto:[EMAIL PROTECTED]] Enviado el: 26 de junio de 2002 9:53 Should connectors to IIS and Apache behave differently according to whether a webapp is deployed as a WAR file or as an uncompressed set of files on the disk? When the webapp is deployed uncompressed, it should be easy enough to find the static files to server, but when it's an unpacked WAR file, it's unlikely IIS et al know how to read from the WAR file directly, or locate the temporary folder into which WAR file contents are unpacked (so that it can find static files). I dont know what could be done if you try to run your app directly from a war, but it seems to me that to do nothing is the way to go :), it is simply a tradeoff.. I was just wondering if the connectors were aware that sometimes they won't find static contents using any real path, as they may be in a WAR file. As long as the connectors know that sometimes they shouldn't serve static content, they should just be a sort of proxy or man-in-the-middle. An given that, to get static content served natively by the webserver, it's a performance measure, it's seems that there is a little contradiction with the possibility of run the webapp directly from the war, isn't it? I agree that for performance reasons, it's best to let the frontal server handle static requests. However, in some scenarios (particularly development), it's useful to be able to overwrite previous versions in one go, i.e.: replace one WAR file with another, instead of deleting files that are no longer required, then adding all new files. Where I work, we also create webapps for other companies or organisations/associations, and it's much easier for them to handle one single file than lots of separate files, especially when they want to install an upgrade! Saludos , Ignacio J. Ortega Thanks, -Chris B. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [JK2] Trying 4.1.3 Beta + IIS
Should connectors to IIS and Apache behave differently according to whether a webapp is deployed as a WAR file or as an uncompressed set of files on the disk? When the webapp is deployed uncompressed, it should be easy enough to find the static files to server, but when it's an unpacked WAR file, it's unlikely IIS et al know how to read from the WAR file directly, or locate the temporary folder into which WAR file contents are unpacked (so that it can find static files). - Chris B. - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, June 26, 2002 12:48 AM Subject: RE: [JK2] Trying 4.1.3 Beta + IIS De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: 26 de junio de 2002 0:35 I can't really answer like that. The static files aren't supposed to get served by IIS here ? My setup is [uri:/examples/*] wk2.p file uri components, are Servlet spec compliant (more or less) so you can specify that only *.jsp or an absolute path it's served by tc, but you can too use it as webapp, how i used it.. dumping an entire url subtree to tomcat to manage.. And remember they are mainly need in IIS, Apache can use JK2 directly, without using at all the JK2 mapper.. I can't think of anything funny the DefaultServlet would do over a simpler servlet. It isnt the DS, hmmm, but fail are repeatables, and most times , if you keep getting the same file it eventually fails too.. Saludos , Ignacio J. Ortega -- 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: 5.0 proposal
I can't commit to developing this (I'd love to, I have some ideas, but I don't have the time...), but hopefully it might interest someone and they can develop it... When deploying webapps as WAR files, especially generic webapps, it's not always very practical to request that an administrator manually unpacks the WAR file, locates the web.xml file, and updates context or servlet parameters. Perhaps the admin/manager webapp could list all context/servlet parameters for a given webapp, and allow their values to be changed. This isn't a way to modify web.xml directly, more a way to store values to override whatever's in web.xml. That way, if a new copy of the webapp is installed in the server, the overriding values would still be retained and can override the updated web.xml, without requiring to be reentered. It's by no means a critical feature, but it's nice to have. - Chris B. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Spec change: getting servlet context name / url prefix during init
Hello, I'm aware (or at least, I assume!) that some of the people on this list are involved in developing the specs for the Servlet API. It would be useful to be able to obtain information about the servlet context's name (or specifically, it's URL prefix) during initialisation (either in a servlet's init() method, or in session or context event listeners), for example to know that all servlets in the context will be prefixed with /mycontext for example. It's useful for preparing resources in quite a few cases, but at present, I can only obtain this info from the ServletRequest (and that's too late, or at least very tricky to handle or synchronise). I know that there's a method on ServletContext called getServletContextName, but that returns the value of the display-name element in the deployment descriptor, not the URI mapping. Hopefully someone can put this idea forward for inclusion in Servlet2.4 (the next one, isn't it?). Thanks, -Chris B. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fw: request.getLocale() always returns en_US ..?!
Hello, I posted this on tomcat-user, without any reply. It seems to be a bug, so I hope it's relevant on this list. -Chris - Original Message - From: chris brown To: tomcat-user Sent: Thursday, March 14, 2002 3:52 PM Subject: request.getLocale() always returns en_US ..?! Hello, I'm trying to use the method getLocale() on HttpServletRequest objects... however, it always seems to return en_US! This is despite my browser sending fr,en-gb;q=0.5 as the accept-language header! (I've checked this last point by calling request.getHeader(Accept-Language), including several variations (upper lower case, for example). I can always get the correct value back, but Tomcat 4.0.1 always returns en_US. Is this a bug? Or am I missing something? For info., I've tried this on IE6.0 and Mozilla 0.9.8 . Both with appropriate language settings, both get picked up as en_US, despite correctly-specified values in the accept-language headers. - Chris B. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Add a new mime-type to web.xml
Hi, Would it be possible to add the following mime-mapping to the default web.xml file for future releases of Tomcat? mime-mapping extensionhtc/extension mime-typetext/plain/mime-type /mime-mapping It's for DHTML behaviors, which don't work without this mime type. It's a minor addition, and quite simple, so I hope someone can do this (maybe in time for the release of 4.0.2 ?) Thanks, Chris Brown -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Suggestion for directory listings generated by Tomcat
Hi, I'm setting up a search engine to index some sites running under Tomcat (4.01 as it happens). It redundantly indexes Tomcat's directory listing pages as valid documents (albeit with little interest). I can of course set up URL filters for the search engine that force it to follow links without indexing content when the URL ends with / (path separator). It would maybe make life simpler for everyone in my situation if someone could modify Tomcat's directory listing servlet to include the following meta tag : meta name=robots content=noindex,follow Hopefully someone has a few spare minutes to do that. Many thanks in advance, -Chris Brown -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
