Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
on 1/15/01 9:51 PM, "Anil Vijendran" [EMAIL PROTECTED] wrote: Talking about someone's mother is just not kosher. I didn't talk about his mother. I'm simply showing the immaturity and rudeness of telling someone to shut up. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Stop! Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
on 1/15/01 11:17 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: I'll just set a filter - and I advise you do the same. I'm going to ignore any posting Jon does, and I'll avoid any project where he's involved. Again. More censorship. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info
Paulo Gaspar wrote: Sam and others already stated that 3.3 is easier to maintain. They did take a look at the code. Not me. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
Jon Stevens wrote: Costin, this has been like you since I have known you. You are an excellent developer in that you can work on your own, but when it comes to working within a project or group of people where you need to ask the opinions of others and then take those seriously, I haven't seen you doing that at all. That was not my experience when I worked by Costin's side on 3.1. Before Sam points it out, I will state that I am also guilty of doing the same thing. However, I am trying to work on fixing that (admitted) portion of my personality defect. What are you doing about it? On the contrary, I believe that there are projects and groups who owe their very existence to your work. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
Hans Bergsten wrote: The way I feel right now is that the best way to answer this question is by a vote on this list, where all +1 votes for TC 3.3 also means a commitment to help fix bugs in TC 3.3. +1 . That's the right body (the committers of Tomcat) to make this decision, IMHO. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info - What happens if a 3.3 proposal getsa -1
Hans Bersten wrote: Unless another committer can convince whoever votes -1 to change his vote, it means that 3.3 will not happen. Instead we will continue to maintain the 3.x code base based on 3.2.1. That's how decision making is defined for this project, see http://jakarta.apache.org/site/decisions.html That may be how it is defined, but we need to find a way to make it work. Two conflicting goals: the burden of proof needs to be on the one proposing to change the status quo, and we can't permit -1's that simply are raised to prohibit forward progress. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info
Hans Bergsten wrote: Great. As have been said a few times, you can do that as a revolution using a different name than Tomcat within the Jakarta project. +1. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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\account\_0002 fsystem_0002fadmin_0002fmodes_0002fstart_0002faccount_0002fpage_0005fadmin_0 005fstart_0005faccount_0005fpassword_0002ejsppage_0005fadmin_0005fstart_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]
Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
Jon Stevens wrote: on 1/15/01 9:51 PM, "Anil Vijendran" [EMAIL PROTECTED] wrote: Talking about someone's mother is just not kosher. I didn't talk about his mother. I'm simply showing the immaturity and rudeness of telling someone to shut up. What do you mean by "I didn't talk"?? See the following snippet posted by yourself: (Let me know if you want me to forward the exact mail...) For all the talk you do about read what I wrote carefully you should remember what *you* write. I can't get you and Costin to understand what I'm saying, however, you understand Hans even though he said nearly the same thing that I have been saying all along. Than maybe it would be a good idea to shut up and let Hans do the talking? How should I respond to this, with a comment about your mother or something? -jon -- Peace, Anil +:-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #778 has been filed.
Bug report #778 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/778 REPORT #778 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2.1 JVM Release: 1.3.0 Operating System: Windows NT OS Release: 4.00.1381 Platform: Intel Pentium II Synopsis: Cannot make an include inside a custom tag Description: When making a include inside a custom tag i get the following error message: java.io.IOException: Illegal to flush within a custom tag void org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) void javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) void org.apache.tomcat.core.ServletWrapper.doService(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.Handler.service(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.ServletWrapper.service(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.ContextManager.internalService(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.ContextManager.service(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(org.apache.tomcat.service.TcpConnection, java.lang.Object[]) void org.apache.tomcat.service.TcpWorkerThread.runIt(java.lang.Object[]) void org.apache.tomcat.util.ThreadPool$ControlRunnable.run() void java.lang.Thread.run() Title: BugRat Report # 778 BugRat Report # 778 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Ari Volcoff ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 03:01:33 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Cannot make an include inside a custom tag Environment: (jvm, os, osrel, platform) 1.3.0, Windows NT, 4.00.1381, Intel Pentium II Additional Environment Description: Report Description: When making a include inside a custom tag i get the following error message: java.io.IOException: Illegal to flush within a custom tag void org.apache.jasper.servlet.JspServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) void javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) void org.apache.tomcat.core.ServletWrapper.doService(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.Handler.service(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.ServletWrapper.service(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.ContextManager.internalService(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.core.ContextManager.service(org.apache.tomcat.core.Request, org.apache.tomcat.core.Response) void org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(org.apache.tomcat.service.TcpConnection, java.lang.Object[]) void org.apache.tomcat.service.TcpWorkerThread.runIt(java.lang.Object[]) void org.apache.tomcat.util.ThreadPool$ControlRunnable.run() void java.lang.Thread.run() How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info
I am terribly sorry Sam. It was Larry. Sorry again, Paulo -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 08:46 Paulo Gaspar wrote: Sam and others already stated that 3.3 is easier to maintain. They did take a look at the code. Not me. - Sam Ruby -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 15:35 ... I think in the long run, the community will be better served by a released 3.3. It may have some different bugs, but I think it will eventually have fewer bugs and quirks and be more maintainable as well. ... Cheers, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info
Hans Bergsten wrote: The way I feel right now is that the best way to answer this question is by a vote on this list, where all +1 votes for TC 3.3 also means a commitment to help fix bugs in TC 3.3. +1 . I'd like to see a beta release of 3.3. We could see and compare after. Don't forget that the majority of commiters on 3.3 only works on 3.x. It will not take away resources from TC 4.0 Another alternative could be as, I proposed some time ago, to rename Tomcat 3.3 to AnotherName 3.3 ie Bobcat or Finecat 3.3 ;-) Excellence came from openness.Even if code base may diverge from 3.3 and 4.0, it will certainly help somewhere to build a common framework for inclusion of module in both 3.3 and 4.0. And that may be the framework of TC 5.0. Why not thinking about a plugable Tomcat engine which could made of TC 3.3 core or TC 4.0 core. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Fwd: Jakarta PMC Meeting Agenda / Info]
-Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 06:05 on 1/15/01 9:03 PM, "Paulo Gaspar" [EMAIL PROTECTED] wrote: The reasons why there are advantages for (at least) the next year or so on having both 3.3 and 4.x were already stated so often today... 3.3 will get released. That isn't the question. GREAT! I was getting "confused" about that. ...and also how 3.3 commiters are scratching an itch and will not focus on 4.x while the itch is there... Not true at all. Costin has said that he will not work on 4.x. Again, my point being that perhaps it would be smarter to encourage people to work on improving 4.x more quickly instead of having this fork of developer resources working on 3.x. Some of us have production sites _now_. It is smarter for us to do whatever keeps/gets those sites running ASAP. Scratching the itch, remember? If Costin and everyone else had put all of their energy on working on 4.x in the first place, we wouldn't be in the same situation we are in today and people would have been more willing to migrate from 3.0/3.1 to 4.x because the improvement would have been more clear. Instead, now we are stuck in the position of having to give people 3.2 and potentially 3.3 because people have invested a lot into building on top of it. Where does it stop? "If" here means "maybe". Can anyone be sure that 4.0 would be production ready now? I am sure that all that people can still be motivated to migrate to 4.x _when_ it is ready for production if it has real advantages - and I am not doubting it may have. Just because you want it now, it does not mean that you can drag people with different needs. The reason 3.3 is there is just because there are several committers with those different needs. So, I guess "it stops" when 4.0 is able to satisfy those different needs too. Paulo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat / Configuration / Setting a java system property ...
Hi! We are using Apache/Tomcat and now we would like to specify a Java System Property to our JVM workers. We have tried .. worker.workername.sysprops=propname=propvalue .. within the "workers.properties" file but with no luck! Can anyone out there help us? Thanks in advance, Gunnar Eketrapp
RE: Jakarta PMC Meeting Agenda / Info - Is more than just 3.x vs 4.x
Don't forget about that : PRE-MEETING FESTIVITIES: Before the meeting, Jon Stevens and I welcome you to come to CollabNet and discuss ideas for a CJAN implementation for managing Java JAR libraries. I'm sure that we'd also like to talk about Sam's tinderbox ideas as these ideas are related. Details on this to follow. I'm a +1000 to see someone like CJAN (CPAN for java) came to life. One of my goal in RPM packaging majors projects in jakarta and xml is to help RPM users (Not only Linux) have an easy access and installation to help them do a more effective java programming. Dependencies, Obsoleting and packaging concept of RPM help do that. Hope to read decision of CJAN. Some questions : * Did the jars must be installed in : /usr/share/java/(Debian recommandation) /usr/lib/java/ ( la perl) * Must we keep major versions in naming ie : /usr/share/java/jakarta-regexp-1.1.jar /usr/share/java/jakarta-regexp-1.2.jar /usr/share/java/jakarta-regexp.jar - /usr/share/java/jakarta-regexp-1.2.jar * What's the exact naming of jars : /usr/share/java/jakarta-regexp.jar or /usr/share/java/regexp.jar Thanks for comments - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: IM LOST, ERROR 500????
Delivery failure: javax.mail.MessagingException: 452 Filesystem error - message not accepted Delivery failure: javax.mail.MessagingException: 452 Filesystem error - message not accepted Delivery failure: javax.mail.MessagingException: 452 Filesystem error - message not accepted Hi Im writing my first little program that will welcome a user once she enters and submits her details into a web page.There is no problem Writing the JSP files but I cannot start a new .java file in Jbuilder, so I write it in Homesite, save it as .java and attempt to compile it to .class in Jbuilder. Im having difficulty converting the .javafile to .class I have tried compiling the .java file to a .class in JBuilder, but I keep getting the following warning: "Warning #908: check sourcepath; source c:\jakarta-tomcat\webapps\mary\Web-inf\Classes\namehandler.java cannot be found on source pathby appending \mary\namehandler.java to each sourcepath entry." (mary is the name of the package) When I try to view the program in my browser at http:// localhost etc etc I get the following error Error: 500 Location: /Mary/hellouser.jsp Internal Servlet Error:org.apache.jasper.JasperException: Bad file argument to include at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventListener.java, Compiled Code) at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener.java:116) at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java, Compiled Code) at org.apache.jasper.compiler.Parser.parse(Parser.java, Compiled Code) at org.apache.jasper.compiler.Parser.parse(Parser.java:1038) at org.apache.jasper.compiler.Parser.parse(Parser.java:1034) at org.apache.jasper.compiler.Compiler.compile(Compiler.java, Compiled Code) at org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java:413) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:149) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:161) at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261) at org.apache.jasper.runtime.JspServlet.service(JspServlet.java, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, Compiled Code) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:160) at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338) at java.lang.Thread.run(Thread.java:479)PLEASE PLEASE PLEASE, anyone with help?Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #780 has been filed.
Bug report #780 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/780 REPORT #780 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Environment: Release: 1.2.1 JVM Release: 1.2.2 Operating System: NT OS Release: 4.0 Platform: PC Synopsis: Redirect to welcome file works not too well Description: I have a problem with welcome file list. It doesn't work the way other webservers do. Instead of showing content of i.e. index.jsp file like others do, it posts a redirect to index.jsp And that redirect have content type of text/html which is OK for Web browsers, but not OK for WAP phones (or other devices I think). I think Tomcat should: 1) Just return welcome file and not redirect to it. Redirecting is slower and makes bookmarked addreses longer (client could bookmark http://www.x.com/ not http://www.x.com/index.html) and makes bookmarks more stable (if somebody changes index.html to index.jsp and somebody has bookmarked www.x.com/index.html) Maybe should it be parameter for that behaviour? 2) Redirect with a type which is suitable for user agent (user agent informs server which mime type it supports) Title: BugRat Report # 780 BugRat Report # 780 Project: Tomcat Release: 1.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Submitter: Michal Hobot ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 08:02:56 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Redirect to welcome file works not too well Environment: (jvm, os, osrel, platform) 1.2.2, NT, 4.0, PC Additional Environment Description: Report Description: I have a problem with welcome file list. It doesn't work the way other webservers do. Instead of showing content of i.e. index.jsp file like others do, it posts a redirect to index.jsp And that redirect have content type of text/html which is OK for Web browsers, but not OK for WAP phones (or other devices I think). I think Tomcat should: 1) Just return welcome file and not redirect to it. Redirecting is slower and makes bookmarked addreses longer (client could bookmark http://www.x.com/ not http://www.x.com/index.html) and makes bookmarks more stable (if somebody changes index.html to index.jsp and somebody has bookmarked www.x.com/index.html) Maybe should it be parameter for that behaviour? 2) Redirect with a type which is suitable for user agent (user agent informs server which mime type it supports) How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #781 has been filed.
Bug report #781 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/781 REPORT #781 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: 1.2.1 JVM Release: 1.2.2 Operating System: NT OS Release: 4.0 Platform: PC Synopsis: Problems with virtual hosts on NT Description: I have apache with http and https virtual servers. I'd like to connect each of them to virtual Tomcat host. Virtual hosts names are somehost:80 and somehost:443 When I put those names as Host name="somehost:80" and Host name="somehost:443" Tomcat tries creating directory in \work containing :443 and :80 in name. It should work for Unix, but colon is not permitted in NT (because of A:, C: drive notation). Title: BugRat Report # 781 BugRat Report # 781 Project: Tomcat Release: 1.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: Michal Hobot ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 08:11:04 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Problems with virtual hosts on NT Environment: (jvm, os, osrel, platform) 1.2.2, NT, 4.0, PC Additional Environment Description: Report Description: I have apache with http and https virtual servers. I'd like to connect each of them to virtual Tomcat host. Virtual hosts names are somehost:80 and somehost:443 When I put those names as and Tomcat tries creating directory in \work containing :443 and :80 in name. It should work for Unix, but colon is not permitted in NT (because of A:, C: drive notation). How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
Anil. That was a question, not a stated comment about his mother. It was said in such a way as to show that if I had commented about his mother, it would be as low as telling someone to shut up. -jon on 1/16/01 12:46 AM, "Anil Vijendran" [EMAIL PROTECTED] wrote: Jon Stevens wrote: on 1/15/01 9:51 PM, "Anil Vijendran" [EMAIL PROTECTED] wrote: Talking about someone's mother is just not kosher. I didn't talk about his mother. I'm simply showing the immaturity and rudeness of telling someone to shut up. What do you mean by "I didn't talk"?? See the following snippet posted by yourself: (Let me know if you want me to forward the exact mail...) For all the talk you do about read what I wrote carefully you should remember what *you* write. I can't get you and Costin to understand what I'm saying, however, you understand Hans even though he said nearly the same thing that I have been saying all along. Than maybe it would be a good idea to shut up and let Hans do the talking? How should I respond to this, with a comment about your mother or something? -jon -- Peace, Anil +:-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Honk if you love peace and quiet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info - Is more than just 3.x vs 4.x
BTW, you know the Giant Java Tree project, don't you? Have fun, Paulo Gaspar -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 13:42 I'm a +1000 to see someone like CJAN (CPAN for java) came to life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info
Another alternative could be as, I proposed some time ago, to rename Tomcat 3.3 to AnotherName 3.3 ie Bobcat or Finecat 3.3 ;-) Robcat! - r p.s. my brother's name is tom. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #782 has been filed.
Bug report #782 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/782 REPORT #782 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: Apache Tomcat Version 4.0 Beta 1 JVM Release: 1.3.0 Operating System: Linux OS Release: Kernel 2.2.16 Platform: SuSE Linux 7.0 Synopsis: Error Mounting a WebApp over mod_webapp with Apache Description: When mounting a Web-app in the httpd.conf with WebAppMount web-app-name warpConnection /Mountpoint the Mountpoint has to have the same length as the name of the webapp. Otherwise the last part of the Requesting URI is shorten about the size of Web-App-Name - Mountpoint. Example: Web-App-Name: fooname Mountpoint: foo Requesting URI: http://servername/foo/servlet Here the URI given to Tomcat is about 7 (length fooname) - 3 (length) foo shorter. URI given to Tomcat: http://servername/foo/let The first 4 letters of servlet are missing. Title: BugRat Report # 782 BugRat Report # 782 Project: Tomcat Release: Apache Tomcat Version 4.0 Beta 1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Matthias Brantner ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 10:27:08 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Error Mounting a WebApp over mod_webapp with Apache Environment: (jvm, os, osrel, platform) 1.3.0, Linux, Kernel 2.2.16, SuSE Linux 7.0 Additional Environment Description: Report Description: When mounting a Web-app in the httpd.conf with WebAppMount web-app-name warpConnection /Mountpoint the Mountpoint has to have the same length as the name of the webapp. Otherwise the last part of the Requesting URI is shorten about the size of Web-App-Name - Mountpoint. Example: Web-App-Name: fooname Mountpoint: foo Requesting URI: http://servername/foo/servlet Here the URI given to Tomcat is about 7 (length fooname) - 3 (length) foo shorter. URI given to Tomcat: http://servername/foo/let The first 4 letters of servlet are missing. View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugRat Report #778 has been filed.
BugRat Mail System wrote: Bug report #778 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/778 REPORT #778 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2.1 JVM Release: 1.3.0 Operating System: Windows NT OS Release: 4.00.1381 Platform: Intel Pentium II Synopsis: Cannot make an include inside a custom tag Description: When making a include inside a custom tag i get the following error message: java.io.IOException: Illegal to flush within a custom tag [...] The include action can not be used within a custom tag. This is documented in the JSP 1.1 spec (see the spec for details). You may want to test Tomcat 4.0 instead, since it implements JSP 1.2 where this restriction has been lifted. 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: [Fwd: Jakarta PMC Meeting Agenda / Info]
Paul Speed wrote: [EMAIL PROTECTED] wrote: Can you argue about how Valve's single chain of command ( where authentication, generation, etc are done in a single invoke() ) can be better than what all other server are doing ( and Apache 2.0 moves to a different level with the flexible HOOK mechanism ? Actually, this is a discussion I would like to see happen. I think that I can actually argue for Valves. Admittedly, I know little about the actual implementations but I am very familiar with the patterns used in Tomcat 3.x and Tomcat 4.x and I have seen much of the discussions on this list. However, in other projects I have converted several architectures using patterns similar to 3.x to be more like the Valve approach. We did it to shorten development times and improve developer productivity. Performance wasn't our main goal but in all but one case performance improved. Valves implement the "Chain of Responsibility" design pattern in the GoF book. You will also see a very similar programming model in the way that the javax.servlet.Filter APIs are defined in the Servlet Specification, Version 2.3 Proposed Final Draft -- after wrestling with lots of alternatives, the expert group concluded that this was the most appropriate programming model for exposing similar functionality at the application level. What I would like to see is a frank analysis of this topic. If those "in the know" do not have the time then I will attempt to do a brief analysis myself in the coming weeks. It will take research on my part whereas some of you might know the answers off the top of your head. I did an analysis on this topic in August, when Catalina was being formally proposed -- it is still in the "jakarta-tomcat-4.1" CVS repository as file "catalina/docs/filters.html". The comparison was primarily to the way that request interceptors were implemented in Tomcat 3.2, so I would suspect that there have been some changes since on the HEAD branch -- particularly in the last section, where I discuss limitations that are due to the *implementation* of request interceptors in Tomcat 3.2, not their *design*. (The Valve APIs have not needed to be changed -- they have proven to be entirely sufficient to implement the servlet 2.3 spec's functionality requirements :-). Aside from downloading the 4.1 source repository, this document will also be visible though the online CVS web access. Sorry, I'm offline at the moment, so I cannot give you a hyperlink, but select the CVSWeb link, module "jakarta-tomcat-4.1", directory "catalina", directory "docs", directory "dev", and file "filters.html". What I intend to compare is the typical method call sequence of the two approaches, including resource allocation if any, when handling various types requests. From there I hope to point to the relative merits and tradeoffs of each approach. I have fun with this kind of stuff... it harkens back to my old graphics programming days. It's almost always surprising what this stuff will turn up. -Paul Speed I had a Comp Sci prof that made an interesting point -- you only write one real program in your life, and then you spend the rest of your career plagarizing from it :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Sorry not to get this out earlier ... comments intermixed.
Glenn Nielsen wrote:
Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
Work on implementing this proposal is in progress. Comments please?
Tomcat 4 Java SecurityManager Proposal
Tomcat 4 will require the Java SecurityManager, use of the
SecurityManager will be optional when Tomcat is embedded in
another application.
Will it be optional when Tomcat 4 is run by itself (either standalone or behind
a
web server) as well?
Setting policies for internal Tomcat classes
Security policies will be set using the tomcat.policy file. Security
checks will be based only on the codeSource of the class matching the
codeBase for JVM and Tomcat internal classes.
Example tomcat.policy entries affecting Tomcat internals
// javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/jre/lib/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/server/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/bin/-" {
permission java.security.AllPermission;
};
Note - to be technically correct, references to "tomcat.home" in the entries
above
should be "catalina.home" for Tomcat 4, to be consistent with the system
property
definition that is actually used.
Setting policies for web application contexts
-
A web application has its security based on either the default grant in
tomcat.policy or an entry for the context which uses the Context path
file URL as the codeBase. This policy will be in affect for any Class running
within the Context thread no matter which ClassLoader loaded the class
which triggered a security check. A default permission to read files in
the Context path is granted.
// Default permissions for a Context, all contexts have these permissions
grant {
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
};
Is this set of default permissions going to be easily configurable? I can
imagine
that this would be a popular choice for people who don't want to spend a lot of
time thinking about security. For example, you might want to grant all webapps
the
ability to connect to the network host and port required by your database
because
you use it in every app.
// Additional Permissions for tomcat examples context
grant codeBase="file:${tomcat.home}/webapps/examples/- {
permission java.util.PropertyPermission "*", "read";
};
Should the code base actually be restricted to ".../examples/WEB-INF/classes/-"
and
".../examples/WEB-INF/lib/-"? It means setting up two policy entries instead of
one if a particular app uses both JAR'd and unJAR'd classes, but I suspect that
is
somewhat unusual.
Security restrictions for using classes
---
StandardClassLoader will implement the SecurityManager.checkPackageAccess()
method to determine whether the ClassLoader has permission to access the
packages "sun.,org.apache.catalina.,org.apache.jasper.".
Is org.apache.jasper really special? It is loaded by the "Shared" classloader
(in
the Tomcat 4 classloader hierarchy) anyway, so it is already going to be
restricted.
And, a web app will need to be able to access these packages to utilize the JSP
servlet, and therefore execute JSP pages.
If a Context doesn't have the RuntimePermission "*" or
"accessClassInPackage.{package name}", it will not be allowed to use a
Class in the package.
Security restrictions for defining classes
--
StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
method to determine whether the ClassLoader has permission to define a class
in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".
Same question re: specialness of Jasper, although I can see a stronger case for
prohibiting class *creation* in this package than class *access*.
If a Context doesn't have the RuntimePermission "*" or
"defineClassInPackage.{package name}", it will not be allowed to define
a Class in the package.
Changing security policies at runtime
-
Anytime a Context is reloaded the security policies will be refreshed
from the tomcat policy file.
StandardClassLoader
---
All of the code for implementing system, restricted, and allowed
checks will be removed. This will be handled by the SecurityManager.
+1
It's only there as a placeholder until security manager support is available.
Remove the ability to configure a contexts classloader in the
server.xml
Re: Jakarta PMC Meeting Agenda / Info
"Rob S." wrote: Another alternative could be as, I proposed some time ago, to rename Tomcat 3.3 to AnotherName 3.3 ie Bobcat or Finecat 3.3 ;-) Robcat! - r p.s. my brother's name is tom. Sounds as rational as the thinking at most of the product naming/branding meetings I've ever attended :-). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Query regrading mod_webapp
I have been trying to configure mod_webapp (without much luck) and I notice that wa_host will not allow applications to be mounted which have common heads (i.e. '/' and '/examples/'). Tomcat itself doesn't seem to have any problem with such a setup. Is this a genuine design decision? Regards, Arshad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Jakarta PMC Meeting Agenda / Info - What happens if a 3.3 proposal getsa -1
Sam Ruby wrote: Hans Bersten wrote: Unless another committer can convince whoever votes -1 to change his vote, it means that 3.3 will not happen. Instead we will continue to maintain the 3.x code base based on 3.2.1. That's how decision making is defined for this project, see http://jakarta.apache.org/site/decisions.html That may be how it is defined, but we need to find a way to make it work. Two conflicting goals: the burden of proof needs to be on the one proposing to change the status quo, and we can't permit -1's that simply are raised to prohibit forward progress. Right, we need to talk about this (and a few other things in our bylaws and guidelines) at the meeting today. 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: Query regrading mod_webapp
Arshad Mahmood wrote: I have been trying to configure mod_webapp (without much luck) and I notice that wa_host will not allow applications to be mounted which have common heads (i.e. '/' and '/examples/'). Tomcat itself doesn't seem to have any problem with such a setup. Is this a genuine design decision? Sounds like a bug to me. Pier? Regards, Arshad Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info
Hola a todos: Hans Bergsten wrote: The way I feel right now is that the best way to answer this question is by a vote on this list, where all +1 votes for TC 3.3 also means a commitment to help fix bugs in TC 3.3. +1 . +1 Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #783 has been filed.
Bug report #783 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/783 REPORT #783 Details. Project: Servlet API Category: Feature Requests SubCategory: Enhancement Class: swbug State: received Priority: high Severity: serious Confidence: public Environment: Release: 4.0.b1 JVM Release: 1.3 Operating System: Linux (Mandrake) OS Release: 7.2 Platform: Intel Synopsis: req.getInputStream() causes req.getParameterNames() to hang 60-80 seconds. Description: I have written a simple servlet to test Unicode input encoding. It will alternatly read the servlet request input stream and decode the stream into parameters, then use getParameterNames() and getParameterValues() to read the parameters. The two methods should return the same string. (They do not). In my first testing against Catalina 4.0.b1 I notice extremely long response time, and the jvm associated with the servlet is spinning in execute state for up to 3 minutes whenever I read the servlet input stream before getting the parameter names and values. When I read the parameter names and values, the jvm executes a normal amount of time. Title: BugRat Report # 783 BugRat Report # 783 Project: Servlet API Release: 4.0.b1 Category: Feature Requests SubCategory: Enhancement Class: swbug State: received Priority: high Severity: serious Confidence: public Submitter: Timothy T. Tye ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 11:58:40 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: req.getInputStream() causes req.getParameterNames() to hang 60-80 seconds. Environment: (jvm, os, osrel, platform) 1.3, Linux (Mandrake), 7.2, Intel Additional Environment Description: running the servlet in examples context. Report Description: I have written a simple servlet to test Unicode input encoding. It will alternatly read the servlet request input stream and decode the stream into parameters, then use getParameterNames() and getParameterValues() to read the parameters. The two methods should return the same string. (They do not). In my first testing against Catalina 4.0.b1 I notice extremely long response time, and the jvm associated with the servlet is spinning in execute state for up to 3 minutes whenever I read the servlet input stream before getting the parameter names and values. When I read the parameter names and values, the jvm executes a normal amount of time. View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #784 has been filed.
Bug report #784 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/784 REPORT #784 Details. Project: Servlet API Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 4.0.b1 JVM Release: 1.3 Operating System: Linux (Mandrake) OS Release: 7.2 Platform: Intel Synopsis: Servlet Request getCharacterEncoding returns Incorrect value on Netscape. Description: The servlet request getCharacterEncoding method always returns the string "ISO-8859-1". I have set the character set of the response using method setContentType() in the previous execution to "text/html charset=UTF-8". Both Netscape and Internet Explorer recognize this charset as eight bit compressed Unicode and correctly display and enter characters using the specified encoding. Netscape also returns the request header with a "charset=UTF-8" entry. However, IE does ont place a charset entry in the request header. So, for Netscape, the getCharacteEncoding() method should return the string "UTF-8" (or converted to JAVA name 'UTF8'). For IE, the getCharacterEncoding() method should return NULL because no character encoding was specified in the request header. Title: BugRat Report # 784 BugRat Report # 784 Project: Servlet API Release: 4.0.b1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Timothy T. Tye ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 12:08:50 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Servlet Request getCharacterEncoding returns Incorrect value on Netscape. Environment: (jvm, os, osrel, platform) 1.3, Linux (Mandrake), 7.2, Intel Additional Environment Description: Netscape 4.7 (NT and Linux) IE 5.0 (NT) Report Description: The servlet request getCharacterEncoding method always returns the string "ISO-8859-1". I have set the character set of the response using method setContentType() in the previous execution to "text/html charset=UTF-8". Both Netscape and Internet Explorer recognize this charset as eight bit compressed Unicode and correctly display and enter characters using the specified encoding. Netscape also returns the request header with a "charset=UTF-8" entry. However, IE does ont place a charset entry in the request header. So, for Netscape, the getCharacteEncoding() method should return the string "UTF-8" (or converted to JAVA name 'UTF8'). For IE, the getCharacterEncoding() method should return NULL because no character encoding was specified in the request header. Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Error
I have the following error using Jakarta-tomcat with Apache Server on Windows 2000 Can you help me . Thanks in advance . FATAL:java.net.BindException: Address in use: JVM_Bind java.net.BindException: Address in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:397) at java.net.ServerSocket.init(ServerSocket.java:170) at java.net.ServerSocket.init(ServerSocket.java:121) at org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(Default ServerSocketFactory.java) at org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint(PoolTcpEndpoi nt.java) at org.apache.tomcat.service.PoolTcpConnector.start(PoolTcpConnector.jav a) at org.apache.tomcat.core.ContextManager.start(ContextManager.java) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Jakarta PMC Meeting Agenda / Info
Hans Bergsten wrote: The way I feel right now is that the best way to answer this question is by a vote on this list, where all +1 votes for TC 3.3 also means a commitment to help fix bugs in TC 3.3. +1 Cheers, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #785 has been filed.
Bug report #785 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/785
REPORT #785 Details.
Project: Servlet API
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment:
Release: 4.0.b1
JVM Release: 1.3
Operating System: Linux (Mandrake)
OS Release: 7.2
Platform: Intel
Synopsis:
Use setCharacterEncoding("UTF8") does not change the way getParameterValue*() decodes
characters.
Description:
I am testing the support of UNICODE input and output for Java servlets and JSP's. I
have a very simple servlet that creates a web page with a single entry field. When
the ServletResponse is created, I use setContentType("text/html charset=UTF-8") to
tell the web browsers this page contains eight bit compressed unicode. This works,
the data is placed from the servlet onto the web page in UTF8 style, and displayed by
the web browser (IE and Netscape) correctly.
However, when data is entered by the web browser, the getParameterValues method
ignores the character encoding and maps each byte to a seperate character. It fails
even when I use the setCharacterEncoding("UTF8") method on the request before reading
any parameter names or values.
Support of character encoding on request input is critical to any users outside of
Latin-1.
Title:
BugRat Report #
785
BugRat Report #
785
Project:
Servlet API
Release:
4.0.b1
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
high
Severity:
critical
Confidence:
public
Submitter:
Timothy T. Tye ([EMAIL PROTECTED])
Date Submitted:
Jan 16 2001, 12:24:12 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
Use setCharacterEncoding("UTF8") does not change the way getParameterValue*() decodes characters.
Environment: (jvm, os, osrel, platform)
1.3, Linux (Mandrake), 7.2, Intel
Additional Environment Description:
Report Description:
I am testing the support of UNICODE input and output for Java servlets and JSP's. I have a very simple servlet that creates a web page with a single entry field. When the ServletResponse is created, I use setContentType("text/html charset=UTF-8") to tell the web browsers this page contains eight bit compressed unicode. This works, the data is placed from the servlet onto the web page in UTF8 style, and displayed by the web browser (IE and Netscape) correctly.
However, when data is entered by the web browser, the getParameterValues method ignores the character encoding and maps each byte to a seperate character. It fails even when I use the setCharacterEncoding("UTF8") method on the request before reading any parameter names or values.
Support of character encoding on request input is critical to any users outside of Latin-1.
View this report online...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
"Craig R. McClanahan" wrote: Paul Speed wrote: [EMAIL PROTECTED] wrote: Can you argue about how Valve's single chain of command ( where authentication, generation, etc are done in a single invoke() ) can be better than what all other server are doing ( and Apache 2.0 moves to a different level with the flexible HOOK mechanism ? Actually, this is a discussion I would like to see happen. I think that I can actually argue for Valves. Admittedly, I know little about the actual implementations but I am very familiar with the patterns used in Tomcat 3.x and Tomcat 4.x and I have seen much of the discussions on this list. However, in other projects I have converted several architectures using patterns similar to 3.x to be more like the Valve approach. We did it to shorten development times and improve developer productivity. Performance wasn't our main goal but in all but one case performance improved. Valves implement the "Chain of Responsibility" design pattern in the GoF book. You will also see a very similar programming model in the way that the javax.servlet.Filter APIs are defined in the Servlet Specification, Version 2.3 Proposed Final Draft -- after wrestling with lots of alternatives, the expert group concluded that this was the most appropriate programming model for exposing similar functionality at the application level. Yeah, I've used variations on this pattern to help save architectures that were spiralling out of control. What I would like to see is a frank analysis of this topic. If those "in the know" do not have the time then I will attempt to do a brief analysis myself in the coming weeks. It will take research on my part whereas some of you might know the answers off the top of your head. I did an analysis on this topic in August, when Catalina was being formally proposed -- it is still in the "jakarta-tomcat-4.1" CVS repository as file "catalina/docs/filters.html". The comparison was primarily to the way that request interceptors were implemented in Tomcat 3.2, so I would suspect that there have been some changes since on the HEAD branch -- particularly in the last section, where I discuss limitations that are due to the *implementation* of request interceptors in Tomcat 3.2, not their *design*. (The Valve APIs have not needed to be changed -- they have proven to be entirely sufficient to implement the servlet 2.3 spec's functionality requirements :-). Aside from downloading the 4.1 source repository, this document will also be visible though the online CVS web access. Sorry, I'm offline at the moment, so I cannot give you a hyperlink, but select the CVSWeb link, module "jakarta-tomcat-4.1", directory "catalina", directory "docs", directory "dev", and file "filters.html". Just in case anyone else is interested: http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat-4.1/catalina/docs/filters.html What I intend to compare is the typical method call sequence of the two approaches, including resource allocation if any, when handling various types requests. From there I hope to point to the relative merits and tradeoffs of each approach. I have fun with this kind of stuff... it harkens back to my old graphics programming days. It's almost always surprising what this stuff will turn up. -Paul Speed I had a Comp Sci prof that made an interesting point -- you only write one real program in your life, and then you spend the rest of your career plagarizing from it :-) Ain't it the truth. One thing that was always fun about graphics programming was that quite often the algorithm that looked least optimal performed the best. Figuring out why is sometimes it's own game. Thanks for the pointer to the doc... it should get me started. -Paul Speed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed name encoding patch
It's worth to mention that both JSP encoding and work dir encoding are resolved/improved in 3.3 - and the code can be easily ported back / reused. I'll take a look at both patches and try to integrate them into 3.3 also ( what is not covered already ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat Report #786 has been filed.
Bug report #786 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/786 REPORT #786 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: Tomcat 3.2 JVM Release: JDK 1.3 Operating System: Windows NT OS Release: 4.0 Platform: Wintel Synopsis: Thread in jk_ajp12_worker.c spins in infinite loop Description: When a client closes the connection after sending a header but before sending the content, the thread handling the response spins in an infinite loop receiving 0 bytes from an apache call. I've included the patch in the known work around section. I submitted a patch to the email list in October but it never found it's way into the source tree. Title: BugRat Report # 786 BugRat Report # 786 Project: Tomcat Release: Tomcat 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Brian Vetter ([EMAIL PROTECTED]) Date Submitted: Jan 16 2001, 03:22:09 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Thread in jk_ajp12_worker.c spins in infinite loop Environment: (jvm, os, osrel, platform) JDK 1.3, Windows NT, 4.0, Wintel Additional Environment Description: Report Description: When a client closes the connection after sending a header but before sending the content, the thread handling the response spins in an infinite loop receiving 0 bytes from an apache call. I've included the patch in the known work around section. I submitted a patch to the email list in October but it never found it's way into the source tree. Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
mod_jk ACL - next
Hi, I'm busy these days and didn't have many time on ACL for mod_jk. Before investing too many times, just want to describe the plan : 1) Create stuff to handle InetMask a l hosts.allow / hosts.deny. Data initialized via config in server.xml From 3.2 server.xml Connector className="org.apache.tomcat.service.PoolTcpConnector" Parameter name="handler" value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/ Parameter name="port" value="8009"/ Parameter name="deny" value="ALL"/ Parameter name="allow" value="172.168.1.0/24"/ Parameter name="allow" value="127.0.0.1"/ /Connector After connection, ACL is checked and connection closed (and warned) if rules not meet 2) The ACL stuff could also be used in a Realm ? Thanks for more Lights ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP (REVISED)
Thanks to everyone for the comments on my paper. I've tried to address them in the revised version by emphasizing the validation and site architecture and moving MLS into the supporting article. The new version is at http://virtualschool.edu/wap. I'd be interested whether the validation/site stuff would be appropriate to add to Tomcat. I'd be glad to do the work if someone would point me in the right direction. on 1/10/01 7:52 PM, "Brad Cox" [EMAIL PROTECTED] wrote: I've uploaded an early rough draft of a pair of articles that boils down to a critique of the JSP approach plus source code for a quite different approach. I'd be very interested in feedback... of the constructive variety, of course ;) The articles are at http://virtualschool.edu/wap -- --- 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]
TC 4 / mod_jk
Craig, I assume I'm the person interested in porting mod_jk to TC 4 (if there's anyone else, please get in touch with me ;-). Thank you for clarifying the issue about the difference between the 2.2 and 2.3 specs -- I hadn't realized that. I do have a question: how would you feel about including mod_jk in TC 4 before it became totally 2.3 compliant? In other words, if I managed to write ajp13 and/or ajp12 connectors for TC 4, how would you feel about that being committed to cvs immediately, so that people could start using it (and using TC with various web servers), *before* making the extensive additions which would be necessary to bring it into 2.3 compliance? To my mind this would be worthwhile, and in keeping with TC 4 development in general -- there is the doc specifying the various degrees of "doneness" of 2.3 compliance. I see it as a very pragmatic path -- I believe that adding a functional web server connector would give many, many more people reason to start using TC 4, which can only be a good thing. And, I hope, that increased usage would bring more volunteer resources to bear on the connectors -- which could be mod_webapp or mod_jk. I ask this because I am honestly not sure how much time I can devote to the project -- I am hoping to write the ajp13 connector, but I am not sure if I will have the time to rewrite all the C code (something I'm not as expert at) to bring mod_jk into 2.3 compliance. If I can only offer the code for the current ajp13, would that be something you would be comfortable with merging into the TC 4 codebase? Thanks, -Dan "Craig R. McClanahan" wrote: GOMEZ Henri wrote: [finally ... a technical issue!] I still didn't understand why TC 4.0 didn't select mod_jk as their connector to WebServer. The code is clean and many bugs are removed. A web server connector is not an easy piece of cake so why reinvent the whell ?-( Tomcat 4.0 did not select mod_jk for several reasons. The most important ones are at the top: * MOD_JK (like MOD_JSERV before it) has no clue what a web application is. This forces you to configure many items twice -- once in the web.xml file and once in the Apache configuration, which is a pretty serious imposition on people trying to administer the combination. * While the 2.2 spec was silent in many areas, the 2.3 spec will require an Apache+Tomcat combination to obey *all* the requirements of the spec (same rules as for any other container). This means that the things in web.xml *must* be respected. For example, a security constraint in a web.xml file must be enforced, even on a static resource that is served by Apache instead of Tomcat. Substantial modifications to MOD_JK would be needed to make this work (primarily in adding a two-way exchange of configuration information). * MOD_JK had no committers interested in maintaining it, at the time that the decision was made. Subsequent to that time, several volunteers have surfaced, including at least one person interested in supporting MOD_JK under Tomcat 4.0. That would be fine with me, as long as the result obeys all the rules. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Forwarding side-effects HttpSession in Tomcat 3.2.1
I don't have cvs access at the moment, so if anyone is interested in
this fix:
public void forward(ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
.
HttpSession oldSession = realRequest.getSession(false);
context.getContextManager().processRequest(realRequest);
realRequest.setSession(oldSession); // fix for side-effect
}
The problem is when you forward with a new session,
org.apache.tomcat.session.StandardSessionInterceptor
clobbers it. It's probably related to its logic
about cookies being set or some such thing, but
I don't think it really makes sense for a servlet
to forward to another servlet, and the second
servlet not have the same session as the first,
so this is a basic workaround for some logic
that doesn't seem to make sense in the case
of forward().
I'm sure there's a more elegant fix, but this seems
to work better than no fix at all.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Forwarding side-effects HttpSession in Tomcat 3.2.1
By the way, this is for RequestDispatcherImpl...
I think this produces another bug with session invalidation, though...
-Bill
William Flanders wrote:
I don't have cvs access at the moment, so if anyone is interested in
this fix:
public void forward(ServletRequest request, ServletResponse response)
throws ServletException, IOException
{
.
HttpSession oldSession = realRequest.getSession(false);
context.getContextManager().processRequest(realRequest);
realRequest.setSession(oldSession); // fix for side-effect
}
The problem is when you forward with a new session,
org.apache.tomcat.session.StandardSessionInterceptor
clobbers it. It's probably related to its logic
about cookies being set or some such thing, but
I don't think it really makes sense for a servlet
to forward to another servlet, and the second
servlet not have the same session as the first,
so this is a basic workaround for some logic
that doesn't seem to make sense in the case
of forward().
I'm sure there's a more elegant fix, but this seems
to work better than no fix at all.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
TOMCAT ENCRYPTION OF CREDIT CARD NUMS???????
Hi all, Help badly needed by anyone with ANY information on the foollowing: I am designing an online booking system using JSP, Java Beans and Tomcat for a project at uni. Does anyone have any information on how to encrypt a credit card number with Tomcat in mind. Surely there is some code I code take from somewhere to help me. Credit card security is a side project on top of my booking system. If anyone knows of any documentation or code available on the web, please mail me as all I can seeem to find is companys offering to selll me their security systems for $500! A big thanks in advance!! _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TOMCAT ENCRYPTION OF CREDIT CARD NUMS???????
Hi Mary, The servlet container (Tomcat in this case) you choose is irrespective to the type of application you wish to write. That's the whole point of the servlet spec - .WAR files, etc. As far as encryption goes, check out http://java.sun.com/. I think Java Cryptography Engine (JCE) might be a good place for you to start since there's nothing special about credit card numbers - they're just characters. Good luck, - r -Original Message- From: Mary McCarthy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 6:35 PM To: [EMAIL PROTECTED] Subject: TOMCAT ENCRYPTION OF CREDIT CARD NUMS??? Hi all, Help badly needed by anyone with ANY information on the foollowing: I am designing an online booking system using JSP, Java Beans and Tomcat for a project at uni. Does anyone have any information on how to encrypt a credit card number with Tomcat in mind. Surely there is some code I code take from somewhere to help me. Credit card security is a side project on top of my booking system. If anyone knows of any documentation or code available on the web, please mail me as all I can seeem to find is companys offering to selll me their security systems for $500! A big thanks in advance!! _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
load balanced and highly available services in tomcat
Does tomcat have that functions? Did that implement? thx Jeans _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TOMCAT ENCRYPTION OF CREDIT CARD NUMS???????
Why not? It seems like a good answer, and saves someone else the trouble of offering the same advice. I'll tuck it away and refer to it in a few weeks, when I will have the same problem. *** REPLY SEPARATOR *** On 1/16/2001 at 7:18 PM Rob S. wrote: DOH sorry i didn't mean to send this to the list =( - r -Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 7:14 PM To: [EMAIL PROTECTED] Subject: RE: TOMCAT ENCRYPTION OF CREDIT CARD NUMS??? Hi Mary, The servlet container (Tomcat in this case) you choose is irrespective to the type of application you wish to write. That's the whole point of the servlet spec - .WAR files, etc. As far as encryption goes, check out http://java.sun.com/. I think Java Cryptography Engine (JCE) might be a good place for you to start since there's nothing special about credit card numbers - they're just characters. Good luck, - r -Original Message- From: Mary McCarthy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 6:35 PM To: [EMAIL PROTECTED] Subject: TOMCAT ENCRYPTION OF CREDIT CARD NUMS??? Hi all, Help badly needed by anyone with ANY information on the foollowing: I am designing an online booking system using JSP, Java Beans and Tomcat for a project at uni. Does anyone have any information on how to encrypt a credit card number with Tomcat in mind. Surely there is some code I code take from somewhere to help me. Credit card security is a side project on top of my booking system. If anyone knows of any documentation or code available on the web, please mail me as all I can seeem to find is companys offering to selll me their security systems for $500! A big thanks in advance!! _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Khurram Mahmood/PeopleSoft is out of the office.
I will be out of the office starting 01/16/2001 and will not return until 01/30/2001. I will respond to your message when I return. Take it easy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
HELP! need binaries of nsapi_redirect.so (Solaris)!
Why won't it compile on my system? Here is the error message: ~/dl/tomcat/jakarta-tomcat-3.2.1-src/src/native/netscape# make -f Makefile.solaris make: *** No rule to make target `jk_ajp12_worker.o', needed by `nsapi_redirector.so'. Stop. I originally installed the Tomcat binary distribution, which worked, but because of the make error with nsapi_redirect I've been trying to install the source distribution. The source distribution fails to build with this error: ~/jakarta/jakarta-tomcat# build.sh Searching for build.xml ... Buildfile: /usr/local/home/august/jakarta/jakarta-tomcat/build.xml prepare: tomcat: [javac] Compiling 4 source files to /usr/local/home/august/jakarta/build/tomcat/classes [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/facade/HttpServletRequestFacade.java:290: Ambiguous class: org.apache.tomcat.util.Constants and org.apache.tomcat.core.Constants [javac] encoding = Constants.DEFAULT_CHAR_ENCODING; [javac]^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/facade/ServletOutputStreamFacade.java:130: Ambiguous class: org.apache.tomcat.core.Constants and org.apache.tomcat.util.Constants [javac] if ( Constants.DEFAULT_CHAR_ENCODING.equals(enc) ) [javac] ^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java:188: Ambiguous class: org.apache.tomcat.core.RequestUtil and org.apache.tomcat.util.RequestUtil [javac] RequestUtil.getLocale(req), [javac]^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java:218: Ambiguous class: org.apache.tomcat.core.RequestUtil and org.apache.tomcat.util.RequestUtil [javac] RequestUtil.getLocale(req), [javac] ^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java:457: Ambiguous class: org.apache.tomcat.core.RequestUtil and org.apache.tomcat.util.RequestUtil [javac] Locale locale=RequestUtil.getLocale(req); [javac] ^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionUtil.java:106: No variable SESSION_COOKIE_NAME defined in class org.apache.tomcat.util.Constants. [javac] Cookie cookie = new Cookie(Constants.SESSION_COOKIE_NAME, id); [javac] ^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionUtil.java:196: No variable SESSION_COOKIE_NAME defined in class org.apache.tomcat.util.Constants. [javac] if (Constants.SESSION_COOKIE_NAME.equals(cookies[i].getName())) [javac] ^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionUtil.java:215: No variable SESSION_PARAMETER_NAME defined in class org.apache.tomcat.util.Constants. [javac] String match = ";" + Constants.SESSION_PARAMETER_NAME + "="; [javac] ^ [javac] /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionUtil.java:266: No variable SESSION_PARAMETER_NAME defined in class org.apache.tomcat.util.Constants. [javac] buf.append(Constants.SESSION_PARAMETER_NAME); [javac] ^ [javac] Note: /usr/local/home/august/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java uses or overrides a deprecated API. Recompile with "-deprecation" for details. [javac] 9 errors, 1 warning BUILD FAILED /usr/local/home/august/jakarta/jakarta-tomcat/build.xml:94: Compile failed, messages should have been provided. Total time: 3 seconds __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
