DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 Resubmit to j_security_check mistakenly fetches a page of that name --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 10:47 --- This bug is still around in 4.1.12. And its still not cleared up in the servlet 2.4 spec. I posted a comment on the spec during the public review stage, and got this reply from Yutaka Yoshida: Thank you for the feedback and I'm sorry for being so late to get back to you. Issues you mentioned were actually brought up in the expert group, and we'll try to put them in to 2.4. again, thank you very much for the 'Suggested Resolution' (The resolutions I suggested were that either a specific exception would be thrown in this case, or that an additional standard parameter could be added to the login forms to specify where the user should be taken when this bug occurs. Another simple idea which involves no spec change is presented at the end of this comment) Unfortunately, no change made it into the final draft. It is usually standard practice to post patches in unified diff format (diff -u). I know - I really need to get into the habit of grabbing source and updating it instead of just looking at cvs.apache.org :) My understanding of the problem is that: 1. We want FormAuthenticator to mirror BasicAuthenticator as closely as possible from the user's perspective. That's what I'd like. One open concern is whether sessions should invalidate or not when you provide new credentials. This isn't the case (to the best of my knowledge) with either BASIC or DIGEST auth. 2. In BASIC authentication, when a user successfully authenticates and presses the back button, the user is returned to the page she was on before attempting to access a secured resource. If the attempt to access the secured resource is the very first page visited after opening a browser, then the Back button is unavailable. Number 2 is not reproducible using FormAuthenticator because an extra request is generated (the request for the login page). Therefore we must decide on a desired behavior for this scenario. Any takers? My point is that you cant stop the user pressing the back button and seeing the login form. RFC 2616, Section 13.13 History Lists: History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. In other words, showing the login form when you click back is /exactly/ what browsers are meant to do, and no amount of no-cache headers will help if the browser follows the spec. So, we have to deal with what happens when the user misuses the login form. One thing that would help is if TC stopped using 'redirect' to take users to the login form, and used a 'forward' instead! (this isn't a spec violation). This would mean the URL of the login form would /never/ appear in the browser. Users could bookmark the login page if they wanted, but since the bookmark would be for http://some/webapp/secure/resource instead of for http://some/webapp/login/page it wouldnt matter. The change there is much smaller than the stuff I suggested before - just to change the line: hres.sendRedirect(hres.encodeRedirectURL(loginURI)); to something like hreq.getRequestDispatcher(loginURI).forward(hreq,hres); The only remaining problem would be what happens when the user clicks the back button to see a login form. If we know we have used a forward instead of a redirect, it becomes possible for TC to guess the page they were trying to log in to from the REFERER header (since this will be the URL of the page that caused the login screen to appear in the first place). Some users will be blocking referer headers, but its better than the errors TC throws out right now. The final issue to be resolved would be what to do with a session if someone resubmits login credentials. My gut feeling is that if your principal changes your session should be invalidated first, but this could be made an option in server.xml. There is no spec to guide this issue. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
FW: R: GOODBYE from tomcat-dev@jakarta.apache.org
Who unsubbed this guy on Fri Nov 1 03:31:13 PST 2002??? 1036089107 - [EMAIL PROTECTED] It's not a probe, so, someone (one of the moderators, I believe), unsubbed him manually (see at the bottom). Any reason why? Pier -- Forwarded Message From: Luca Ventura [EMAIL PROTECTED] Date: Fri, 1 Nov 2002 11:31:43 +0100 To: [EMAIL PROTECTED] Subject: R: GOODBYE from [EMAIL PROTECTED] Hello! Why has my address been removed from the tomcat-dev mailing list? Can you subscribe it to the tomcat-dev mailing list again, please? Thanks, Luca -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:tomcat-dev-help;jakarta.apache.org] Inviato: giovedi 31 ottobre 2002 19.32 A: [EMAIL PROTECTED] Oggetto: GOODBYE from [EMAIL PROTECTED] Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. I'm working for my owner, who can be reached at [EMAIL PROTECTED] Acknowledgment: I have removed the address [EMAIL PROTECTED] from the tomcat-dev mailing list. This address is no longer a subscriber. --- I have subscribed or unsubscribed you at the request of a moderator of the [EMAIL PROTECTED] mailing list. If this is not an action you desire, please send a complaint or other comments to the list owner ([EMAIL PROTECTED]) as soon as possible. If you would like more information on how to interact with the tomcat-dev mailing list, just send an empty message to [EMAIL PROTECTED] -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14059] - HTP Response does not respond correctly to flush()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059
HTP Response does not respond correctly to flush()
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2002-11-01 12:49 ---
I have gone back and created a java client that reads the inputStream response a
char at a time:
logger.debug( opening buffered reader to read response );
InputStreamReader is = new InputStreamReader(
URLConnection.getInputStream() );
// Note: should read response to make sure no error.
String str;
int i;
StringBuffer sb = new StringBuffer();
while ( ( i = is.read() ) != -1 ) {
char c = (char)i;
logger.debug( Have a char: + c );
sb.append( c );
}
String s = sb.toString();
logger.debug( String returned is: + s );
if ( !s.startsWith( OK ) ) {
throw new RuntimeException( Server returned: + s );
}
is.close();
}
I pointed it at the Servlet test code on Tc4.0.6
Results:
2002-11-01 12:41:16,884 [GMT] DEBUG 10TestTestService [main] - Connecting
to
http://mocha.ko.kodak.com:8080/eFUSE/servlet/controller/Test?action=ReadRequestreadQueue=TestingMe
2002-11-01 12:41:16,934 [GMT] DEBUG 60TestTestService [main] - opening
buffered reader to read response
2002-11-01 12:41:16,944 [GMT] DEBUG 70TestTestService [main] - Have a char:O
2002-11-01 12:41:16,944 [GMT] DEBUG 70TestTestService [main] - Have a char:K
2002-11-01 12:41:16,954 [GMT] DEBUG 80TestTestService [main] - Have a char:
2002-11-01 12:41:16,954 [GMT] DEBUG 80TestTestService [main] - Have a char:
2002-11-01 12:41:16,954 [GMT] DEBUG 80TestTestService [main] - String
returned is: OK
TC 4.1.12 Results:
2002-11-01 12:38:48,050 [GMT] DEBUG 10TestTestService [main] - Connecting
to
http://arabica.ko.kodak.com:8080/eFUSE/servlet/controller/Test?action=ReadRequestreadQueue=TestingMe
2002-11-01 12:38:48,100 [GMT] DEBUG 60TestTestService [main] - opening
buffered reader to read response
2002-11-01 12:38:54,119 [GMT] DEBUG 6079 TestTestService [main] - Have a char:O
2002-11-01 12:38:54,119 [GMT] DEBUG 6079 TestTestService [main] - Have a char:K
2002-11-01 12:38:54,119 [GMT] DEBUG 6079 TestTestService [main] - Have a char:
2002-11-01 12:38:54,119 [GMT] DEBUG 6079 TestTestService [main] - Have a char:
2002-11-01 12:38:54,119 [GMT] DEBUG 6079 TestTestService [main] - String
returned is: OK
Note the times. Each TC instance was deployed out of the box, however is
there a directive in the server.xml that would account for this behavior difference?
Thank you for your time.
-j.p.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14164] New: - https makes warning
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14164. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14164 https makes warning Summary: https makes warning Product: Tomcat 4 Version: 4.1.2 Platform: PC URL: https://localhost:8443 OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] hi there! I installed new tomcat 4.1.12.I uncomment ssl connector in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true useURIValidationHack=false Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false protocol=TLS keystoreFile=/home/xhudik/crypt2 keystorePass=minimalne/ /Connector and make certificate(is ok). After start up tomcat(without problem),http connction works correctly. If I make for example https://localhost:8443 request I will get in browser requested page,but in console in which is tomcat running I will get this message: 1.11.2002 14:25:20 org.apache.coyote.http11.Http11Processor action WARNING: Exception getting SSL attributes javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificateChain(DashoA6275) at org.apache.tomcat.util.net.JSSESupport.getPeerCertificateChain(JSSESupport.java:118) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:543) at org.apache.coyote.Response.action(Response.java:216) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:314) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:221) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533) at java.lang.Thread.run(Thread.java:536) This is done by every https request(every picture,page,servlet). Could you help me? Thanx for your help. PS:tomcat is standalone. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [PATCH] virtual_hosting.txt
Robert, Thank you for making sure authorship was attributed to me. :-) I orginally wrote this to answer some questions Craig had about Tomcat and web hosting. Then later reposted it to tomcat-user when a similar question was raised. Yes it can be added to the Tomcat 4.1 documentation and committed to cvs with the ASF license. Regards, Glenn Robert L Sowders wrote: Well hey there, It is a nice document, isn't it. Alas, I'm not the Author. I pulled it off the tomcat-user list last August. It was sent originally by Glen Nielsen. [EMAIL PROTECTED] A brief search through the mailing list archives and presto, http://marc.theaimsgroup.com/?l=tomcat-userm=102838763518720w=2 All credit should go to Mr. Nielsen Thank you, rls Ian Darwin [EMAIL PROTECTED] 10/31/2002 06:28 AM To: Robert L Sowders [EMAIL PROTECTED], Tomcat Developers List [EMAIL PROTECTED] cc: Subject:Re: [PATCH] virtual_hosting.txt Robert, thank you for sending this document! I'd just like to clarify the copyright on this document before reformatting it into our XML tags: Do we have permission to include the virtual hosting with tomcat and apache document that you submitted to Bill Barker, into the Tomcat distribution, and to place it under the standard Apache Software Foundation License? You will be credited as the original author, of course. Thanks very much! Ian Darwin [EMAIL PROTECTED] On October 31, 2002 02:06 am, Bill Barker wrote: I'm pretty busy just at the moment, so I'm forwarding this to the list. I does a pretty good job of addressing a lot of the newbie questions that come up over and over on tomcat-user. - Original Message - From: Robert L Sowders [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 1:03 AM Subject: virtual_hosting.txt as promised -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14165] New: - Deleting a directory with compiled jsp pages causes FileNotFoundException on recompile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14165 Deleting a directory with compiled jsp pages causes FileNotFoundException on recompile Summary: Deleting a directory with compiled jsp pages causes FileNotFoundException on recompile Product: Tomcat 4 Version: 4.1.14 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] if you have a dir structure like / /somedir and you delete the /somedir from the jspcache then next time you try and get a page in that directory you get a FileNotFoundException. see attached war after going to index.jsp delete the dir directory in the jspcache and reload index.jsp you will see errors in the two iframes instead of the jsp page. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14165] - Deleting a directory with compiled jsp pages causes FileNotFoundException on recompile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14165 Deleting a directory with compiled jsp pages causes FileNotFoundException on recompile --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 14:10 --- Created an attachment (id=3694) this is a war file showing the error -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Problem with navigating faster that JSP pages can compile
I did not want to create a bug for this, as I can not reproduct it with a simple example. We have a webapp that has some huge jsp pages that take a good while to compile. If you navigate to another page before the previous page finishes its compile sometime the new page will get a compile error. When you look at the error it is as if the compiler merged the two generated classes. You will see the beginning of one word from the first jsp page and the end of a word from the second in the error message (ie if jsp1 had String john = Hi john; and jsp2 had boolean cold = true; then the compile error would refer to Strlean cold = true; unknown class Strlean) if you look at the .java files for the jsp pages they are fine and as they should be and a refresh will fix the problem. Does anyone know where should start to look to see if I can resolve (or atleast recreate in a simple example) this problem. Thanks, John -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14007] - Incorrect validation of optional package.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14007 Incorrect validation of optional package. --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 14:30 --- The CVS diff you posted shows changes in one source file, in the actual commit for Tomcat 5 changes related to this were made to a number of other files. Reviewing some of the relevant code comments shows that what you are asking to be removed was implemented to comply with the Servlet 2.3 spec. Tomcat 5 is implmenting the Servlet 2.4 spec. You state that the code for doing this is broken, how is it broken? If it is required by the spec shouldn't it be fixed rather than removed? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: R: GOODBYE from tomcat-dev@jakarta.apache.org
-Original Message- From: Pier Fumagalli [mailto:pier;betaversion.org] Sent: Friday, November 01, 2002 12:33 PM To: Tomcat Developers List Subject: FW: R: GOODBYE from [EMAIL PROTECTED] Who unsubbed this guy on Fri Nov 1 03:31:13 PST 2002??? Think the name is bug... Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. I regularly receive such a message couple of times in a week. Been harassing my ISP for two months, and found that if I lock my account (simply receiving mail due to the slow connection), and someone sends an e-mail during that, I immediately receive a warning from ezmlm. (Well that is what I found out). Don't think that anything is wrong either with my account, or my ISP, cause I have found no (well except from PHP-list using ezmlm too) other list behaving like that. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 Resubmit to j_security_check mistakenly fetches a page of that name --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 15:41 --- (sigh) Its never that simple is it... I grabbed the 4.1 code to make the last change I described and submit the patch. The problem is that of course the internals of Catalina arent real servlet requests so you can't forward them. There is code in FormAuthenticator which does do the equivalent of a forward(), by copying values into the request and returning true (so that the next handler is invoked). Trying something like this breaks the contract of authenticate(), and will cause more problems because the caller of authenticate() (AuthenticatorBase()) appears to call authenticate() twice. I don't feel comfortable with how intimate AuthenticatorBase needs to be with how FormAuthenticator works if I fix this; I'll try to put a working patch together at the weekend - a fix for this problem would be a good reason for us to upgrade to 4.1. If anyone has any comments on the suggested fix I'd appreciate them! -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14169] New: - Bug in 4.x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14169. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14169 Bug in 4.x Summary: Bug in 4.x Product: Tomcat 4 Version: Unknown Platform: PC OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The first time a JSP or Servlet is called from an HTML link, everything is fine. Two files of a JSP/Servlet are created in the following directory: C:\Program Files\Apache Group\Tomcat 4.1\work\Standalone\localhost\iss_web_site (ie-addNewResume_jsp.class, addNewResume_jsp.java) (depending where the app is installed) If you rename the JSP/Servlet (AddNewResume.jsp - Capital A) and try to call it from an HTML link, you will get an error stating the file cannot be found. You must manually go into the above directory and delete the files (addNewResume_jsp.class, addNewResume_jsp.java) , which were created. The next time the JSP/Servlet is called it will be as if it was called for the first time; works fine. The files will be created properly: AddNewResume_jsp.class, AddNewResume_jsp.java and the JSP/Servlet will run. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: R: GOODBYE from tomcat-dev@jakarta.apache.org
Was me, the idea was to silently make this guy pass trought the moderation process to indicate him the correct way to use our lists, althought i indicated that double posting and use the dev lists for user questions ( i dont think hi posted anything on topic never ) is against our rules, he guy did it again and again, so i was trying help him follow the rules.. The silently part failed.. ;) Saludos, Ignacio J. Ortega -Original Message- From: Pier Fumagalli [mailto:pier;betaversion.org] Sent: Friday, November 01, 2002 12:33 PM To: Tomcat Developers List Subject: FW: R: GOODBYE from [EMAIL PROTECTED] Who unsubbed this guy on Fri Nov 1 03:31:13 PST 2002??? 1036089107 - [EMAIL PROTECTED] It's not a probe, so, someone (one of the moderators, I believe), unsubbed him manually (see at the bottom). Any reason why? Pier -- Forwarded Message From: Luca Ventura [EMAIL PROTECTED] Date: Fri, 1 Nov 2002 11:31:43 +0100 To: [EMAIL PROTECTED] Subject: R: GOODBYE from [EMAIL PROTECTED] Hello! Why has my address been removed from the tomcat-dev mailing list? Can you subscribe it to the tomcat-dev mailing list again, please? Thanks, Luca -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:tomcat-dev-help;jakarta.apache.org] Inviato: giovedi 31 ottobre 2002 19.32 A: [EMAIL PROTECTED] Oggetto: GOODBYE from [EMAIL PROTECTED] Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. I'm working for my owner, who can be reached at [EMAIL PROTECTED] Acknowledgment: I have removed the address [EMAIL PROTECTED] from the tomcat-dev mailing list. This address is no longer a subscriber. --- I have subscribed or unsubscribed you at the request of a moderator of the [EMAIL PROTECTED] mailing list. If this is not an action you desire, please send a complaint or other comments to the list owner ([EMAIL PROTECTED]) as soon as possible. If you would like more information on how to interact with the tomcat-dev mailing list, just send an empty message to [EMAIL PROTECTED] -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 Resubmit to j_security_check mistakenly fetches a page of that name --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 16:51 --- In other words, showing the login form when you click back is /exactly/ what browsers are meant to do, and no amount of no-cache headers will help if the browser follows the spec. So, we have to deal with what happens when the user misuses the login form. I agree, and I think this means that we /can not/ replicate Basic Authentication's behavior here. We have to accept that Form Authentication differs in that it involves an extra page load on the client, thereby adding a page to the history. This happens whether we use a redirect or a forward. That said, I like the idea of giving the user the login form instead of the requested page without a redirect. Users can not bookmark a Basic Authentication login form, they must bookmark secured resources. This makes bookmarking work the same across Authenticator implementations. Also, I think the URI in the client for both items in the history will be the URI of the secured resource. So, pending some actual code to verify this, this might take care of the back button issue as well. On the session invalidation stuff, I think you're on to something. You should probably put it in another bug report as it can be addressed independently. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/tools - New directory
glenn 2002/11/01 09:39:53 jakarta-tomcat-connectors/jk/tools - New directory -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/tools/reports - New directory
glenn 2002/11/01 09:40:00 jakarta-tomcat-connectors/jk/tools/reports - New directory -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/tools/reports README.txt tomcat_reports.pl tomcat_trend.pl
glenn 2002/11/01 09:41:04 Added: jk/tools/reports README.txt tomcat_reports.pl tomcat_trend.pl Log: Import perl scripts for analyzing mod_jk logs and generating graphs/reports Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/tools/reports/README.txt Index: README.txt === This directory contains perl scripts which can be used to generate statistics for tomcat requests and errors logged by mod_jk. See the comments in the scripts for more details. A great deal of statistical data is generated but at this time only long term trend graphs are being created and no reports. This is only a start. Many more graphs and reports could be generated from the data. Please consider contributing back any new reports or graphs you create. Thanks. Requires the following perl modules and libraries: GD 1.8.x graphics library http://www.boutell.com/gd/. GD 1.4.x perl module. GD Graph perl module. GD TextUtil perl module. StatisticsDescriptive perl module. 1.1 jakarta-tomcat-connectors/jk/tools/reports/tomcat_reports.pl Index: tomcat_reports.pl === #!/usr/local/bin/perl # = # # The Apache Software License, Version 1.1 # # Copyright (c) 1999-2001 The Apache Software Foundation. # All rights reserved. # # = # # Redistribution and use in source and binary forms, with or without modi- # fication, are permitted provided that the following conditions are met: # # 1. Redistributions of source code must retain the above copyright notice #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, Jk, 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 Software Foundation. # # 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 indivi- # duals on behalf of the Apache Software Foundation. For more information # on the Apache Software Foundation, please see http://www.apache.org/. # # = # $Header: /home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_reports.pl,v 1.1 2002/11/01 17:41:04 glenn Exp $ # $Revision: 1.1 $ # $Date: 2002/11/01 17:41:04 $ # Author: Glenn Nielsen # Script for generating reports and graphs using statistical data generated # by the tomcat_trend.pl script. # # The following graphs are created: # # tomcat_request.png #Long term trend graph of total number of tomcat requests handled # # tomcat_median.png #Long term overall trend graph of tomcat request latency median # # tomcat_deviation.png #Long term overall trend graph of tomcat request
mod_jk log analysis/report perl scripts imported to CVS
I have imported the mod_jk log analysis scripts into CVS. The scripts for analyzing the logs generates alot of data. The scripts for graphing/reporting this data only generates five long term graphs. More graphs and reports could be generated from the raw data. For an example of these graphs look at: http://kinetic.more.net/ar/kinetic/lottery.shtml Only the long term graphs referring to tomcat in this page were generated by the new perl scripts. The server load graph was not. Enjoy, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Bug with symbolic links in WEB-INF/lib/
Hi ! I noticed a Tomcat bug that may be of interest for you developers. When using Tomcat 4.0.x, I used to set some symbolic links in my WEB-INF/lib directory. For example : WEB-INF/lib/mm.mysql.jar = /usr/java/lib/mm.mysql-xx.x/mm.mysql.jar But this won't work with Tomcat 4.1.12, which throws the following exception when deploying : java.lang.IllegalArgumentException: Invalid TLD resource path /WEB-INF/lib/mm.mysql.jar at org.apache.catalina.startup.ContextConfig.tldScanJar (ContextConfig.java:898) It took a while to figure out what happened, so maybe a note in RELEASE-NOTES would be usefull to many people :o) Best regards, -- Frédérik Bilhaut GREYC - Université de Caen http://www.info.unicaen.fr/~fbilhaut PS: Many thanks to Tomcat developers for such a great product PS': You'll find below the complete stack trace 2002-11-01 17:20:14 ContextConfig[/trouba] Exception processing JAR at resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - Root Cause - java.lang.IllegalArgumentException: Invalid TLD resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:898) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
OT: ezmlm problems (was: Re: R: GOODBYE from tomcat-dev@jakarta.apache.org)
Mladen Turk wrote: I regularly receive such a message couple of times in a week. Been harassing my ISP for two months, and found that if I lock my account (simply receiving mail due to the slow connection), and someone sends an e-mail during that, I immediately receive a warning from ezmlm. (Well that is what I found out). Don't think that anything is wrong either with my account, or my ISP, cause I have found no (well except from PHP-list using ezmlm too) other list behaving like that. cvs sometimes sends a email to jakarta.apache.org with a very long subject line (does the RFC specify a legal maximum?), which is rejected by a mail server somewhere between me and Apache (I think my ISP). This causes ezmlm to probe my account (send me a 'probe' email). This happens several times a month. -- Michael -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [PATCH] virtual_hosting.txt
Well hey there, It is a nice document, isn't it. Alas, I'm not the Author. I pulled it off the tomcat-user list last August. It was sent originally by Glen Nielsen. [EMAIL PROTECTED] A brief search through the mailing list archives and presto, http://marc.theaimsgroup.com/?l=tomcat-userm=102838763518720w=2 All credit should go to Mr. Nielsen Thank you, rls Ian Darwin [EMAIL PROTECTED] 10/31/2002 06:28 AM To: Robert L Sowders [EMAIL PROTECTED], Tomcat Developers List [EMAIL PROTECTED] cc: Subject:Re: [PATCH] virtual_hosting.txt Robert, thank you for sending this document! I'd just like to clarify the copyright on this document before reformatting it into our XML tags: Do we have permission to include the virtual hosting with tomcat and apache document that you submitted to Bill Barker, into the Tomcat distribution, and to place it under the standard Apache Software Foundation License? You will be credited as the original author, of course. Thanks very much! Ian Darwin [EMAIL PROTECTED] On October 31, 2002 02:06 am, Bill Barker wrote: I'm pretty busy just at the moment, so I'm forwarding this to the list. I does a pretty good job of addressing a lot of the newbie questions that come up over and over on tomcat-user. - Original Message - From: Robert L Sowders [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 1:03 AM Subject: virtual_hosting.txt as promised -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Bug with symbolic links in WEB-INF/lib/
This is not a bug, but a feature :).. The release notes tells more about it. Martin -Original Message- From: Frédérik Bilhaut [mailto:fbilhaut;wanadoo.fr] Sent: 01 November 2002 16:38 To: [EMAIL PROTECTED] Subject: Bug with symbolic links in WEB-INF/lib/ Hi ! I noticed a Tomcat bug that may be of interest for you developers. When using Tomcat 4.0.x, I used to set some symbolic links in my WEB-INF/lib directory. For example : WEB-INF/lib/mm.mysql.jar = /usr/java/lib/mm.mysql-xx.x/mm.mysql.jar But this won't work with Tomcat 4.1.12, which throws the following exception when deploying : java.lang.IllegalArgumentException: Invalid TLD resource path /WEB-INF/lib/mm.mysql.jar at org.apache.catalina.startup.ContextConfig.tldScanJar (ContextConfig.java:898) It took a while to figure out what happened, so maybe a note in RELEASE-NOTES would be usefull to many people :o) Best regards, -- Frédérik Bilhaut GREYC - Université de Caen http://www.info.unicaen.fr/~fbilhaut PS: Many thanks to Tomcat developers for such a great product PS': You'll find below the complete stack trace 2002-11-01 17:20:14 ContextConfig[/trouba] Exception processing JAR at resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar javax.servlet.ServletException: Exception processing JAR at resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - Root Cause - java.lang.IllegalArgumentException: Invalid TLD resource path /WEB-INF/lib/mm.mysql-2.0.14-bin.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:898) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail:
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SSLAuthenticator.java
bobh2002/11/01 10:48:52
Modified:catalina/src/share/org/apache/catalina/authenticator
SSLAuthenticator.java
Log:
To allow the underlying SSL implementation to perform the certificate
exchange, the socket must be completely read. If the request was a
POST, then there is data still waiting on the socket. We should read
the entire POST and hold on to it. This change just takes care of the
case where the posted ContentType is application/x-www-form-urlencoded.
I will work over the next few days to implement a more general
solution. Kinda hairy, cause if someone posts a huge document - like
a movie file, then were do we buffer that? on disk? So if the POST is
bigger than size X, then start saving to a temporary file? Then
change Request.getInputStream() to read from the file? Joy.
Revision ChangesPath
1.5 +12 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java
Index: SSLAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SSLAuthenticator.java 23 Sep 2002 00:24:32 - 1.4
+++ SSLAuthenticator.java 1 Nov 2002 18:48:52 - 1.5
-148,6 +148,14
(HttpServletResponse) response.getResponse();
if (debug = 1)
log( Looking up certificates);
+
+if (POST.equalsIgnoreCase(request.getMethod())) {
+// Causes POST of application/x-www-form-urlencoded to be read,
+// removing data from socket so that a cert exchange can happen if
needed.
+// A more general solution for all POSTs is coming 01-Nov-2002 bobh
+((HttpServletRequest) request.getRequest()).getParameterMap();
+}
+
X509Certificate certs[] = (X509Certificate[])
request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR);
if ((certs == null) || (certs.length 1)) {
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14164] - https makes warning
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14164. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14164 https makes warning [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 18:51 --- Fixed in 4.1.14 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SSLAuthenticator.java
bobh2002/11/01 11:01:18
Modified:catalina/src/share/org/apache/catalina/authenticator
SSLAuthenticator.java
Log:
- missing a few casts and needed to get to the real Request.. details details..
Revision ChangesPath
1.6 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java
Index: SSLAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- SSLAuthenticator.java 1 Nov 2002 18:48:52 - 1.5
+++ SSLAuthenticator.java 1 Nov 2002 19:01:18 - 1.6
-149,7 +149,7
if (debug = 1)
log( Looking up certificates);
-if (POST.equalsIgnoreCase(request.getMethod())) {
+if (POST.equalsIgnoreCase(((HttpServletRequest)
request.getRequest()).getMethod())) {
// Causes POST of application/x-www-form-urlencoded to be read,
// removing data from socket so that a cert exchange can happen if
needed.
// A more general solution for all POSTs is coming 01-Nov-2002 bobh
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14177] New: - modJk value used for jkConfig
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14177. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14177 modJk value used for jkConfig Summary: modJk value used for jkConfig Product: Tomcat 4 Version: Unknown Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] (4.1.12 from Apache RPMs on RH 7.3, mod_jk-ap13-1.2.0 from Apache RPMs) In my server.xml, I added the following to my Server context: Listener className=org.apache.ajp.tomcat4.config.ApacheConfig modJk=modules/mod_jk.so / and the following to my Host context: Listener className=org.apache.ajp.tomcat4.config.ApacheConfig append=true / When I restart Tomcat I get the following in /var/tomcat4/logs/catalina.out: --- java.lang.RuntimeException: Unable to create path to config file: /var/tomcat4/modules/mod_jk.so at org.apache.ajp.tomcat4.config.BaseJkConfig.getConfigFile(BaseJkConfig .java:428) at org.apache.ajp.tomcat4.config.ApacheConfig.initProperties(ApacheConfi g.java:267) at org.apache.ajp.tomcat4.config.BaseJkConfig.execute(BaseJkConfig.java: 162) at org.apache.ajp.tomcat4.config.BaseJkConfig.lifecycleEvent(BaseJkConfi g.java:153) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardHost.start(Unknown Source) at org.apache.catalina.core.ContainerBase.start(Unknown Source) at org.apache.catalina.core.StandardEngine.start(Unknown Source) at org.apache.catalina.core.StandardService.start(Unknown Source) at org.apache.catalina.core.StandardServer.start(Unknown Source) at org.apache.catalina.startup.Catalina.start(Unknown Source) at org.apache.catalina.startup.Catalina.execute(Unknown Source) at org.apache.catalina.startup.Catalina.process(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Unknown Source) --- When I don't set modJk, the value put into /var/tomcat4/conf/auto/mod_jk.conf contains: IfModule !mod_jk.c LoadModule jk_module libexec/mod_jk.so /IfModule which doesn't work on a default RH install (should be modules/mod_jk.so) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
tomcat4 user guide ( doc on webapps/ dir ) ?
Hi, Is there any documentation on the webapps/ layout ? In 3.3 it's in the 'user guide' ( http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html), but I can't find the equivalent doc. I'm interested in docs for the ROOT special dir. I know this should be directed to tomcat-user :-) ( I also know how it works - but I need the 'official' documentation ) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14179] New: - xercesImpl.jar eating characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14179. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14179 xercesImpl.jar eating characters Summary: xercesImpl.jar eating characters Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have been using the 4.0X version of Tomcat, and am testing 4.1.12. The xercesImpl.jar appears to be swallowing xml content. I moved the previous version of xerces.jar (1779 KB, 6/10/2002), into the /common/endorsed directory, renamed xercesImpl and the problem went away. I can provide sample output files, with and without xercesImpl, if it helps. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[Patch][jakarta-tomcat-catalina] ErrorDispatcherValue.java
This patch fixes support for changes made between the public draft and public final draft for Filter support in Servlet 2.4. Errors that were generated by a throwable in the ErrorDispatcherValue had filters applied properly but those coming from a setStatus (called from within a servlet) are not having filters applied as specfied in the Servlet specification (See SRV.6.2.5 for details). This patch fixes compliance with the specification. The file that needs to be updated is: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java The changes are minimal for this fix. Let me know if this is a problem Greg Murray --- ErrorDispatcherValve.oldFri Nov 1 13:18:46 2002 +++ ErrorDispatcherValve.java Fri Nov 1 13:14:17 2002 @@ -1,2 +1 @@ -/* * $Header: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v 1.3 2002/09/12 00:09:28 amyroh Exp $ * $Revision: 1.3 $ * $Date: 2002/09/12 00:09:28 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 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.catalina.valves; import java.io.IOException; import java.util.ArrayList; import java.util.Enumeration; import java.util.Iterator; import javax.servlet.RequestDispatcher; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.Cookie; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.Globals; import org.apache.catalina.HttpRequest; import org.apache.catalina.HttpResponse; import org.apache.catalina.Logger; import org.apache.catalina.Request; import org.apache.catalina.Response; import org.apache.catalina.Valve; import org.apache.catalina.ValveContext; import org.apache.catalina.Wrapper; import org.apache.catalina.deploy.ErrorPage; import org.apache.catalina.util.RequestUtil; import org.apache.catalina.util.StringManager; import org.apache.catalina.core.ApplicationFilterFactory; /** * pImplementation of a Valve that handles the error dispatch (that is, will * forward to the appropriate error page if necessary)./p * * pThis Valve should be attached at
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931 Base64 decoder chokes on a whitespace --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 21:59 --- Created an attachment (id=3703) Base64-decoder.patch -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931 Base64 decoder chokes on a whitespace [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 22:02 --- Base64-decoder.patch does pre-processing on the value passed to the decode() function. Filtering whitespace the body of decode() would be both more memory and CPU-efficient, but I'm not comfortable enough with the the code to make that invasive of a change. I'm curious what the Tomcat folks are doing here these days. Unfortunately, in implementing this, I noticed that encode() isn't line wrapping at 76 characters -- should we log this as a problem? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14184] New: - HttpSession object has confusing behaviour (HttpSession.isNew() )
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14184. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14184 HttpSession object has confusing behaviour (HttpSession.isNew() ) Summary: HttpSession object has confusing behaviour (HttpSession.isNew() ) Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I don't know if this would qualify as a bug. But it's definitely a behaviour change from 4.0.3 to 4.1.12. Two examples: 1) When I go from servlet A to servlet B, and printout the session ID in both servlets, they are the same value. But, if I do a session.isNew() in session B, the return value is true. My browser is cookie enabled and I'm sure the session has not expired. This did not happen in Tomcat 4.0.3. 2) The values from the following lines are not the same. Again, the browser is cookie enabled and the session has not expired. myRequest.getSession().getId(); myRequest.getRequestedSessionId(); The values are the same when I run the code in Tomcat 4.0.3. Has there been change between 4.0.3 and 4.1.12 that would result in the above behaviour change? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931 Base64 decoder chokes on a whitespace --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 22:19 --- I'd say follow the RFC and wrap it. Strict in what you send, liberal in what you accept --potentially mangled Vixie quote -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931 Base64 decoder chokes on a whitespace --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 22:24 --- I wrote code with the intent of doing this, and it doesn't work quite right. Someone else want to take a stab? I'll attach what I wrote -- it uses the filter style of processing that the decode() fix used. Again, mixing in directly with the encode() function would be more efficient. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931 Base64 decoder chokes on a whitespace --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 22:26 --- Created an attachment (id=3704) BROKEN-Base64-encoder.patch -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 12465] - ServletRequest.getLocales() does not return a list matching what the browser supplies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12465. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12465 ServletRequest.getLocales() does not return a list matching what the browser supplies. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 22:43 --- I just checked Tomcat 4.0.6, and this bug is not present there, i.e. request.getLocales() returns a list matching that in the accept-language header. Cheers. Zac -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 Resubmit to j_security_check mistakenly fetches a page of that name --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 23:59 --- After looking through FormAuthenticator again I realized an error in my earlier comments. When a user bookmarks the login page or presses back to go one previous in her history, the URI referenced is the one in the form-login-page element. To have the behavior I mentioned earlier we would need to change the redirect in the authenticate() class to a RequestDispatcher.include(). -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Security threat with enabling invoker servlet in 4.1.12
Hi, I've browsed the user list for this question but could not find the answer. Apologies if this is not the right question for this list. The release note in 4.1.12 says that the invoker servlet is turned off in the default web.xml for security reasons. However, in the examples app's web.xml the invoker is on. My questions are: 1. What security threat is that? 2. If it is not safe to turn it on in the default web.xml, is it safe to do so in the app web.xml? thx, budi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
luehe 2002/11/01 16:27:45
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
changed visibility of jspContext from protected to private
Revision ChangesPath
1.117 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.116
retrieving revision 1.117
diff -u -r1.116 -r1.117
--- Generator.java1 Nov 2002 02:54:41 - 1.116
+++ Generator.java2 Nov 2002 00:27:45 - 1.117
-3073,7 +3073,7
// to mask the page context from the tag file and simulate a
// fresh page context. We need the original to do things like
// sync AT_BEGIN and AT_END scripting variables.
-out.printil( protected JspContext jspContext; );
+out.printil( private JspContext jspContext; );
out.println();
out.printil( public void setJspContext( JspContext ctx ) { );
out.pushIndent();
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[PATCH] jakarta-servletapi-5: javadoc clarifications
Here is a patch with some more javadoc clarifications, to make the API more testable. Thanks go to Ryan Lubke for helping out! As always, please let me know if there are any questions or concerns. Change summary: --- jsr152/src/share/javax/servlet/jsp/tagext/VariableInfo.java - Fixed incorrect wording from last patch, for variable synchronization. jsr152/src/share/javax/servlet/jsp/tagext/TagExtraInfo.java - Fixed wording to preserve forwards compatibility for existing TEI implementations. jsr152/src/share/javax/servlet/jsp/tagext/TagInfo.java - Fixed default implementation of getVariableInfo() to return a variable for the id attribute, if specified. Clarified intent in javadocs. jsr152/src/share/javax/servlet/jsp/tagext/TagData.java - Fixed getId() description, as we're not returning the jsp:id in this case. jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java jsr152/src/share/javax/servlet/jsp/tagext/Tag.java - Clarified javadocs w.r.t. variable synchronization jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd jsr154/src/share/dtd/web-jsptaglibrary_2_0.xsd - Removed fragment element under variable element, as fragment-scoped variables are no longer supported. -- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc. Index: jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java,v retrieving revision 1.2 diff -u -r1.2 BodyTag.java --- jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java 29 Oct 2002 01:18:12 - 1.2 +++ jsr152/src/share/javax/servlet/jsp/tagext/BodyTag.java 2 Nov 2002 01:12:50 +- -200,9 +200,9 * tags whose doStartTag() method returns SKIP_BODY or EVAL_BODY_INCLUDE. * * p - * The JSP container will resynchronize any variable values that - * are indicated as so in TagExtraInfo or TLD after the invocation of - * doInitBody(). + * The JSP container will resynchronize the values of any AT_BEGIN and + * NESTED variables (defined by the associated TagExtraInfo or TLD) after + * the invocation of doInitBody(). * * throws JspException * see #doAfterBody Index: jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java,v retrieving revision 1.2 diff -u -r1.2 IterationTag.java --- jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java 29 Oct 2002 01:18:12 - 1.2 +++ jsr152/src/share/javax/servlet/jsp/tagext/IterationTag.java 2 Nov 2002 01:12:54 +- -138,9 +138,9 * of external computation. * * p - * The JSP container will resynchronize any variable values that are - * indicated as so in TagExtraInfo or TLD after the invocation of - * doAfterBody(). + * The JSP container will resynchronize the values of any AT_BEGIN and + * NESTED variables (defined by the associated TagExtraInfo or TLD) after + * the invocation of doAfterBody(). * * return whether additional evaluations of the body are desired * throws JspException Index: jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java,v retrieving revision 1.3 diff -u -r1.3 SimpleTag.java --- jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java29 Oct 2002 01:18:12 - 1.3 +++ jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java2 Nov 2002 01:12:54 +- -111,6 +111,11 * Called by the container to invoke this tag. * The implementation of this method is provided by the tag library * developer, and handles all tag processing, body iteration, etc. + * + * p + * The JSP container will resynchronize any AT_BEGIN and AT_END + * variables (defined by the associated tag file, TagExtraInfo, or TLD) + * after the invocation of doTag(). * * throws javax.servlet.jsp.JspException If an error occurred * while processing this tag. Index: jsr152/src/share/javax/servlet/jsp/tagext/Tag.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/tagext/Tag.java,v retrieving revision 1.3 diff -u -r1.3 Tag.java --- jsr152/src/share/javax/servlet/jsp/tagext/Tag.java 29 Oct 2002 01:18:12 - 1.3 +++ jsr152/src/share/javax/servlet/jsp/tagext/Tag.java 2 Nov 2002 01:12:54 - -243,9 +243,11 * implements
DO NOT REPLY [Bug 14187] New: - JSP compilation fails if beans in default package are used
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14187. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14187 JSP compilation fails if beans in default package are used Summary: JSP compilation fails if beans in default package are used Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JSPs fail to compile if the page uses a bean in the default package(no package). This occurs using 'javac' as well as 'jikes', although 'jikes' in general doesn't work with this version of Tomcat. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
