RE: class-loading and java.endorsed.dirs
This is a JVM thing, not a tomcat thing. You're not normally allowed to override built-in Java classes locally (for security reasons). In JDK 1.4, the XML/XSLT classes are built in. The endorsed standards override mechanism was added to 1.4 because of the fact that some people might need or want to use an alternate XML parser or transformer. So the JAVA_ENDORSED_DIRS thing tells the JVM that it's OK to override Xalan with libraries from the specified directories. So I don't think there's any way to specify on a per-webapp basis which impl to use. It's all or nothing at the VM instance level. Also see http://java.sun.com/j2se/1.4/docs/guide/standards/ for more info. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Voytenko, Dimitry [mailto:[EMAIL PROTECTED]] Sent: Friday, February 21, 2003 12:30 AM To: '[EMAIL PROTECTED]' Subject: class-loading and java.endorsed.dirs Hi, Here's what happend. It looks pretty strange. I couldn't find explanation to this neither in Tomcat docs, Servlet specs or Mailing List. I have a servlet, with doGet implemented as: System.err.println(XALAN VERSION = + org.apache.xalan.Version.getVersion()); In the application's WEB_INF/lib directory I have xalan.jar of version 2.4.1, which I thought should have been used. But instead, as the result of execution of the servlet, I got XALAN VERSION = Xalan Java 2.2 D11 This is the Xalan version included to JDK 1.4. Isn't application's JAR should be used (as stated in SRV.9.7.2 of the Servlet 2.3 specification)? Then, I changed setclasspath.bat JAVA_ENDORSED_DIRS env. variable to include my WEB_INF/lib directory (application wasn't packed into WAR). This variable is then passed as the value of java.endorsed.dirs java startup parameter. As the result, I got XALAN VERSION = Xalan Java 2.4.1 which I expected in the first place. Does this mean that libraries in the endorsed dir have bigger priority? It's a little confusing why this change whould make such a difference. Is there a way to specify forcefully that application should only use local libraries if they're specified? Thanks, Dimitry E Voytenko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
This bug seems to be submitted several times a week. Maybe an FAQ would be in order? (or FOB -- frequently opened bugs haha) Then again, if people don't search the bug database before submitting a new one, then I guess they can't be expected to read the FAQ. And on the other hand, if the spec confuses this many people, maybe that should be fed back to the spec authors. Just adding a reset method to Tag that is called before each invocation might help people understand the difference between that and release. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, January 17, 2003 10:58 AM To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked Martin Algesten wrote: Remy, once again we agree :) Lol, I guess. After the 100th time this bug is being reopened, I'm getting pissed ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
-Original Message- From: Hans Bergsten [mailto:[EMAIL PROTECTED]] Sent: Friday, January 17, 2003 1:37 PM To: Tomcat Developers List Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked Tim Moore wrote: This bug seems to be submitted several times a week. Maybe an FAQ would be in order? (or FOB -- frequently opened bugs haha) Then again, if people don't search the bug database before submitting a new one, then I guess they can't be expected to read the FAQ. And on the other hand, if the spec confuses this many people, maybe that should be fed back to the spec authors. Just adding a reset method to Tag that is called before each invocation might help people understand the difference between that and release. I'm in the EG and we had a long discussion about this again for JSP 2.0. The end result is that the current behavior (do _not_ call release() between invocations) will stay. A confusing arrow from the released state to the initialized state in the state diagram will be removed, however. This state transition came with lots and lots of restrictions, but it seems like some vendor (and developers) saw it as a requirement to call release() between invocations, even though the text clearly state that that's not the case. I agree that the current behavior of release should not change. There are important uses for long-term state that we shouldn't throw away just because of some confusion. But what do you think about the idea of adding a new method? My thinking is that if there were a reset method where people could reset invocation-local state, then it would be easier for people to understand the correct purpose of release in contrast. I know there are perfectly good ways to reset now, so this change would be more for psychological reasons than technical ones. You have to admit, though, the fact that this misunderstanding is so common does say something about the clarity of the API. I made this mistake initially, and I believe many of the Jakarta tags did as well. I also know that adding methods to an interface can be problematic for backwards compatibility reasons, but if a noop implementation is added to TagSupport, that would handle 90% of the problem. What do you think? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
-Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: Friday, January 17, 2003 5:49 PM To: [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked Hans Bergsten wrote: evaluation all in one place. To make things even easier, these tag handlers can _not_ be reused at all. Benchmarks with modern JVMs show that the gain from reuse is not worth all the trouble. So, for new tags we recommend using the SimpleTag API which takes care of the problem by forbidding reuse. Wow. I would be _very_ curious to see those benchmarks and the modern JVM that was used. All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well worth the trouble - at least if you have 100s of requests per second ( it is not worht the trouble for very low loads ). But I'm happy to hear that I'm wrong. Costin I thought the benefit of Tag.release and pooling was that I could create a tag that does something expensive at init time (acquire a DB connection, read a file, whatever) and reuse those resources until released. Maybe that's a bad practice? But then what's the advantage of having release called only once before GC? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] forward instead of redirect for welcome files
-Original Message- From: Matt Parker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 7:39 PM To: Tomcat Developers List Subject: Re: [PATCH] forward instead of redirect for welcome files Verified the following: http://foo/bar#anchor http://foo/bar/#anchor with a welcome-file of: test/test.jsp and was correctly forwarded to: http://foo/bar/test/test.jsp#anchor okay, I was a little premature (no jokes please). if the welcome file itself has a relative link off of it, then it breaks. so that a href='foo.jsp' on test.jsp will try to go to http://foo/bar/foo.jsp rather than http://foo/bar/test/foo.jsp i'll see if i can fix that. sorry... If you want to mirror what Apache HTTPD does: No slash present -- append slash (only!) and redirect Slash present -- internally forward to welcome-file page -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] forward instead of redirect for welcome files
-Original Message- From: Matt Parker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 8:11 PM To: Tomcat Developers List Subject: RE: [PATCH] forward instead of redirect for welcome files If you want to mirror what Apache HTTPD does: No slash present -- append slash (only!) and redirect Slash present -- internally forward to welcome-file page Well, here's the rub: - The new servlet spec clearly states that either /foo or /foo/ should return a welcome-file (if specified) Well if you redirect from /foo to /foo/ and handle the welcome file from /foo/ then all is well. :-) - Apache also has the problem with a relative link on a welcome file which has a directory specified in it Ah...yes I imagine so. However, I think that the patch benefits still outweigh its drawbacks: - it satisfies the new servlet spec - it circumvents the need for special processing and configuration when placed behind a proxy server (a farely common production practice). - it inherits a problem, but the problem is probably rare in practice, and will already have been avoided by Apache users since it's the same. i.e. i've never had a burning need to specify a welcome file or directory index that has a subdirectory in it _and_ has a relative link, so i can only guess that others either don't or already know to avoid it. Unless I'm missing something, if you don't redirect from /foo to /foo/, then you'll have broken relative links even if the welcome file is not in a subdirectory. This would probably be a pretty common problem. For example, if your welcome file has a href=bar.html then resolving that relative to /foo would give you /bar.html while resolving it relative to /foo/ would give you /foo/bar.html. That means that relative links will either work or not work, depending just on whether the trailing slash is there. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat without DOS Window on Win XP, i.e. like an NT Service?
-Original Message- From: micael [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 1:11 PM To: [EMAIL PROTECTED] Subject: Tomcat without DOS Window on Win XP, i.e. like an NT Service? Anyone know how to start Tomcat without the DOS window on Win XP? Micael So-called NT services should still work on Win XP. I haven't done it myself, but some of my coworkers have. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Security threat with enabling invoker servlet in 4.1.12
-Original Message- From: Budi Kurniawan [mailto:budik;cse.unsw.EDU.AU] Sent: Friday, November 01, 2002 7:22 PM To: Tomcat Developers List Subject: Security threat with enabling invoker servlet in 4.1.12 Hi, I've browsed the user list for this question but could not find the answer. Apologies if this is not the right question for this list. The release note in 4.1.12 says that the invoker servlet is turned off in the default web.xml for security reasons. However, in the examples app's web.xml the invoker is on. My questions are: 1. What security threat is that? 2. If it is not safe to turn it on in the default web.xml, is it safe to do so in the app web.xml? thx, budi This probably is more appropriate for the user list, but to answer your question, please see http://www.mail-archive.com/tomcat-dev;jakarta.apache.org/msg33723.html and http://www.mail-archive.com/tomcat-dev;jakarta.apache.org/msg34918.html -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: How to run multiple instances of JSP pages/servlets in Tomcat?
You can have several servlet declarations that use the same file or class. servlet servlet-nameMyJspPage/servlet-name jsp-file/mywebapp/MyJspPage.jsp/jsp-file init-param param-nameconfigFile/param-name param-valuemy.conf/param-value /init-param load-on-startup1/load-on-startup /servlet servlet servlet-nameMyJspPage2/servlet-name jsp-file/mywebapp/MyJspPage.jsp/jsp-file init-param param-nameconfigFile/param-name param-valuemy2.conf/param-value /init-param load-on-startup2/load-on-startup /servlet -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Luca Ventura [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 4:13 PM To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: R: How to run multiple instances of JSP pages/servlets in Tomcat? Hello! And thanks a lot! Can you tell me also how I can indicate the number of instances to activate for every servlet or jsp-page? Thanks in advance! Luca -Messaggio originale- Da: John Trollinger [mailto:[EMAIL PROTECTED]] Inviato: giovedi 26 settembre 2002 17.01 A: 'Tomcat Developers List' Oggetto: RE: How to run multiple instances of JSP pages/servlets in Tomcat? The servlet spec explains how to do this servlet servlet-nameMyJspPage/servlet-name jsp-file/mywebapp/MyJspPage.jsp/jsp-file init-param param-nameconfigFile/param-name param-valuemy.conf/param-value /init-param load-on-startup1/load-on-startup /servlet -Original Message- From: Luca Ventura [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 10:50 AM To: tomcat-dev Subject: How to run multiple instances of JSP pages/servlets in Tomcat? Hello everybody! In Tomcat 4.x I don't know how I can call automatically a JSP page when the web application starts. I mean...in Tomcat 4.x there is the web.xml file where I can declare: servlet servlet-nameMyServlet/servlet-name servlet-classMyServlet/servlet-class init-param param-nameconfigFile/param-name param-valuemy.conf/param-value /init-param load-on-startup1/load-on-startup /servlet In this way the servlet MyServlet is called when the web app. starts... Can I do the same thing with a jsp page (the jsp page should be like a servlet, in fact it is translated into a servlet when it is called the first time)? If yes, in which way? Another questions: how can I tell the Web Server Tomcat to activate more instances of a servlet or a JSP page? Thanks a lot to everybody! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
