RE: Proposed name encoding patch
Yes, this may work. Just remember to encode the escape char '_' as well even though it is a valid java id char. Otherwise, the mapping may not be unique. Tal -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 10:50 AM To: '[EMAIL PROTECTED]' Subject: RE: Proposed name encoding patch I was looking at this last night, by coincidence. It seems to me that the class name is encoding too much information. It's duplicating the package as part of the class name. I suspect it's getting confused between '/', '\', File.separatorChar, etc. It's also encoding characters that are legal in java class names that do not happen to be Character.isLetterOrDigit(). Should probably be Character.isJavaIdentifierStart and Character.isJavaIdentifierPart -Original Message- From: Tal Dayan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 3:41 AM To: [EMAIL PROTECTED] Subject: Proposed name encoding patch Hello, This is my first posting to this list so please bare with me. We are having problems with the jsp name mangling (bug 330 at http://znutar.cortexity.com/BugRatViewer/ShowReport/330). Every '/' or '_' char in the jsp path is converted to 6 chars which easily extend the file path beyond Win NT limitation of 256 chars. As a result, the JSP compilation fails with the following error: org.apache.jasper.JasperException: Unable to compile class for JSPerror: Can't write: D:\tomcat\appserv\work\localhost_8080\system\admin\modes\start\acc ount\_0002 fsystem_0002fadmin_0002fmodes_0002fstart_0002faccount_0002fpage_00 05fadmin_0 005fstart_0005faccount_0005fpassword_0002ejsppage_0005fadmin_0005f start_0005 faccount_0005fpassword_jsp_0.class A quick look at the code reveals that the mangling is done by the method CommandLineCompiler.mangleChar() so we plan to modify the method to generate a more compact encoding, especially for common chars such as '/', '_', and '.'. What is the view of the list regarding the proposed modification and how should we proceed to maximize the changes that our patch will be included in the official Tomcat code ? Thanks, Tal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Security problem
HI to all, i have found some problem in configuring security on site (Sparc Solaris 5.7) with Tomcat 3.2 (in virtual host). Everything goes Ok, but when I tried to configure Basic Realm on a particular Servlet class or sub dir of WEB-INF i didn't found any solution. Is it possible to keep in security only particular Servlet class and not the complete directory? - ?xml version="1.0" encoding="ISO-8859-1"? !DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd" web-app !-- Default login configuration uses BASIC authentication -- login-config auth-methodBASIC/auth-method realm-nameReal name/realm-name /login-config security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/protected/*/url-pattern url-pattern/servlet/login/*/url-pattern url-pattern/servlet/protected/*/url-pattern /web-resource-collection auth-constraint !-- This role name is configured in server.xml -- role-namerandom/role-name /auth-constraint /security-constraint /web-app - Thank's for suggestions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
I also think it would be good idea to require Jasper's JspServlet still function properly if used in Tomcat 3.3, even though Tomcat 3.3 now uses an interceptor to manage JSP compilation. (Jasper is still used for translation to servlet source, but the interceptor controls the rest). +1 (We use Jasper inside Weblogic's servlet container, and so don't have/use the interceptor) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Rollover for each day ? Is this possible ??
Jim,
Ooops! I got a DateRollingAppender from you too? Eirik Lygre has also sent
me one. Roberto Leong has too. Their contributions are attached.
Jim, can you please repost your contribution on this list? I seem to have
lost it. Sorry, I haven't been handling this item particularly well.
What I would like to see is the following:
0) Keep in mind that log4j is not in the quickie business. Much of the
success of the package can be attributed to solving problems well, not just
solving them.
1) The new appender should have flexible way of expressing the rollover
frequency, perhaps in the same format as in the Unix crontabs file which I
belive is also a Posix standard. I am not aware of any library that
supports this. JDring (http://webtools.dyade.fr/jdring/) seems to have most
of the functionality needed except parsing the crontab format. Anyone know
anything better?
As a side note, the omission of a crontab/at functionality in Java core
libraries seems like a major oversight. Try buying stock a day later then
what the customer ordered. See how many customers stay with your brokerage
house. :-)
2) The new appender should not add any significant overhead to the append
method. If appending to a file takes 100 microseconds in a particular
environment it should still take 100 microseconds with the new appender.
There are several possible designs. The first one is to check for the
rollover condition at each append. This is what Eirik Lygre has done. The
second one is to schedule a thread that will initiate the rollover after
the appropriate delay. This is what Roberto Leong has proposed.
The second approach seems more sound to me. One could generalize it by
using a single timer thread (as in JDring) to manage multiple time based
RollingAppenders. Your opinion/comments are welcome. Ceki
ps: I am forwarding this to the Avalon list since they are writing a
general purpose framework.
ps: I wonder how Tomcat addresses the issue.
At 21:45 18.01.2001 -0500, you wrote:
Yes, but you need to use a different Appender than FileRolloverAppender.
I've already written one, but haven't heard back from Ceki about adding it
to the "package" yet...
-Jim Moore
-Original Message-
From: Andrewt Tierney [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 18, 2001 8:02 PM
To: '[EMAIL PROTECTED]'
Subject: Rollover for each day ? Is this possible ??
I see you can set the maxsize and have it automatically rollover the log
file.
Is it possible to force a new log file each day
Thanks
Andrew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Freedom as in the capacity to exercise choice.
package org.log4j.varia;
import org.log4j.FileAppender;
import org.log4j.helpers.TracerPrintWriter;
import org.log4j.helpers.LogLog;
import java.text.SimpleDateFormat;
import java.io.IOException;
import java.io.FileWriter;
import java.util.Calendar;
// Roberto Leong [EMAIL PROTECTED]
/**
DailyFileAppender extends FileAppender to backup the log files when
the day changes. Basically a new log file will automatically
be created everyday.
*/
public class DailyFileAppender extends FileAppender {
// formatter for date
SimpleDateFormat formatter = null;
// pattern for date
String dateFormat = "-MM-dd";
{
formatter = new SimpleDateFormat(dateFormat);
}
//
// filename without the day part
String unformattedFileName = null;
/**
Activates the thread that checks the day
{@link #setOption}. */
public void activateOptions() {
super.activateOptions();
new Thread(new DayChecker(this)).start();
}
/**
Overrides FileAppender.setFile(String fileName, boolean append) to append
todays day to the filename
@param fileName The path to the log file.
@param boolean If true will append to fileName. Otherwise will
truncate fileName. */
public
synchronized
void setFile(String fileName, boolean append) throws IOException {
unformattedFileName = new String(fileName);
boolean hasDot = false;
//finds the first and hopefully only '.' and appends today's day before it.
// If no '.' is found just add it to end of the filename
for(int i=0; ifileName.length(); i++) {
if(fileName.charAt(i)=='.') {
String str = fileName.substring(0, i);
fileName = str + formatter.format(Calendar.getInstance().getTime()) +
fileName.substring(i);
hasDot = true;
break;
}
}
if(!hasDot)
fileName = fileName + formatter.format(Calendar.getInstance().getTime());
reset();
this.setQWForFiles(new FileWriter(fileName, append));
this.tp = new TracerPrintWriter(qw);
this.fileName = fileName;
this.qwIsOurs = true;
}
class DayChecker
Re: Rollover for each day ? Is this possible ??
A couple of comments. JDK 1.3 comes with timer classes in java.util.Timer and TimerTask. They don't have the functionality of cron but that could be built on top if necessary. Using the timer infrastructure of java.util has the advantage that fewer threads will be created overall in a system, and also it just makes sense to use JDK functionality when it's there. Sure some folks aren't using JDK 1.3 -- maybe there's a downloadable library that implements the java.util timer functions like there is for the collections lib. Also, I think that when using rolling log files one would usually like to roll over on boundaries and not just with a certain periodicity [if that's even a word]. For example, one might want to roll over daily at midnight, rather than just daily at the time the server happened to be restarted at last. Anders Ceki Gulcu wrote: Jim, Ooops! I got a DateRollingAppender from you too? Eirik Lygre has also sent me one. Roberto Leong has too. Their contributions are attached. Jim, can you please repost your contribution on this list? I seem to have lost it. Sorry, I haven't been handling this item particularly well. What I would like to see is the following: 0) Keep in mind that log4j is not in the quickie business. Much of the success of the package can be attributed to solving problems well, not just solving them. 1) The new appender should have flexible way of expressing the rollover frequency, perhaps in the same format as in the Unix crontabs file which I belive is also a Posix standard. I am not aware of any library that supports this. JDring (http://webtools.dyade.fr/jdring/) seems to have most of the functionality needed except parsing the crontab format. Anyone know anything better? As a side note, the omission of a crontab/at functionality in Java core libraries seems like a major oversight. Try buying stock a day later then what the customer ordered. See how many customers stay with your brokerage house. :-) 2) The new appender should not add any significant overhead to the append method. If appending to a file takes 100 microseconds in a particular environment it should still take 100 microseconds with the new appender. There are several possible designs. The first one is to check for the rollover condition at each append. This is what Eirik Lygre has done. The second one is to schedule a thread that will initiate the rollover after the appropriate delay. This is what Roberto Leong has proposed. The second approach seems more sound to me. One could generalize it by using a single timer thread (as in JDring) to manage multiple time based RollingAppenders. Your opinion/comments are welcome. Ceki ps: I am forwarding this to the Avalon list since they are writing a general purpose framework. ps: I wonder how Tomcat addresses the issue. At 21:45 18.01.2001 -0500, you wrote: Yes, but you need to use a different Appender than FileRolloverAppender. I've already written one, but haven't heard back from Ceki about adding it to the "package" yet... -Jim Moore -Original Message- From: Andrewt Tierney [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 8:02 PM To: '[EMAIL PROTECTED]' Subject: Rollover for each day ? Is this possible ?? I see you can set the maxsize and have it automatically rollover the log file. Is it possible to force a new log file each day Thanks Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Freedom as in the capacity to exercise choice. Name: DailyFileAppender.java DailyFileAppender.javaType: Plain Text (text/plain) Encoding: quoted-printable DailyFileAppender1.javName: DailyFileAppender1.jav Type: Plain Text (text/plain) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Rollover for each day ? Is this possible ??
Since I'm partly to blame :-), my few cents: 1) I don't have any strong opinions about threads vs checking each-time. I guess I chose checking each time because it seemed simpler to implement. 2) My appender uses a configurable file format, making it possible to customize the file format. Through this, it's simple to have files which roll over every week, every month, every day of the month, every weekday, etc. Since the file format maps directly to SimpleDateFormat, it ought to be flexible enough for most uses. If the rollover frequency changes, it is also possible to specify filenames which vary by the hour, or even (theoretically) the millisecond. Eirik ++ Eirik Lygre [EMAIL PROTECTED] e-vita as, Stortorvet 3, Oslo Mobil: (+47) 905 66476 Fax: (+47) 23 35 70 51 Anders Kristensen [EMAIL PROTECTED] 19.01.2001 13:00 To:LOG4J Users Mailing List [EMAIL PROTECTED] cc:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Rollover for each day ? Is this possible ?? A couple of comments. JDK 1.3 comes with timer classes in java.util.Timer and TimerTask. They don't have the functionality of cron but that could be built on top if necessary. Using the timer infrastructure of java.util has the advantage that fewer threads will be created overall in a system, and also it just makes sense to use JDK functionality when it's there. Sure some folks aren't using JDK 1.3 -- maybe there's a downloadable library that implements the java.util timer functions like there is for the collections lib. Also, I think that when using rolling log files one would usually like to roll over on boundaries and not just with a certain periodicity [if that's even a word]. For example, one might want to roll over daily at midnight, rather than just daily at the time the server happened to be restarted at last. Anders Ceki Gulcu wrote: Jim, Ooops! I got a DateRollingAppender from you too? Eirik Lygre has also sent me one. Roberto Leong has too. Their contributions are attached. Jim, can you please repost your contribution on this list? I seem to have lost it. Sorry, I haven't been handling this item particularly well. What I would like to see is the following: 0) Keep in mind that log4j is not in the quickie business. Much of the success of the package can be attributed to solving problems well, not just solving them. 1) The new appender should have flexible way of expressing the rollover frequency, perhaps in the same format as in the Unix crontabs file which I belive is also a Posix standard. I am not aware of any library that supports this. JDring (http://webtools.dyade.fr/jdring/) seems to have most of the functionality needed except parsing the crontab format. Anyone know anything better? As a side note, the omission of a crontab/at functionality in Java core libraries seems like a major oversight. Try buying stock a day later then what the customer ordered. See how many customers stay with your brokerage house. :-) 2) The new appender should not add any significant overhead to the append method. If appending to a file takes 100 microseconds in a particular environment it should still take 100 microseconds with the new appender. There are several possible designs. The first one is to check for the rollover condition at each append. This is what Eirik Lygre has done. The second one is to schedule a thread that will initiate the rollover after the appropriate delay. This is what Roberto Leong has proposed. The second approach seems more sound to me. One could generalize it by using a single timer thread (as in JDring) to manage multiple time based RollingAppenders. Your opinion/comments are welcome. Ceki ps: I am forwarding this to the Avalon list since they are writing a general purpose framework. ps: I wonder how Tomcat addresses the issue. At 21:45 18.01.2001 -0500, you wrote: Yes, but you need to use a different Appender than FileRolloverAppender. I've already written one, but haven't heard back from Ceki about adding it to the package yet... -Jim Moore -Original Message- From: Andrewt Tierney [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 8:02 PM To: '[EMAIL PROTECTED]' Subject: Rollover for each day ? Is this possible ?? I see you can set the maxsize and have it automatically rollover the log file. Is it possible to force a new log file each day Thanks Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Freedom as in the capacity to exercise choice. Name: DailyFileAppender.java DailyFileAppender.java Type: Plain Text (text/plain) Encoding: quoted-printable
RE: Interceptors
As a "piping" mechanism (as opposed to a "hooking" one) the kind of thing Donald described is my favorite one. My other $0.02 are that I agree 100% with Jon on this. People will get confused if you have 2 different ways of using valves from a minor version to the other. Have fun, Paulo Gaspar -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 02:22 on 1/18/01 4:28 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: If you change the names and parameter orders a little, you have just quoted the new api for javax.servlet.Filter in the 2.3 Proposed Final Draft. I'd be game to change the Valve APIs to conform to this kind of pattern in a 4.1 timeframe, if people prefer it. If we're ever going to do this, earlier is better (before too many valves that have to be changed get created). I'm almost thinking that this should be done for 4.0 because 4.0 is going to be implementing the 2.3 spec and having two different filtering mechanism's doing essentially the same thing doesn't make much sense to me... -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Interceptors
Over the weekend I will start having a look at 3.x HEAD. If you do not think that document is urgent and no one faster at doing it pops up, I can try writing something like that. Have fun, Paulo Gaspar P.S.: BTW, I was also refering to specialized events has in Swing. That is the kind of thing that realy cuts down development complexity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 05:54 P.S. Those are just few of the reasons behind the 3.x Interceptors. It would be great if someone would want to help creating a small document based on the discussions we had - with the pros and cons. I could also add few examples, and maybe go into more details about how the most important chains work ( Error handling, session, auth, mapping ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4.0 w/Apache question
Couple of simple questions to help us get TC 4.0 going like we had for Tomcat 3.1 1. Which Apache connectors can we use to talk to TC 4.0? I know of mod_jserv, mod_jk, and mod_webapp. Which of these work with TC4.0 and which one is best given our requirements. 2. I need to set up the connector to to forward ".jsp"and ".myservletsuffix" to TC4.0 while letting .gifs + .html be served up by Apache. Which connector is best for this? 3. My app context is the ROOT context "/" under 3.1 I need this functionality under TC4.0 as well. Which connector is best for this? Thanks guys! -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #805 has been filed.
Bug report #805 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/805 REPORT #805 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: tomcat m4 JVM Release: 1.1.3 Operating System: linux OS Release: 2.2.17 Platform: Intel Synopsis: Imort of packages in included JSP page Description: when i do in a JSP page: jsp:include page="%=jspLetName%"/ and in included page is a tag: %@ page import="some.package.*"% i expect in compiled java file will be import some.package.*; but isn't, so i must write whole names. Title: BugRat Report # 805 BugRat Report # 805 Project: Tomcat Release: tomcat m4 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Jan 19 2001, 09:21:59 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Imort of packages in included JSP page Environment: (jvm, os, osrel, platform) 1.1.3, linux, 2.2.17, Intel Additional Environment Description: Report Description: when i do in a JSP page: and in included page is a tag: <%@ page import="some.package.*"%> i expect in compiled java file will be import some.package.*; but isn't, so i must write whole names. View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Call for volunteers
Hi, As you know, a number of people expressed interest on releasing a new dot version of tomcat3. They believe that the changes made so far to the main branch are making the code more maintainable and faster than 3.2. This cannot happen without your help. Before making an official proposal and asking for a vote, I need to have an idea about how much help can I get from tomcat commiters, non-commiters and users. Help is needed in the following areas: 1. Bug fixes. At least 3 commiters will volunteer to integrate the patches that are sent and do fixes them-self. 2. Bug reports/verification: we have a large number of bug reports, most of them against previous versions of tomcat. We need people to look at the bugs, try to reproduce them in the proposed 3.3, try to fix them. If possible, we need a simple reproduction code that can be added to the regression suite. 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 4. Testing/Building/mod_jk: If you use tomcat with a web server, we need help making sure it works fine and eventually getting a compiled version of mod_jk for your platform ( if you use a "special" OS or configuration ). 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) 6. Jasper: making sure the bugs are integrated and the interceptor works as expected, instead of just being faster. 7. User support/documentation: If you managed to get tomcat3 working, you may be able to help others and reduce the load on commiters. If you are a user of tomcat 3.2 or embed tomcat 3.2 in your applications, this is a chance to turn into a contributor and then commiter. The help can range from downloading a milestone and running the provided regression tests on your platform, writing simple fixes for the problems that bother you, just looking at the source code and sending feedback or small documentation, testing you favorite web application and making sure it'll still work fine. Based on the response I get on this mail during the next few days I'll decide if I go ahead and make the proposal. This is not an "official" vote - just a show of hands to help the commiters that will vote +1 get an idea about how much help they can expect ( and maybe change their vote :-). Any help is important - and there are many ways you can do it. This mail doesn't "commit" yourself to anything - I'm asking for your intention to help and what would you like to help with. -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
Ciao a tutti, hi to you Costin: i can help for points 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) enjoy Andrea Barbieri - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Call for volunteers
From the user side I'll help with 4,7 as much as I can. (Solaris 8 sparc, x86 - HP-UX 11 possible) -- Mike Braden CNE, MCP+I, MCSE, CCNA, Sun Comp 2k Enterprise E10k Utenzi 808 Aviation Parkway Suite 1100 PO Box 13479 Research Triangle Park, NC 27709 [EMAIL PROTECTED] -Original Message- 1. Bug fixes. At least 3 commiters will volunteer to integrate the patches that are sent and do fixes them-self. 2. Bug reports/verification: we have a large number of bug reports, most of them against previous versions of tomcat. We need people to look at the bugs, try to reproduce them in the proposed 3.3, try to fix them. If possible, we need a simple reproduction code that can be added to the regression suite. 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 4. Testing/Building/mod_jk: If you use tomcat with a web server, we need help making sure it works fine and eventually getting a compiled version of mod_jk for your platform ( if you use a "special" OS or configuration ). 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) 6. Jasper: making sure the bugs are integrated and the interceptor works as expected, instead of just being faster. 7. User support/documentation: If you managed to get tomcat3 working, you may be able to help others and reduce the load on commiters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Call for volunteers
1. Bug fixes. At least 3 commiters will volunteer to integrate the patches that are sent and do fixes them-self. +1 2. Bug reports/verification: we have a large number of bug reports, most of them against previous versions of tomcat. We need people to look at the bugs, try to reproduce them in the proposed 3.3, try to fix them. If possible, we need a simple reproduction code that can be added to the regression suite. +0 (mod_jk) 4. Testing/Building/mod_jk: If you use tomcat with a web server, we need help making sure it works fine and eventually getting a compiled version of mod_jk for your platform ( if you use a "special" OS or configuration ). +1 (+ packaging RPM) 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) +1 7. User support/documentation: If you managed to get tomcat3 working, you may be able to help others and reduce the load on commiters. +1 Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
Costin, Although I don't think I'll have enough time to reproduce and fix general bugs which have been submitted, I will happily commit to working on any mod_jk / ajp13 issues which come up. In other words, I don't think I can be part of the core "release team", but I will definitely contribute whatever expertise I have in the connector area. -Dan [EMAIL PROTECTED] wrote: Hi, As you know, a number of people expressed interest on releasing a new dot version of tomcat3. They believe that the changes made so far to the main branch are making the code more maintainable and faster than 3.2. This cannot happen without your help. Before making an official proposal and asking for a vote, I need to have an idea about how much help can I get from tomcat commiters, non-commiters and users. -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
Costin, I was planning on doing #4 (along with the netscape plugin) for NetWare. Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 01/19/01 09:05AM snip... 4. Testing/Building/mod_jk: If you use tomcat with a web server, we need help making sure it works fine and eventually getting a compiled version of mod_jk for your platform ( if you use a "special" OS or configuration ). snip... -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
I'd be glad to help with the servlet engine code. At 5:31 PM + 01/19/2001, Andrea Barbieri wrote: Ciao a tutti, hi to you Costin: i can help for points 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) enjoy Andrea Barbieri - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Dr. Brad Cox; [EMAIL PROTECTED] Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 http://superdistributed.com: A new paradigm for a new millinneum PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Interceptors
Jon Stevens wrote: on 1/18/01 4:28 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: If you change the names and parameter orders a little, you have just quoted the new api for javax.servlet.Filter in the 2.3 Proposed Final Draft. I'd be game to change the Valve APIs to conform to this kind of pattern in a 4.1 timeframe, if people prefer it. If we're ever going to do this, earlier is better (before too many valves that have to be changed get created). I'm almost thinking that this should be done for 4.0 because 4.0 is going to be implementing the 2.3 spec and having two different filtering mechanism's doing essentially the same thing doesn't make much sense to me... I can sympathize with that concern -- I really really don't want to go changing fundamental APIs in dot releases the way that 3.x has. Note, I'm not volunteering to scratch this itch...I'm just giving an opinion. Thanks a bunch :-) Craig, can you make a statement about how hard/timeframe it would be to make the two different filtering mechanism's match up? Effort requirements are probably 4-6 hours for development and execution for changing the implementation plus all the existing valves. Impact on the overall 4.0 release cycle is more problematic -- I think we would want to do this in a new beta round and add a week of intensive testing to make sure nothing got destabilized. Let me work up a specific proposal (with impact estimates) and I propose it later today. There will also be a different proposal (based on input from Glenn) for a "facade" layer that will make it easier to do the security manager stuff -- I would want to do both sets of changes together if we're going to do them. thanks, -jon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugRat Report #804 has been filed.
BugRat Mail System wrote: Bug report #804 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/804 REPORT #804 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: 3.2 final release JVM Release: 1.2.2 Operating System: Win NT OS Release: 4.0 ServPack 6 Platform: Intel Synopsis: java expression not translates in attribute value Description: %@ taglib uri="/atl" prefix="atl" % jsp:useBean id="PbPb" scope="session" class="at.alcatel.gcca.beans.pinboard.PbPinboard" / html atl:Menu name="xxPinboard" type="at.alcatel.gcca.beans.pinboard.PbPinboardStructure" vector="%=PbPb.getPinboards(\"chris\")%" atl:MenuLink text="%= xxPinboard.PbName %" link="%=new String(\"Messages.jsp?pinboardId=\"+xxPinboard.PbId)%" / atl:MenuLink text="%= xxPinboard.PbName %" link="Messages.jsp?pinboardId=%= xxPinboard.PbId%" / /atl:Menu /html In the above there are 2 MenuLink tags. The second one with 'link="Messages.jsp?pinboardId=%= xxPinboard.PbId%"' was the planed version, but it does not evaluate the xxPinboard.PbId. If I write it as in the first version (with new String) it works, but it is unreadable. The JSP spec doesn't support mixing static text and JSP expressions in an attribute value. An alternative way to get what you want is this: atl:MenuLink text="%= xxPinboard.PbName %" link='%= "Messages.jsp?pinboardId" + xxPinboard.PbId %' / Note that you can use single quotes around the attribute value so you don't have to escape double quotes in the value. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugRat Report #804 has been filed.
Hans, can you stick this tip in BugRat as a comment and close the bug out? On Fri, 19 Jan 2001, Hans Bergsten wrote: Note that you can use single quotes around the attribute value so you don't have to escape double quotes in the value. Hans -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
[EMAIL PROTECTED] wrote: 6. Jasper: making sure the bugs are integrated and the interceptor works as expected, instead of just being faster. I can review and fix bugs here. Don't have time for anything else. -- Peace, Anil +:-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug with mod_jk and Tomcat?
Dear Tomcat developers,
We are using Tomcat/Apache with mod_jk.
Apache (1.3.14) is running mod_ssl (2.7.1-1.3.14) with OpenSSL (0.9.6).
Tomcat 3.2.1
When a servlet is requested under
https://www.mydomain.com:/test/MyServlet
and the servlet does a simple
response.sendRedirect("loginfailed.html");
this makes the browser request
http://www.mydomain.com:/test/loginfailed.html
At this point Apache complains since the browser is trying to speak HTTP to
an HTTPS enabled port. We are also missing all the URL information that you
normally get from the Sevlet request, like getPathURI etc
any idea why this is happening?
Filip
~
Namaste - I bow to the divine in you.
~
Filip Hanik
Technical Architect
[EMAIL PROTECTED]
- Original Message -
From: "Anil Vijendran" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 19, 2001 10:28 AM
Subject: Re: Call for volunteers
[EMAIL PROTECTED] wrote:
6. Jasper: making sure the bugs are integrated and the interceptor works
as expected, instead of just being faster.
I can review and fix bugs here. Don't have time for anything else.
--
Peace, Anil +:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
I'd like to review code, if only to understand the inner workings in Tomcat. Of course, I'd like to test our application -- it's a load tester, so performance is critical. Cheers, Alex. Paulo Gaspar wrote: I can help with these ones (3 and 5) and maybe a bit with "7. User support/documentation" Have fun, Paulo Gaspar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 17:05 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Interceptors
on 1/19/01 9:38 AM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Impact on the overall 4.0 release cycle is more problematic -- I think we would want to do this in a new beta round and add a week of intensive testing to make sure nothing got destabilized. Remember that Sun does not control the 4.0 release cycle. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Interceptors
Jon Stevens wrote: on 1/19/01 9:38 AM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Impact on the overall 4.0 release cycle is more problematic -- I think we would want to do this in a new beta round and add a week of intensive testing to make sure nothing got destabilized. Remember that Sun does not control the 4.0 release cycle. Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we agreed in the release plan to have a feature freeze / bug fix round on 4.0, and work towards a production quality release quickly. API surgery is not something normally done late in a cycle like this. That is why it needs to be discussed (and voted on, IMHO) before we change what was previously agreed to on TOMCAT-DEV. -jon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Craig, These design goals are AWESOME. It makes much more sense to do this way. However, I _did_ do this as you mentioned: I have *.jsp and *.j mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was the output of index.jsp as something Netscape had to download. telnetting to the webserver port revealed that the index.jsp was being served by Apache, not Catalina. I'll mess around with it this weekend and see if I can get it to work "as advertised" and report back my results, but I have a couple of guys waiting on a servlet container that works with our *.j framework to test today, so I'm temporarily falling back to 3.2. I'm really happy that this approach is being followed as it's much more (ultimately) intuitive than the way it's done in 3.2 because it's simpler. Thanks again, -Nick On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? The design goals for mod_webapp say that it should respect web.xml mappings -- in other words, if you added a servlet-mapping entry for "*.foo" to a particular servlet, then that is what would happen at runtime. I totally do not understand this! I'm dense or something: How does Apache / DSO* know about something in the web.xml? This is the key architectural difference between mod_webapp and the current generation of connectors. When mod_webapp establishes its initial connection from Apache to Tomcat, the configuration information (extracted from the property getters of the internal Context object) is sent back to the connector in order to configure everything about this particular webapp. From the sysadmin perspective, this means we can forget all about having to configure things twice (once in httpd.conf and once in web.xml). It's also a requirement of the 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the combination) must still obey all the servlet spec requirements, including respecting things in web.xml. If I grok you, this still relies on having /foo mapped to the servlet container in Apache. I'm in a situation where Apache's DocumentRoot _is the same as_ the top level of the WAR, but I want Apache to serve the *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp and a special mapping (in this case *.j). Then what you'd want is to configure the ROOT webapp to have a context base equal to your Apache document root. If you want things mapped to servlets, just do them with servlet-mapping entries *exactly* like you would for Tomcat stand-alone. As I mentioned earlier, the connector takes over the "default servlet" mapping, so it will handle everything that is *not* explicitly mapped to a servlet (i.e. all the static files). Again, this is all the design goals -- I have not tested the current implementation to see if it achieves these goals yet. In particular, I recall seeing bug reports about mapping the ROOT context. The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind Apache is the mapping for the "default" servlet. In the stand-alone case, this is mapped to the Tomcat servlet that serves static resources. In the connected case, they would be served by Apache. I don't see how this works in my case. I'm being dense, I think. If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j files to a particular servlet like this (in your webapp's web.xml file): servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.mypackage.MyServlet/servlet-class /servlet servlet-mapping servlet-nameMyServlet/servlet-mapping url-pattern*.j/url-pattern /servlet-mapping and this rule would get applied to all incoming requests -- a request for "foo.j" would be sent to your servlet, while a request for "foo.html" would be handled by the default file-serving servlet. In Tomcat4+Apache, you do *exactly* the same thing. The only difference at runtime is that Apache becomes the "default file-serving servlet" instead of the servlet inside Tomcat. Does that help? At any rate, this is the theory -- Pier can comment on current practice. I know he's working on a bunch of bug fixes for the originally reported problems. Craig I would like to have it work in my case, but in order for me to help make it happen, I need to understand the goal, which I don't understand. If you or Pier can nurse me along a bit, I will work on making it happen in my case (I do know C) and give it back to the community. Thanks a ton anyway, Craig. -- Nicolaus Bauman
Re: Interceptors
on 1/19/01 11:51 AM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we agreed in the release plan to have a feature freeze / bug fix round on 4.0, and work towards a production quality release quickly. API surgery is not something normally done late in a cycle like this. That is why it needs to be discussed (and voted on, IMHO) before we change what was previously agreed to on TOMCAT-DEV. I thought that this is what we are discussing right now. :-) I'm +1 on doing API surgery at this point...especially given that you are doing development towards a release of Tomcat 4.x based on a Servlet API version that isn't release either. :-) What if the Servlet API changes tomorrow? That would be more API surgery as well IMHO. Also, given that this would be surgery towards making things more compatible with the Servlet API, I think that it is more than justified. :-) -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Nick Bauman wrote: Craig, These design goals are AWESOME. It makes much more sense to do this way. However, I _did_ do this as you mentioned: I have *.jsp and *.j mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was the output of index.jsp as something Netscape had to download. telnetting to the webserver port revealed that the index.jsp was being served by Apache, not Catalina. I'll mess around with it this weekend and see if I can get it to work "as advertised" and report back my results, but I have a couple of guys waiting on a servlet container that works with our *.j framework to test today, so I'm temporarily falling back to 3.2. I'm really happy that this approach is being followed as it's much more (ultimately) intuitive than the way it's done in 3.2 because it's simpler. I'm glad you like it, although you should really thank Pier Fumagalli -- it's his vision (which I agree with) and effort that has really been working towards this. As I mentioned several times, what I was describing is the *theory* of what mod_webapp is supposed to accomplish. To ensure that it becomes *reality*, please feel free to volunteer your time (as you did above) in testing the current connector, identifying places where there are bugs, posting patches, etc. I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Thanks again, -Nick Craig On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? The design goals for mod_webapp say that it should respect web.xml mappings -- in other words, if you added a servlet-mapping entry for "*.foo" to a particular servlet, then that is what would happen at runtime. I totally do not understand this! I'm dense or something: How does Apache / DSO* know about something in the web.xml? This is the key architectural difference between mod_webapp and the current generation of connectors. When mod_webapp establishes its initial connection from Apache to Tomcat, the configuration information (extracted from the property getters of the internal Context object) is sent back to the connector in order to configure everything about this particular webapp. From the sysadmin perspective, this means we can forget all about having to configure things twice (once in httpd.conf and once in web.xml). It's also a requirement of the 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the combination) must still obey all the servlet spec requirements, including respecting things in web.xml. If I grok you, this still relies on having /foo mapped to the servlet container in Apache. I'm in a situation where Apache's DocumentRoot _is the same as_ the top level of the WAR, but I want Apache to serve the *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp and a special mapping (in this case *.j). Then what you'd want is to configure the ROOT webapp to have a context base equal to your Apache document root. If you want things mapped to servlets, just do them with servlet-mapping entries *exactly* like you would for Tomcat stand-alone. As I mentioned earlier, the connector takes over the "default servlet" mapping, so it will handle everything that is *not* explicitly mapped to a servlet (i.e. all the static files). Again, this is all the design goals -- I have not tested the current implementation to see if it achieves these goals yet. In particular, I recall seeing bug reports about mapping the ROOT context. The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind Apache is the mapping for the "default" servlet. In the stand-alone case, this is mapped to the Tomcat servlet that serves static resources. In the connected case, they would be served by Apache. I don't see how this works in my case. I'm being dense, I think. If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j files to a particular servlet like this (in your webapp's web.xml file): servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.mypackage.MyServlet/servlet-class /servlet servlet-mapping servlet-nameMyServlet/servlet-mapping url-pattern*.j/url-pattern /servlet-mapping and this rule would get applied to all incoming requests -- a request for "foo.j" would be sent to your servlet, while a request for "foo.html" would be handled by the default
Re: Call for volunteers
[EMAIL PROTECTED] wrote: [...] This mail doesn't "commit" yourself to anything - I'm asking for your intention to help and what would you like to help with. I think this is a great way to get a feel for the amount of support before putting it up for a formal vote. Based on the number of answers I've seen so far, I assume that it will be put up for a vote soon. I ask, however, that you wait with that until we have an agreement on how to interpret our decision guidelines (or amend them if needed) for a vote on a Release Plan. I want to avoid a "Florida recount situation", where the rules are being made up while the votes are counted ;-) There's a thread with the subject "Release voting rules" on the General list. I ask that all Committers, especially PMC members, join the discussion there so that we can get this clarified ASAP and move on. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Interceptors
Quoting Jon Stevens [EMAIL PROTECTED]: on 1/19/01 11:51 AM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we agreed in the release plan to have a feature freeze / bug fix round on 4.0, and work towards a production quality release quickly. API surgery is not something normally done late in a cycle like this. That is why it needs to be discussed (and voted on, IMHO) before we change what was previously agreed to on TOMCAT-DEV. I thought that this is what we are discussing right now. :-) I'm +1 on doing API surgery at this point... Ok, I've thought about the issue, and I don't really like the change from Valves to Filters, because I have the following concerns : - Valves are internal. They access internal objects. Making them filters will lead to more typecasting and more rtti. - I'd like a clarification on how much response and request wrapping would occur. Basically, all internal filters should be able to mutate freely either the request object or the response object by typecasting the request and the response. I don't see anything preventing this if we're inside the servlet container (except what the servlet API says). Do you think either of these is justified ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Valve APIs
Quoting "Craig R. McClanahan" [EMAIL PROTECTED]:
THE PROPOSED DESIGN PATTERN:
This is an adaptation of the pattern that Peter Donald proposed
yesterday, to be
slightly more aligned with the Filter API:
public interface Valve {-- similar to javax.servlet.Filter
public Container getContainer();-- Many valves need this
public void setContainer(Container container);
public void invoke(Request request, Response response,
Pipeline pipeline) throws IOException, ServletException
}
and the typical usage pattern in invoke() would be
... preprocess the request ...
pipeline.invoke(request, response);
... postprocess the response ...
where the pipeline would manage the details of where the current request
is in
the set of Valves to be processed, handles the "falling off the end"
problem,
and so on.
IMPACT OF CHANGE:
The following changes would be required inside the Tomcat 4.0 source
repository
(I would be willing to undertake this, if the proposal is approved,
unless some
other committer would like to volunteer instead):
* Rewrite the existing Pipeline and Valve interfaces
* Create standard Pipeline implementation class(es) that
can be used by all containers, including support for pooling
if that approach is selected.
* Modify all existing Container and Valve implementations to
utilize the new APIs. In most cases, these changes would
be simplifications in the common ContainerBase and ValveBase
classes, although each individual Valve would need to have
its invoke() method signature and the way it invokes the next
Valve in the pipline updated to the new APIs
* Release of a second beta that incorporates this change, to allow
regression testing and make sure nothing got broken along the way.
* After completion, forward port to the 4.1 repository to maintain
compatibility.
RECOMMENDATION:
I recommend that we do this change, and do it in 4.0 (rather than
waiting for
4.1). The revised design pattern is cleaner and easier for Valve
implementors,
and doing this in 4.0 would avoid an incompatible API change between 4.0
and
4.1.
What do you think?
+1.
Forget about my other email : this one clarified everything.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Interceptors
Remy Maucherat wrote: Quoting Jon Stevens [EMAIL PROTECTED]: on 1/19/01 11:51 AM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Agreed ... I'm talking about the *Apache Tomcat* release cycle, where we agreed in the release plan to have a feature freeze / bug fix round on 4.0, and work towards a production quality release quickly. API surgery is not something normally done late in a cycle like this. That is why it needs to be discussed (and voted on, IMHO) before we change what was previously agreed to on TOMCAT-DEV. I thought that this is what we are discussing right now. :-) I'm +1 on doing API surgery at this point... Ok, I've thought about the issue, and I don't really like the change from Valves to Filters, because I have the following concerns : - Valves are internal. They access internal objects. Making them filters will lead to more typecasting and more rtti. As you will see from the proposal, I'm not suggesting we actually use filters. In particular, the request and response objects passed to Valves are the internal ones (org.apache.catalina.Request / org.apache.catalina.Response) to maintain access to the internals. As you note, Valves are for internal things and Filters are for application things. The proposal is to make the two APIs structurally similar, but still recognize the differences. - I'd like a clarification on how much response and request wrapping would occur. Basically, all internal filters should be able to mutate freely either the request object or the response object by typecasting the request and the response. I don't see anything preventing this if we're inside the servlet container (except what the servlet API says). The arguments to Valve.invoke() are still the internal request and response objects, just as they are today. Although I didn't mention it earlier, the Filter API allows for wrapping request and response objects (such as when a servlet uses them in a RequestDispatcher). The current Valve implementation already supports wrapping in a very similar manner, although in practice it will not be needed often - because a Valve can mutate the request and response objects to some degree, while a Filter cannot. You would still need to wrap the response, for example, if your Valve wanted to modify the data content of the response (such as applying compression, or an XSLT transformation). However, you should choose to implement functionality like this as a Filter if you can, for maximum portability, and reserve Valve implementations for implementing internal-to-Tomcat functionality. Do you think either of these is justified ? Remy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Stay Tuned...
I've been a bit silent in these days after the PMC meeting.. I've been preparing for a big trip to Dublin/Prague/NYC+LinuxWorld over the next two weeks. Luckily I'll be stuck on a plane for 10 hours later today and will be catching up with all email. Replys will flow in from Dublin. :) Just FYI -- I hate being silent for too long.. :) Also, if anybody in Dublin/Prague/NYC would like to get together and chat, my schedule may permit such meetings (over beer of course!). Send me private mail if you are interested and we'll see what can happen. .duncan -- James Duncan Davidson[EMAIL PROTECTED] !try; do() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
BACKGROUND:
One of the unique (AFAIK) features of Tomcat 3.2 as a servlet container is the
fact that you can choose to run Tomcat under a Java SecurityManager (when
running under a Java2 JDK), with corresponding fine-grained control over the
resources that a particular web application can access. In addition, the
security manager can be used to constrain an application from accessing Tomcat
internals (for example, by trying to cast the HttpServletRequest it receives
back to the Tomcat internal implementation class).
This feature has long been on the wish list for 4.0, and recently Glenn Nielsen
[EMAIL PROTECTED] has volunteered to complete it. Those involved in
3.2 will recall that Glenn was also the primary "mover and shaker" in
implementing the security manager feature there.
Currently, as a stopgap security measure, Tomcat 4.0's web application
classloader implements some specific restrictions on access to particular Java
packages -- for example, an application level class is not allowed to load any
class in the org.apache.catalina.* hierarchy. While this does indeed protect
the internal implementation classes, it becomes redundant once running under a
security manager is installed -- the checkPackageAccess() method serves this
purpose in a much more powerful and controlled approach.
THE CURRENT SITUATION:
Currently, the internal object that implements the Java Servlet API objects
exposed to application components implement the corresponding API interfaces
directly. For example:
public class StandardSession
implements HttpSession, Session, Serializable {
...
}
so that, when an application calls request.getSession, an instance of this class
(suitably cast to HttpSession) is returned. The application cannot cast the
returned object to an org.apache.catalina.session.StandardSession, because of
the customized restrictions implemented in the web application class loader.
Switching to the security manager for protection requires a change in this
approach, because the security permissions of a StandardSession are based on
where *that* class was loaded from, and not from the interfaces it implements.
THE PROPOSAL:
For each Servlet API interface that represents an internal Catalina object
exposed to an application object, create a new
org.apache.catalina.facade.XFacade class according to the following basic
pattern:
* Pass the internal object to the constructor (the facade
will be a wrapper around it).
* Implement the appropriate servlet API interface (so the
facade object can be passed to application components)
* For each public method in the interface, implement a doPrivileged
block that calls the corresponding method on the underlying
internal Catalina object.
For example, the session facade object would look something like this:
package org.apache.catalina.facade;
import javax.servlet.http.HttpSession;
import org.apache.catalina.Session;
public class SessionFacade implements HttpSession {
protected Session session = null;
public SessionFacade(Session session) {
super();
this.session = session;
}
public String getId() {
AccessController.doPrivileged(
new PrivilegedAction()
{
public Object run() {
return (session.getId());
}
}
);
}
... same pattern for all other public methods ...
}
Additionally, the logic that implements request.getSession() would be modified
to look up and return the facade object associated with the current session,
instead of the actual StandardSession object itself.
RECOMMENDATION:
Implementing the remainder of the security manager logic in Tomcat 4.0 was part
of the agreed-upon original release plan, and Glenn has volunteered to undertake
the other changes necessary to Catalina and Jasper to make this happen (and
there are lots of them -- thanks Glenn!). It seems that adding the facade
classes, according to the pattern described above, will be necessary to complete
this work.
Therefore, I feel we should implement this change in Tomcat 4.0, and create a
new beta to allow testing of the results. This can be done in the same beta
release with the changes for the Valve API if that is also agreed upon.
However, I'm currently committed on other activities. In order to achieve these
changes in a timely manner, I'm looking for a volunteer to implement these
changes, if the proposal is accepted.
Comments?
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Interceptors
Quoting "Craig R. McClanahan" [EMAIL PROTECTED]: You would still need to wrap the response, for example, if your Valve wanted to modify the data content of the response (such as applying compression, or an XSLT transformation). Ok. BTW, I think compression should be part of the HTTP connector. Every modern browser out there sends accept-encoding headers with the appropriate value : - IE 5 sends : gzip, deflate - Mozilla sends : gzip,deflate,compress,identity - Netscape 4.7 sends : gzip So roughly 95% of the requests will be wrapped by a compression valve. I also think that compression should be considered basic functionality. However, you should choose to implement functionality like this as a Filter if you can, for maximum portability, and reserve Valve implementations for implementing internal-to-Tomcat functionality. Makes a lot of sense. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Catalina + Apache
I'd like to see the fixes for mod_webapp about cookies. I've asked many time on the list about the problem but never got any answers -( "...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 11:03 PM To: [EMAIL PROTECTED] Subject: Re: Catalina + Apache on 1/19/01 12:21 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I know Pier has a bunch of bugfixes currently in his local CVS tree, so hopefully we will be much closer to the "reality" end of the scale soon. Why isn't development happening in public? Having local CVS tree does not encourage community development. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
+1 I'm using Tomcat 3.2 on several production sites and I'm not ready to switch to 4.x yet. I'm sorry I haven't had the time to contribute like I did last summer, but I'll see if I can scrounge up some non-billable hours. At any rate, I can definitely help with app testing, and hopefully with code review. - A -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Quoting "Craig R. McClanahan" [EMAIL PROTECTED]: org.apache.catalina.facade.XFacade Nice package name. I wonder where you got it :) * Pass the internal object to the constructor (the facade will be a wrapper around it). * Implement the appropriate servlet API interface (so the facade object can be passed to application components) * For each public method in the interface, implement a doPrivileged block that calls the corresponding method on the underlying internal Catalina object. +0. I would wrap the request and response using the facades at the last moment, just before going into the filter pipeline. That way, we only need to implement the standard servlet API functions in the facade. Would that work ? RECOMMENDATION: Therefore, I feel we should implement this change in Tomcat 4.0, and create a new beta to allow testing of the results. This can be done in the same beta release with the changes for the Valve API if that is also agreed upon. Since it's the API changes day, may I then suggest that we just merge back all the changes done so far in 4.1, which deal with replacing the resources package with JNDI context. It works, and it's solid. I don't feel like we should leave a whole deprecated package in there, that we'll have to support anyway. However, I'm currently committed on other activities. In order to achieve these changes in a timely manner, I'm looking for a volunteer to implement these changes, if the proposal is accepted. Comments? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Craig R. McClanahan typed the following on 02:00 PM 1/19/2001 -0800
THE PROPOSAL:
For each Servlet API interface that represents an internal Catalina object
exposed to an application object, create a new
org.apache.catalina.facade.XFacade class according to the following basic
pattern:
* Pass the internal object to the constructor (the facade
will be a wrapper around it).
* Implement the appropriate servlet API interface (so the
facade object can be passed to application components)
* For each public method in the interface, implement a doPrivileged
block that calls the corresponding method on the underlying
internal Catalina object.
Sounds cool. If the application doesn't use the security manager,
will the object simply continue "raw" without being wrapped by
the facade to avoid the added overhead? e.g:
// Raw session
Session mySession = whatever;
if (security_enabled) {
mySession = new SessionFacade (mySession);
}
// Raw or facade session, doesn't really matter
mySession.doStuff();
Kief
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
On Fri, 19 Jan 2001, Remy Maucherat wrote: Since it's the API changes day, may I then suggest that we just merge back all the changes done so far in 4.1, which deal with replacing the resources package with JNDI context. It works, and it's solid. I don't feel like we should leave a whole deprecated package in there, that we'll have to support anyway. So what do we need a 4.1 branch for then? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Kurt Schrader wrote: On Fri, 19 Jan 2001, Remy Maucherat wrote: Since it's the API changes day, may I then suggest that we just merge back all the changes done so far in 4.1, which deal with replacing the resources package with JNDI context. It works, and it's solid. I don't feel like we should leave a whole deprecated package in there, that we'll have to support anyway. So what do we need a 4.1 branch for then? If we take the action Remy recommends, we won't. I'm +1 for this (it will certainly reduce the effort of double-committing all the changes), if we're willing to accept the fact that it will increase the time before a 4.0 production quality release is ready. The 4.1 branch was originally created because of a "feature freeze" on 4.0. The various proposals today are effectively to "unfreeze" the 4.0 branch, so that some new functionality (already committed on the 4.1 branch) can get moved into 4.0 instead, along with the other proposed changes that would otherwise need to be posted to both. We can recreate the 4.1 branch at some future point when 4.0 is refrozen. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
sendRedirect to PDF - repeats 3 times?
Hello
all,I am experiencing a strange error, and I'm hoping someone can point
me in the right direction.Using Tomcat 3.2.1 or the latest 3.3, I have a
simple servlet that has two lines of code in its doGet method which forwards a
request to a pdf: System.out.println("Forwarding to the
PDF...");response.sendRedirect("http://localhost:8080/campus/pdf/iep.pdf");When I use IE 5.0 (version
5.00.2920.) and hit the servlet with a GET request, the servlet executes
three times and then fails to redirect to the pdf.The weird thing is
this doesnt happen in IE 5.5 and it doesnt happen in Netscape. I need to
get this fixed, and I was hoping someone could point me at the code I need to
work with.Thanks,Dave
Frankson
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Quoting "Craig R. McClanahan" [EMAIL PROTECTED]: Kurt Schrader wrote: So what do we need a 4.1 branch for then? If we take the action Remy recommends, we won't. I'm +1 for this (it will certainly reduce the effort of double-committing all the changes), if we're willing to accept the fact that it will increase the time before a 4.0 production quality release is ready. Given the delay caused by the security manager support inclusion and the Valve modifications, it won't probably cause any additional delay. The 4.1 branch was originally created because of a "feature freeze" on 4.0. The various proposals today are effectively to "unfreeze" the 4.0 branch, so that some new functionality (already committed on the 4.1 branch) can get moved into 4.0 instead, along with the other proposed changes that would otherwise need to be posted to both. We can recreate the 4.1 branch at some future point when 4.0 is refrozen. Agreed. It that case, I suggest that the 4.1 branch be merged back ASAP. Having a non- beta quality web connector in a beta wasn't a good thing anyway, IMO. I wrongly interpreted the proposal on the security manager, as I was answering an email dealing with i18n at the same time (so I'm +1 now). As Kief suggested, I think that no wrapping should occur if no security manager is present (common sense). There is also a code change needed to provide proper i18n support. Instead of putting in a hack in 4.0 to get around one half of the issue, I suggest instead that some code is moved from the connector.http package to the connector package (some buffers, as well as some code which needs to be merged into HttpRequestBase). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
sendRedirect, include and forward don't work with mod_jk and non standard ssl port
neither of the above functions work properly when I am using a non standard port for https (ex: 445 instead of 443) Apache 1.3.14 Tomcat 3.2.1 + mod_jk.so Open SSL 0.9.6 mod_ssl 2.7.?-1.3.14 any idea why this is happening? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Remy Maucherat" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 3:25 PM Subject: Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades Quoting "Craig R. McClanahan" [EMAIL PROTECTED]: Kurt Schrader wrote: So what do we need a 4.1 branch for then? If we take the action Remy recommends, we won't. I'm +1 for this (it will certainly reduce the effort of double-committing all the changes), if we're willing to accept the fact that it will increase the time before a 4.0 production quality release is ready. Given the delay caused by the security manager support inclusion and the Valve modifications, it won't probably cause any additional delay. The 4.1 branch was originally created because of a "feature freeze" on 4.0. The various proposals today are effectively to "unfreeze" the 4.0 branch, so that some new functionality (already committed on the 4.1 branch) can get moved into 4.0 instead, along with the other proposed changes that would otherwise need to be posted to both. We can recreate the 4.1 branch at some future point when 4.0 is refrozen. Agreed. It that case, I suggest that the 4.1 branch be merged back ASAP. Having a non- beta quality web connector in a beta wasn't a good thing anyway, IMO. I wrongly interpreted the proposal on the security manager, as I was answering an email dealing with i18n at the same time (so I'm +1 now). As Kief suggested, I think that no wrapping should occur if no security manager is present (common sense). There is also a code change needed to provide proper i18n support. Instead of putting in a hack in 4.0 to get around one half of the issue, I suggest instead that some code is moved from the connector.http package to the connector package (some buffers, as well as some code which needs to be merged into HttpRequestBase). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
The case of the disappearing webapps...
Howdy, I have some weird behavior with tomcat-4.x ( both 4.0 and 4.1 from cvs ) if I do the following: * place a .war file in the webapps directory ( in this case the struts .war files ). * startup catalina normally...everything works fine. * shutdown catalina. * startup catalina again normally. the expanded directories corresponding to the .war files now are missing all content...the only things that remain are the *.xml and *.tld files in the WEB-INF directory. I haven't yet submitted a bug report, as I wanted to make sure this wasn't a known-issue and possibly locate the source of the problem first. Has anyone else had this problem or anything like it yet? David Weinrich note: the system this is running on is Win2k and jdk/jre 1.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan Filip Hanik wrote: neither of the above functions work properly when I am using a non standard port for https (ex: 445 instead of 443) Apache 1.3.14 Tomcat 3.2.1 + mod_jk.so Open SSL 0.9.6 mod_ssl 2.7.?-1.3.14 any idea why this is happening? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
ajp12 should I try ajp13? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Dan Milstein" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 4:18 PM Subject: Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan Filip Hanik wrote: neither of the above functions work properly when I am using a non standard port for https (ex: 445 instead of 443) Apache 1.3.14 Tomcat 3.2.1 + mod_jk.so Open SSL 0.9.6 mod_ssl 2.7.?-1.3.14 any idea why this is happening? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
this is what happens, the sendRedirect or include or forward switches the url from saying https to say http even though the port is http /Filip Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://rpit.ratexchange.net:9701/ Apache/1.3.14 Server at rpit.ratexchange.net Port 9701 ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Dan Milstein" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 4:18 PM Subject: Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan Filip Hanik wrote: neither of the above functions work properly when I am using a non standard port for https (ex: 445 instead of 443) Apache 1.3.14 Tomcat 3.2.1 + mod_jk.so Open SSL 0.9.6 mod_ssl 2.7.?-1.3.14 any idea why this is happening? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Remy Maucherat wrote: Quoting "Craig R. McClanahan" [EMAIL PROTECTED]: org.apache.catalina.facade.XFacade Nice package name. I wonder where you got it :) :) Unless I understand wrong, isn't a "facade" already a well known feature that allows Tomcat 3.x to use more than one different version of the Servlet API? Am I wrong and it does more than just that? If I'm right, that means you're proposing to use the name "facade" in the Tomcat 4 codebase to have a completely different meaning, right? If this is the case, could we instead use a different name? I'm not sure what name I would use.. "sandbox" maybe? -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: The case of the disappearing webapps...
Ok, I think I have found the problem, and I am guessing the following is happening: 19-Jan-2001 15:10:44 StandardHost[localhost]: Undeploying web application at context path /struts-test 19-Jan-2001 15:10:44 StandardHost[localhost]: Removing expanded directory c:\java\tomcat-4.1\webapps\struts-test * the container is trying to undeploy the application ( hey I didn't even know this happened ;) because it was deployed from a .war file. 19-Jan-2001 15:10:44 HostConfig[localhost] Error undeploying web application at context path /struts-test java.io.IOException: Cannot delete file c:\java\tomcat-4.1\webapps\struts-test\WEB-INF\lib\struts.jar at org.apache.catalina.core.StandardHost.remove(StandardHost.java:794) * Win2k is not allowing the container to delete a library file that it thinks is currently in use ( struts.jar in this case ). 19-Jan-2001 15:11:06 StandardHost[localhost]: Deploying web application at context path /struts-test from URL file:C:\java\tomcat-4.1\webapps\struts-test * catalina finds the struts-test directory and doesn't re-deploy the application from the .war file. If I shutdown, delete the expanded directories, and restart, the .war files deploy normally: 19-Jan-2001 15:56:26 StandardHost[localhost]: Recording expanded app at path /struts-test 19-Jan-2001 15:56:26 StandardHost[localhost]: Deploying web application at context path /struts-upload from URL jar:file:C:\java\tomcat-4.1\webapps\struts-upload.war!/ 19-Jan-2001 15:56:26 StandardHost[localhost]: expand(jar:file:C:\java\tomcat-4.1\webapps\struts-upload.war!/) 19-Jan-2001 15:56:26 StandardHost[localhost]: Proposed directory name: struts-upload ... I will try to dig into this more later tonight/this weekend. Any further hints/ideas would be appreciated :) David Weinrich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
I don't know if that will fix the problem, but if you could try that (i.e. using ajp13 and seeing if you still have this problem), that would definitely help me narrow this down (and since there seem to be some basic redirect problems in TC 3.2 / mod_jk, that would be very, very helpful). Thanks. -Dan p.s. What browser are you using? Filip Hanik wrote: ajp12 should I try ajp13? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Dan Milstein" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 4:18 PM Subject: Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port
Good catch, it works fine with the Ajp13 protocol. so now we know where the problem is. thanks a lot for your help Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Dan Milstein" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 4:46 PM Subject: Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port I don't know if that will fix the problem, but if you could try that (i.e. using ajp13 and seeing if you still have this problem), that would definitely help me narrow this down (and since there seem to be some basic redirect problems in TC 3.2 / mod_jk, that would be very, very helpful). Thanks. -Dan p.s. What browser are you using? Filip Hanik wrote: ajp12 should I try ajp13? Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: "Dan Milstein" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 4:18 PM Subject: Re: sendRedirect, include and forward don't work with mod_jk and non standard ssl port Filip, Which connection protocol are you using? ajp12? ajp13? jserv? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Interceptors
Damn, that is somethink I would like very much to see. Many people indent HTML with spaces - those who code by hand. Some of them (size conscious) unindent them for production and sometimes partially indent again for fixing something! And we often use "font" tags everywhere because of browsers with bad CSS support. I would feel much better about those spaces and font tags thinking how little they would weight after gziped. Ok! I know that all HTML (with all those repetitive tags) benefits a lot from compression. But for me (and those HTML coders) there is a feel good factor on gzip support. =;o) Have fun, Paulo -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 23:10 ... BTW, I think compression should be part of the HTTP connector. Every modern browser out there sends accept-encoding headers with the appropriate value : - IE 5 sends : gzip, deflate - Mozilla sends : gzip,deflate,compress,identity - Netscape 4.7 sends : gzip So roughly 95% of the requests will be wrapped by a compression valve. I also think that compression should be considered basic functionality. ... Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: sendRedirect to PDF - repeats 3 times?
Are you using TC in standalone mode?
If not, are you using mod_jk? If so, which protocol are you using for your web server
talk to Tomcat (ajp13? ajp12? jserv?). Now that I mention it, what web server are you
using?
Thanks,
-Dan
Dave Frankson wrote:
Hello all,
I am experiencing a strange error, and I'm hoping someone can point me in the right
direction.
Using Tomcat 3.2.1 or the latest 3.3, I have a simple servlet that has two lines of
code in its doGet method which forwards a request to a pdf:
System.out.println("Forwarding to the PDF...");
response.sendRedirect("http://localhost:8080/campus/pdf/iep.pdf");
When I use IE 5.0 (version 5.00.2920.) and hit the servlet with a GET request,
the servlet executes three times and then fails to redirect to the pdf.
The weird thing is this doesnt happen in IE 5.5 and it doesnt happen in Netscape. I
need to get this fixed, and I was hoping someone could point me at the code I need to
work with.
Thanks,
Dave Frankson
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Call for volunteers
Costin, It was good meeting and speaking with you at the PMC meeting. I would be more than happy to help with the following: 2. Bug reports/verification: we have a large number of bug reports, most of them against previous versions of tomcat. We need people to look at the bugs, try to reproduce them in the proposed 3.3, try to fix them. If possible, we need a simple reproduction code that can be added to the regression suite. 3. Code review/Documentation: The code is not perfect, but it should do its job. Reading the tomcat.core and making sure it's ok is essential. 4. Testing/Building/mod_jk: If you use tomcat with a web server, we need help making sure it works fine and eventually getting a compiled version of mod_jk for your platform ( if you use a "special" OS or configuration ). Solaris 7 SPARC 5. Testing your application with tomcat :-) ( this is probably a better and more important test than our regression ) 7. User support/documentation: If you managed to get tomcat3 working, you may be able to help others and reduce the load on commiters. To what degree I can help with docs, I will. Cheers, Michael Percy Portera Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
welcome-file
I tried configuring welcome-file attribute like below. welcome-file-list welcome-file HomePage.jsp /welcome-file /welcome-file-list It doesn't work. Please help. Jayesh _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/share/gtest GTest.java
costin 01/01/19 18:35:36
Added: src/tests/share/gtest GTest.java
Log:
Added missing file, needed to run the self-test ( was moved from share/
since was not a required part of tomcat, and is used only in the test
app ).
There are many enhancements needed to make it really easy to run the
tests. I guess we'll do them as we go.
I also did a small change - GTest new extends Task and uses log() instead
of System.out(). ( I'll check in a jsp file that runs the test - the change is
needed to send the output to the right destination ).
Note: this is a change to the CVS HEAD. IMHO there is nothing to stop
fixes to go in - as long as we don't call it anyway. I'll commit a number
of fixes over the weekend - including restoring the JDK1.1 build ( plus
a solution that will simplify supporting JDK1.1 ), and I'll probably finish
the .jsp taglib that runs the tests. Lazy consensus should work as before -
if anyone has a problem with any checkin, please -1 it.
Revision ChangesPath
1.1 jakarta-tomcat/src/tests/share/gtest/GTest.java
Index: GTest.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.util.test;
import java.net.*;
import java.io.*;
import java.util.*;
import java.net.*;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.BuildException;
/** Test a web application. Will send a http request and
verify the response code, compare the response with a golden
file or find strings.
*/
public class GTest extends Task {
String prefix="http://localhost:8080/test";
String host="localhost";
int port=8080;
int debug=0;
String description="No description";
String request;
Hashtable requestHeaders;
String content;
// Expected response
boolean magnitude=true;
boolean exactMatch=false;
// Match the body against a golden file
String goldenFile;
// Match the body against a string
String responseMatch;
// the response should include the following headers
Tomcat bug - corrupt library
Hi, if you add in a corrupt library to WEB-INF/lib/ then tomcat will not process the remining of the libraries (jar, zip files) and will start up without notifying you, later when you try to load a class that was in a library that didn't get loaded you get a null pointer. I had a hard time tracking this down, but finally figured out that one of our jar files got corrupt during the FTP transfer and that resulted in the a lot of jar files didn't get loaded. I would strongly recommend that Tomcat throws an exception if it can not load a jar file, or at least give some warning. let me know if you want specific examples, or more explanation Filip ~ Namaste - I bow to the divine in you. ~ Filip Hanik Technical Architect [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 19, 2001 6:35 PM Subject: cvs commit: jakarta-tomcat/src/tests/share/gtest GTest.java costin 01/01/19 18:35:36 Added: src/tests/share/gtest GTest.java Log: Added missing file, needed to run the self-test ( was moved from share/ since was not a required part of tomcat, and is used only in the test app ). There are many enhancements needed to make it really easy to run the tests. I guess we'll do them as we go. I also did a small change - GTest new extends Task and uses log() instead of System.out(). ( I'll check in a jsp file that runs the test - the change is needed to send the output to the right destination ). Note: this is a change to the CVS HEAD. IMHO there is nothing to stop fixes to go in - as long as we don't call it anyway. I'll commit a number of fixes over the weekend - including restoring the JDK1.1 build ( plus a solution that will simplify supporting JDK1.1 ), and I'll probably finish the .jsp taglib that runs the tests. Lazy consensus should work as before - if anyone has a problem with any checkin, please -1 it. Revision ChangesPath 1.1 jakarta-tomcat/src/tests/share/gtest/GTest.java Index: GTest.java === /* * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * "This product includes software developed by the *Apache Software Foundation (http://www.apache.org/)." *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software *Foundation" must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called "Apache" *nor may "Apache" appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.tomcat.util.test;
