Re: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 runningon AIX 4.3.3. Please help save Tomcat for a high profile project inSwitzerland
[EMAIL PROTECTED] wrote: First of all I attempt to calmly summarize the problem and only then let my emotions get through. My insufficient knowledge of AIX platforms prevents me from successfully compiling mod_webapp (as well mod_jk) on AIX 4.3.3 platform. Hardware: IBM pSeries 660 model 6H1 OS: AIX 4.3.3 (not sure about exact maintenance level) Web server: IBM HTTP Server 1.3.19 Servlet Engine: Tomcat 4.0.1 Tools libraries: IBM?s port of common GNU other open-source packages available at http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html Tomcat itself appears to be running flawlessly. Unfortunately due to my meager knowledge of AIX I seem to be unable to recompile neither mod_webapp nor mod_jk for the specified platform. Actually compilation worked fine in both cases. What did fail was the ?ld? linker. As far as I can judge about possible cause of failure, the linker requires a module export (.exp) file in order to be able successfully complete linking process. In this respect AIX appears to differ from Unixes, as I had no problems at all building mod_webapp mod_jk under Linux (Mandrake 8.0 Mandrake 8.1) as well as Solaris 8. The problem is aggravated by the management?s desire to use IBM HTTP Server instead of plain Apache mainly due to IBM?s SSL support, which is perceived to be more trustworthy and secure. Is my assumption right? If yes, is there a way I could generate that damn .exp file for mod_webapp? I could also live with mod_jk as a fallback scenario. Try a staticly linked mod_jk. That you do not need any .exp file. Please help. I have been informed by the management that if problem is not resolved by mid next week Tomcat will be replaced with WebSphere 3.5 Standard Edition. Please held save Tomcat for the project. Our work is highly visible. The system will serve population of an entire Swiss canton. If successful the system may be adopted by other cantons with Tomcat prominently featured alongside other leading commercial products. And most of all I really would like to show my management that open-source community cares, and is much more responsive when it comes to solving problems. Thanks cheers Oleg Kalnichevski -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Change the order of releases mentioned on the TC web page
On Mon, 19 Nov 2001, Bojan Smojver wrote: | Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the | releases in the order from the oldest to the newest in the description | section. | | I propose those are listed in the more natural order, from the newest to | the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) TC 4.0 and TC 3.3 are just as new, but implements different levels of specs. What about that? -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Change the order of releases mentioned on the TC web page
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: lunes 19 de noviembre de 2001 6:18 Para: Tomcat Dev List Asunto: [VOTE] Change the order of releases mentioned on the TC web page Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the releases in the order from the oldest to the newest in the description section. I propose those are listed in the more natural order, from the newest to the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) Vote to change the order of releases on the Tomcat web page: [ ] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: TC 3.3, Production Quality
+1. Did you also rebuild the site since the http://jakarta.apache.org/tomcat/index.html still present 3.3 as beta (it's fixed in your recent commit) Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 17, 2001 3:44 AM To: [EMAIL PROTECTED] Subject: TC 3.3, Production Quality I've noticed that on the main TC page of Jakarta site, TC 3.2.x is still listed as production quality release, although we all know that 3.3 is far superior in almost any respect. That's for Servlet API 2.2 and JSP 1.1, of course. Any objections if I change this? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Change the order of releases mentioned on the TC web page
[X] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Portable SSL Support
Or even better, in SSLInterceptor. No need to change Request or the core - if it can be done in a module, it's better to do it this way. A la mod_ssl :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 running on AIX 4.3.3. Please help save Tomcat for a high profile project in Switzerland
May I recommand you take a look at mod_jk from jakarta-tomcat-connectors which use configure stuff to try to ease the build... All the developpment effort on tomcat connectors have now moved to J-T-C - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Aaron Bannert [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 18, 2001 9:04 PM To: Tomcat Developers List Subject: Re: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 running on AIX 4.3.3. Please help save Tomcat for a high profile project in Switzerland Lurking indeed... ;) On Sun, Nov 18, 2001 at 10:34:42AM -0800, Justin Erenkrantz wrote: On Sat, Nov 17, 2001 at 08:51:24PM +0100, [EMAIL PROTECTED] wrote: First of all I attempt to calmly summarize the problem and only then let my emotions get through. You're certainly not the first to be frustrated by this problem. :) My insufficient knowledge of AIX platforms prevents me from successfully compiling mod_webapp (as well mod_jk) on AIX 4.3.3 platform. Tomcat itself appears to be running flawlessly. Unfortunately due to my meager knowledge of AIX I seem to be unable to recompile neither mod_webapp nor mod_jk for the specified platform. Actually compilation worked fine in both cases. What did fail was the 'ld' linker. As far as I can judge about possible cause of failure, the linker requires a module export (.exp) file in order to be able successfully complete linking process. In this respect AIX appears to differ from Unixes, as I had no problems at all building mod_webapp mod_jk under Linux (Mandrake 8.0 Mandrake 8.1) as well as Solaris 8. The problem is aggravated by the management's desire to use IBM HTTP Server instead of plain Apache mainly due to IBM's SSL support, which is perceived to be more trustworthy and secure. Is my assumption right? If yes, is there a way I could generate that damn .exp file for mod_webapp? I could also live with mod_jk as a fallback scenario. [snip] I know that Aaron Bannert spent some time working with the IBM httpd folks (Victor, Greg, Bill, Jeff, etc.) trying to get AIX DSO support for Apache 2.0 and APR. I believe the eventual conclusion from the IBM AIX gurus in Austin was that the linker is not capable of handling external dependencies in an acceptable manner. Their recommendation was to wait for the next major release of AIX which would have a new linker. But, this isn't very helpful to you or to us httpd folks though. As of yet we have not been able to tame the beast that is the AIX linker WRT apache-2.0 and DSOs. The essential problem has to do with the mechanism used at runtime to load and dynamically link modules, and the aparent inability of the AIX linker to deal with interdependent shared objects. In the short term this really only applies to apache-2.0 and modules that automatically depend on other libraries, like how mod_webapp depends on libapr and libaprutil. The problem in this scenario is that libaprutil actually depends on symbols exported from libapr. First-order runtime linkages seem to work fine, but as soon as you hit a symbol that depends on that second library (even if they are statically linked into the same shared object) you'll get a segfault. It's entirely possible that over in httpd-2.0 we're doing something wrong, but given the number of people looking at this issue, that is becomming less and less likely. I have been informed by the management that if problem is not resolved by mid next week Tomcat will be replaced with WebSphere 3.5 Standard Edition. My first impression to this post was to suggest you contact your vendor for a solution. (My second and more emotionally based response was to suggest you change operating systems. ;) Hope that provides some insight, -aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Error: null cert chain
FYI, a Linux RPM of ssldump is available at : http://ftp.falsehope.com/home/gomez/ssldump/ Regards :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:53 PM To: Tomcat Developers List Subject: Re: Error: null cert chain Hai Wang [EMAIL PROTECTED] writes: I am working on SSL communication now, I have set up Tomcat to support SSL, but I got an error when I tried to make a connection to Tomcat-SSL server. My procedures are as follows: (by the way my server and client are sitting in the same Linux PC (Lisbon)) 1. create the key pair for server and client 2. request the certificates from thawte from both of them 3. import the reply certifcates to server and client keystores 4 export the server and client certficates and import them as the trusted certficates Detailed procedures, please see the end of the mail when I desable clientAuth, everything is fine, but when I turn on the clientAuth, the following erros come up. Let's start by finding out whether the client is actually performing client auth. Can you get an ssldump trace of the connection? (you can get ssldump from http://www.rtfm.com/ssldump). You'll want to use the -A and -N flags. Once we know what's happening we can try to figure out why. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] Author of SSL and TLS: Designing and Building Secure Systems http://www.rtfm.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Change the order of releases mentioned on the TC web page
+1, I would also be +1 for listing Servlet 2.3/JSP 1.2/Tomcat 4.0 first in the impatient section as well, since that spec is newer. Larry P.S. I remembered to update the news page, but not this one. Thanks for noticing. -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 12:18 AM To: Tomcat Dev List Subject: [VOTE] Change the order of releases mentioned on the TC web page Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the releases in the order from the oldest to the newest in the description section. I propose those are listed in the more natural order, from the newest to the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) Vote to change the order of releases on the Tomcat web page: [ ] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4948] New: - Class.getPackage() returns null in classes loaded by webapp class loader
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=4948. 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=4948 Class.getPackage() returns null in classes loaded by webapp class loader Summary: Class.getPackage() returns null in classes loaded by webapp class loader Product: Tomcat 3 Version: 3.3 Final Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Servlet AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In classes loaded by the webapp class loader, the getPackage() method of java.lang.Class returns null. I could not reproduce this behavior in Tomcat 3.2 or 4.0.1. The last version of Tomcat 3.3 that worked correctly in this regard was the m4 version. I have found that I can work around this bug by copying all the jars in my webapp to Tomcat's lib/apps directory but of course that's not the right way to fix this problem. I've been able to reproduce this bug on multiple systems ( RedHat Linux 6.2, AIX 4.3.3, WinNT 4.0 SP4, Win2k SP2 ) and with both the IBM and Sun JVM implementations on each platform where both are available. I reproduced the problem with a simple servlet that had a single line of code: response.getWriter ().println(getClass().getPackage()) As I understand the code in DependClassLoader.java, parent is the immediate parent of the DependClassLoader instance and parent2 is the immediate parent of that parent. This separation of parent vs. parent2 seems to have been implemented in revision 1.5 of DependClassLoader.java in response to a class reloading bug reported by Ovidiu Predescu. In trying to debug this problem myself, I found that modifying the class loader to delegate to parent instead of parent2 ( line 174 ) fixed the getPackage() == null problem. In searching the mailing lists and bug reports I was unable to find any description of that problem so I have no idea if reverting this part of that patch will have any negative repercussions on class reloading. All I can say for certain is that it works for me and in a quick sanity test of class reloading I saw no odd behavior. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf catalina.policy
glenn 01/11/19 05:51:03
Modified:catalina/src/conf catalina.policy
Log:
Make the permissions for shared/lib explicit
Revision ChangesPath
1.16 +14 -4 jakarta-tomcat-4.0/catalina/src/conf/catalina.policy
Index: catalina.policy
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/catalina.policy,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- catalina.policy 2001/10/06 18:45:51 1.15
+++ catalina.policy 2001/11/19 13:51:03 1.16
@@ -8,7 +8,7 @@
//
// * Read access to the document root directory
//
-// $Id: catalina.policy,v 1.15 2001/10/06 18:45:51 remm Exp $
+// $Id: catalina.policy,v 1.16 2001/11/19 13:51:03 glenn Exp $
//
@@ -58,11 +58,21 @@
permission java.security.AllPermission;
};
-// These permissions apply to shared web application libraries
-// including the Jasper page compiler installed in the shared/lib directory
-grant codeBase file:${catalina.home}/shared/- {
+// These permissions apply to the jasper page compiler.
+grant codeBase file:${catalina.home}/shared/lib/jasper-compiler.jar {
permission java.security.AllPermission;
};
+
+// These permissions apply to the jasper JSP runtime
+grant codeBase file:${catalina.home}/shared/lib/jasper-runtime.jar {
+permission java.security.AllPermission;
+};
+
+// These permissions apply to the JNDI naming factory
+grant codeBase file:${catalina.home}/shared/lib/naming-factory.jar {
+permission java.security.AllPermission;
+};
+
// == WEB APPLICATION PERMISSIONS =
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4949] New: - jspc cannot find bean when using jsp:getProperty or jsp:setProperty
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=4949. 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=4949 jspc cannot find bean when using jsp:getProperty or jsp:setProperty Summary: jspc cannot find bean when using jsp:getProperty or jsp:setProperty Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Similar to Bug 4705 except that I find that jspc cannot find the bean when it is in WEB-INF/classes. jspc does find the bean if a scriptlet is used to retrieve or set the bean's property value. I've attached a small, test webapp that demonstrates the problem. The webapp contains two jsp files (page1.jsp and page2.jsp) and a Java class file (mytest.TestBean). If you run jspc on the webapp using the following command, you will see an error message that is related to mytest.TestBean not being found. jasper.sh jspc -d jspc-test/WEB-INF/jsp-src -webapp jspc-test The ERROR MESSAGE --- 2001-11-19 08:34:31 - error-the file '/page1.jsp' generated the following parse exception: org.apache.jasper.JasperException: mytest.TestBean If you pre-compile page1.jsp and page2.jsp separately, you'll see that the pre-compilation fails for page1.jsp but succeeds for page2.jsp. If you modify jasper.sh to include jspc-test/WEB-INF/classes in the classpath, the pre-compilation of page1.jsp will succeed. I listed the severity as major because we depend on pre-compiling our JSP as part of our webapp's deployment. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4949] - jspc cannot find bean when using jsp:getProperty or jsp:setProperty
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=4949. 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=4949 jspc cannot find bean when using jsp:getProperty or jsp:setProperty --- Additional Comments From [EMAIL PROTECTED] 2001-11-19 06:10 --- Created an attachment (id=803) gzipped tar file of test web application directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
CS143
Hi, Greg, I am working late tonight, cannot sleep. So, I thought I would put together a little grading tool for CS143. If you like it, feel free to change it, use it, sell it, whatever. ;-) The way it works is you put the unzipped files in c:\jdk1.3\jre\classes\ and go there on the command line or any IDE tool that runs the java command and run "java cs143.test.Test". A screen will come up and, if you were a student, you would enter "cs143 harry harry" (course, name, password). This will tell the student, if their class implements the tag interface Testable whether or not they pass the test set for their class. You can give the test the class must test prior to them building the classes. The student can keep changing their classes until they get a pass. Each attempt is recording it a log file. I sent a copy to Erika, in case Mark Vanbeek might find it helpful. Hope he can join us Tuesday. Micael cs143.zip Description: Zip compressed data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[JTC] APACHE_CONFIG_VARS and 2.0.28
Hi to all JTCs, I'm trying to rebuild jk and webapp from JTC and notice we try to include config_vars.mk, which is awaited under $prefix/build/. Problem, it fit well for Apache 2.0 using default packaging (ie all under /usr/local/apache) but fail when we have it installed under another directory, ie /usr/lib/apache2 (see my latest RPM), to make it more FHS compatible. What could we do to have JTC works in such situation since I'm not sure we need to included config_vars.mk !!! - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 3:07 PM To: Tomcat Developers List Subject: Re: Default policy file for TC4 - excessive permissions Thats a good suggestion, thanks. I have made the change and committed it. Antony Bowesman wrote: The catalina.policy file gives AllPermissions to the webapp shared lib/classes directories by default. Isn't this too liberal. Shouldn't the policy file explicitly name the 3 jars with the default 4.0.1 distribution in lib. Rgds Antony -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 README.txt
glenn 01/11/19 06:36:58 Modified:.README.txt Log: Update docs for shared directory Revision ChangesPath 1.18 +4 -3 jakarta-tomcat-4.0/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/README.txt,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- README.txt2001/08/25 03:51:27 1.17 +++ README.txt2001/11/19 14:36:58 1.18 @@ -1,4 +1,4 @@ -$Id: README.txt,v 1.17 2001/08/25 03:51:27 craigmcc Exp $ +$Id: README.txt,v 1.18 2001/11/19 14:36:58 glenn Exp $ The Tomcat 4.0 Servlet/JSP Container @@ -14,18 +14,19 @@ RUNNING.txt Instructions for installing Tomcat, as well as starting and stopping the server bin/Binary executables and scripts - classes/Unpacked classes global to web applications common/ Classes available to both Catalina internal classes and web applications: classes/ Unpacked common classes lib/ Common classes in JAR files conf/ Configuration files jasper/ JAR files visible only in the Jasper classloader - lib/Classes in JAR files global to web applications logs/ Destination directory for log files server/ Internal Catalina classes and their dependencies classes/ Unpacked classes (internal only) lib/ Classes packed in JAR files (internal only) + shared/ Classes shared by all web applications +classes/ Unpacked shared classes +lib/ Shared classes in JAR files webapps/Base directory containing web applications included with Tomcat 4.0 work/ Scratch directory used by Tomcat for holding -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4951] New: - Alias on host not work
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=4951. 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=4951 Alias on host not work Summary: Alias on host not work Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When parser process tag Alias name=tiger/, he adds an empty value, instead of 'tiger' -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Change the order of releases mentioned on the TC web page
On Mon, 19 Nov 2001, Bojan Smojver wrote: Vote to change the order of releases on the Tomcat web page: [X] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. Although we really ought to think about de-listing 3.1, or moving it to some archival page. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4951] - Alias on host not work
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=4951. 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=4951 Alias on host not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-11-19 09:11 --- That's not the correct syntax. The docs were fixed. Aliasmycompany.com/Alias *** This bug has been marked as a duplicate of 4037 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PATCH: jakarta-tomcat-connectors build on MSVC6
Here's a patch for clean builds on MSVC6 - includes a couple of missing
headers, and adds JK_METHOD attributes to the neccesary functions
(otherwise calling conventions are declared differently, and you get
compilation-fatal errors).
Michael Smith
Index: jk_channel_socket.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_channel_
socket.c,v
retrieving revision 1.2
diff -u -r1.2 jk_channel_socket.c
--- jk_channel_socket.c 2001/11/16 22:48:55 1.2
+++ jk_channel_socket.c 2001/11/19 01:06:39
@@ -73,6 +73,8 @@
#include jk_env.h
#include jk_channel.h
#include jk_global.h
+#include jk_util.h
+#include jk_connect.h
#include string.h
@@ -110,13 +112,13 @@
static int jk_channel_socket_resolve(char *host, short port,
struct sockaddr_in *rc);
-static int jk_channel_socket_getProperty(jk_channel_t *_this,
+static int JK_METHOD jk_channel_socket_getProperty(jk_channel_t *_this,
char *name, char **value)
{
return JK_FALSE;
}
-static int jk_channel_socket_setProperty(jk_channel_t *_this,
+static int JK_METHOD jk_channel_socket_setProperty(jk_channel_t *_this,
char *name, char *value)
{
jk_channel_socket_private_t *socketInfo=
@@ -134,7 +136,7 @@
/** resolve the host IP ( jk_resolve ) and initialize the channel.
*/
-static int jk_channel_socket_init(jk_channel_t *_this,
+static int JK_METHOD jk_channel_socket_init(jk_channel_t *_this,
jk_map_t *props,
char *worker_name,
jk_worker_t *worker,
@@ -203,7 +205,7 @@
/** connect to Tomcat (jk_open_socket)
*/
-static int jk_channel_socket_open(jk_channel_t *_this, jk_endpoint_t
*endpoint)
+static int JK_METHOD jk_channel_socket_open(jk_channel_t *_this,
jk_endpoint_t
*endpoint)
{
jk_logger_t *l=_this-logger;
int err=jk_log(l, JK_LOG_DEBUG, Into jk_channel_socket_open\n);
@@ -273,7 +275,7 @@
/** close the socket ( was: jk_close_socket )
*/
-int jk_channel_socket_close(jk_channel_t *_this, jk_endpoint_t
*endpoint)
+static int JK_METHOD jk_channel_socket_send(jk_channel_t *_this,
jk_endpoint_t *endpoint,
char *b, int len)
{
@@ -340,7 +342,7 @@
*0: length of the received data.
* Was: tcp_socket_recvfull
*/
-static int jk_channel_socket_recv( jk_channel_t *_this,
+static int JK_METHOD jk_channel_socket_recv( jk_channel_t *_this,
jk_endpoint_t *endpoint,
char *b, int len )
{
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PATCH: more fixes for jakarta-tomcat-connectors
Ok, so with the previous patch stuff built - this one fixes some
_really_ dodgy casts and type errors that were going on (someone 'fixed'
these by casting them to void pointers.). Also added some JK_METHOD
attributes to a couple more methods, and removed the corresponding void
pointer casts for those.
Everything builds nicely under MSVC6 now.
Michael Smith
Index: jk_env.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_env.c,v
retrieving revision 1.3
diff -u -r1.3 jk_env.c
--- jk_env.c2001/11/11 01:17:43 1.3
+++ jk_env.c2001/11/19 01:44:43
@@ -63,10 +63,10 @@
/* Private methods
*/
static jk_env_initEnv( jk_env_t *env, char *id );
-static jk_env_objectFactory_t *jk_env_getFactory(jk_env_t *env,
+static jk_env_objectFactory_t * JK_METHOD jk_env_getFactory(jk_env_t
*env,
char *type,
char *name );
-static void jk_env_registerFactory(jk_env_t *env,
+static void JK_METHOD jk_env_registerFactory(jk_env_t *env,
char *type,
char *name,
jk_env_objectFactory_t fact);
@@ -88,14 +88,14 @@
static jk_env_initEnv( jk_env_t *env, char *id ) {
/* env-logger=NULL; */
/* map_alloc( env-properties ); */
- env-getFactory= (void *)jk_env_getFactory;
- env-registerFactory= (void *)jk_env_registerFactory;
+ env-getFactory= jk_env_getFactory;
+ env-registerFactory= jk_env_registerFactory;
map_alloc( env-_registry);
jk_registry_init(env);
}
-static jk_env_objectFactory_t *jk_env_getFactory(jk_env_t *env,
+static jk_env_objectFactory_t * JK_METHOD jk_env_getFactory(jk_env_t
*env,
char *type,
char *name )
{
@@ -111,7 +111,7 @@
return result;
}
-static void jk_env_registerFactory(jk_env_t *env,
+static void JK_METHOD jk_env_registerFactory(jk_env_t *env,
char *type,
char *name,
jk_env_objectFactory_t fact)
Index: jk_env.h
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_env.h,v
retrieving revision 1.2
diff -u -r1.2 jk_env.h
--- jk_env.h2001/11/11 01:17:43 1.2
+++ jk_env.h2001/11/19 01:44:43
@@ -100,10 +100,9 @@
* for the various web servers (since the only link is through
* jk_worker_list.h).
*/
-typedef int (JK_METHOD *jk_env_objectFactory_t)(jk_env_t *env,
- void **result,
- char *type,
- char *name);
+typedef int (JK_METHOD *jk_env_objectFactory_t)(jk_worker_t **w,
+ const char *name,
+ jk_logger_t *l);
/** Get a pointer to the jk_env. We could support multiple
* env 'instances' in future - for now it's a singleton.
Index: jk_registry.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_registry
.c,v
retrieving revision 1.5
diff -u -r1.5 jk_registry.c
--- jk_registry.c 2001/11/16 22:59:06 1.5
+++ jk_registry.c 2001/11/19 01:44:44
@@ -123,11 +123,11 @@
printf(jk_registry_init: Assertion failed, env==NULL\n );
return;
}
- env-registerFactory( env, worker, ajp13, (void
*)ajp13_worker_factory )
;
- env-registerFactory( env, worker, ajp14, (void
*)ajp14_worker_factory )
;
- env-registerFactory( env, worker, lb,(void
*)lb_worker_factory );
+ env-registerFactory( env, worker, ajp13, ajp13_worker_factory
);
+ env-registerFactory( env, worker, ajp14, ajp14_worker_factory
);
+ env-registerFactory( env, worker, lb,lb_worker_factory );
#ifdef HAVE_JNI
- env-registerFactory( env, worker, jni, (void
*)jni_worker_factory );
+ env-registerFactory( env, worker, jni, jni_worker_factory );
#endif
env-registerFactory( env, channel, socket,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH: jakarta-tomcat-connectors build on MSVC6
On Mon, 19 Nov 2001, Michael Smith wrote: Here's a patch for clean builds on MSVC6 - includes a couple of missing headers, and adds JK_METHOD attributes to the neccesary functions (otherwise calling conventions are declared differently, and you get compilation-fatal errors). Thanks Michael ! Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH: jakarta-tomcat-connectors build on MSVC6
On Mon, 19 Nov 2001, Remy Maucherat wrote: On Mon, 19 Nov 2001, Michael Smith wrote: Here's a patch for clean builds on MSVC6 - includes a couple of missing headers, and adds JK_METHOD attributes to the neccesary functions (otherwise calling conventions are declared differently, and you get compilation-fatal errors). Thanks Michael ! How about giving Michael commit access ? He already has an account @Jakarta, so he just needs some additional karma. In general, I think all jakarta commiters should have cross-project permissions - maybe with the additional requirement that you need a review-then-commit process when commiting to a project you are not 'regular' commiter. There are many 'integration' bugs ( project X doesn't work with project Y ) that would be solved much quicker this way. But this is something for the PMC to decide. I'll vote +1 for any apache commiter ( i.e. jakarta, xml, httpd... ) who wants to become a commiter on tomcat. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.c jk_env.c jk_channel_socket.c
costin 01/11/19 10:14:38
Modified:jk/native/common jk_registry.c jk_env.c jk_channel_socket.c
Log:
Patch from Michael Smith.
One change I didn't apply is the signature change in jk_env_objectFactory_t.
The problem with the worker_factory is that it is specific to workers,
while objectFactory can create any kind of jk object.
In time we should replace worker_factory and use the new method. ( I'll start
this soon, I'm working on a proposal )
Revision ChangesPath
1.6 +6 -10 jakarta-tomcat-connectors/jk/native/common/jk_registry.c
Index: jk_registry.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_registry.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_registry.c 2001/11/16 22:59:06 1.5
+++ jk_registry.c 2001/11/19 18:14:38 1.6
@@ -62,7 +62,7 @@
/***
* Description: Worker list*
- * Version: $Revision: 1.5 $ *
+ * Version: $Revision: 1.6 $ *
***/
/** Static declarations for all 'hardcoded' modules. This is a hack,
@@ -123,19 +123,15 @@
printf(jk_registry_init: Assertion failed, env==NULL\n );
return;
}
- env-registerFactory( env, worker, ajp13, (void *)ajp13_worker_factory );
- env-registerFactory( env, worker, ajp14, (void *)ajp14_worker_factory );
- env-registerFactory( env, worker, lb,(void *)lb_worker_factory );
+ env-registerFactory( env, worker, ajp13, ajp13_worker_factory );
+ env-registerFactory( env, worker, ajp14, ajp14_worker_factory );
+ env-registerFactory( env, worker, lb,lb_worker_factory );
#ifdef HAVE_JNI
- env-registerFactory( env, worker, jni, (void *)jni_worker_factory );
+ env-registerFactory( env, worker, jni, jni_worker_factory );
#endif
- env-registerFactory( env, channel, socket,
- (void *)jk_channel_socket_factory );
+ env-registerFactory( env, channel, socket, jk_channel_socket_factory );
- /*
- env-registerFactory( env, channel, socket, jk_channel_socket_factory );
- */
/* Add all other factories here */
}
1.4 +16 -16jakarta-tomcat-connectors/jk/native/common/jk_env.c
Index: jk_env.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_env.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_env.c 2001/11/11 01:17:43 1.3
+++ jk_env.c 2001/11/19 18:14:38 1.4
@@ -63,13 +63,13 @@
/* Private methods
*/
static jk_env_initEnv( jk_env_t *env, char *id );
-static jk_env_objectFactory_t *jk_env_getFactory(jk_env_t *env,
- char *type,
- char *name );
-static void jk_env_registerFactory(jk_env_t *env,
-char *type,
-char *name,
-jk_env_objectFactory_t fact);
+static jk_env_objectFactory_t * JK_METHOD jk_env_getFactory(jk_env_t *env,
+char *type,
+char *name );
+static void JK_METHOD jk_env_registerFactory(jk_env_t *env,
+ char *type,
+ char *name,
+ jk_env_objectFactory_t fact);
/* XXX We should have one env per thread to avoid sync problems.
The env will provide access to pools, etc
@@ -88,16 +88,16 @@
static jk_env_initEnv( jk_env_t *env, char *id ) {
/* env-logger=NULL; */
/* map_alloc( env-properties ); */
- env-getFactory= (void *)jk_env_getFactory;
- env-registerFactory= (void *)jk_env_registerFactory;
+ env-getFactory= jk_env_getFactory;
+ env-registerFactory= jk_env_registerFactory;
map_alloc( env-_registry);
jk_registry_init(env);
}
-static jk_env_objectFactory_t *jk_env_getFactory(jk_env_t *env,
- char *type,
- char *name )
+static jk_env_objectFactory_t * JK_METHOD jk_env_getFactory(jk_env_t *env,
+char *type,
+char *name )
{
jk_env_objectFactory_t *result;
@@ -111,10 +111,10 @@
return result;
}
[VOTE] New committer: Michael Smith
Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH: jakarta-tomcat-connectors build on MSVC6
On Mon, 19 Nov 2001, Remy Maucherat wrote: In general, I think all jakarta commiters should have cross-project permissions - maybe with the additional requirement that you need a review-then-commit process when commiting to a project you are not 'regular' commiter. There are many 'integration' bugs ( project X doesn't work with project Y ) that would be solved much quicker this way. But this is something for the PMC to decide. I'll vote +1 for any apache commiter ( i.e. jakarta, xml, httpd... ) who wants to become a commiter on tomcat. Good, but according to the current policy, it's not automatic, so I'm posting a regular vote. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Michael Smith
On Mon, 19 Nov 2001, Remy Maucherat wrote: Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. +1 Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationContext.java
craigmcc01/11/19 10:25:39 Modified:catalina/src/share/org/apache/catalina/core ApplicationContext.java Log: Avoid double slashes in the values returned by something like ServletContext.getResourcePaths(/images/). Revision ChangesPath 1.33 +5 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java Index: ApplicationContext.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- ApplicationContext.java 2001/09/11 01:34:50 1.32 +++ ApplicationContext.java 2001/11/19 18:25:39 1.33 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v 1.32 2001/09/11 01:34:50 remm Exp $ - * $Revision: 1.32 $ - * $Date: 2001/09/11 01:34:50 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v 1.33 2001/11/19 18:25:39 craigmcc Exp $ + * $Revision: 1.33 $ + * $Date: 2001/11/19 18:25:39 $ * * * @@ -113,7 +113,7 @@ * * @author Craig R. McClanahan * @author Remy Maucherat - * @version $Revision: 1.32 $ $Date: 2001/09/11 01:34:50 $ + * @version $Revision: 1.33 $ $Date: 2001/11/19 18:25:39 $ */ public class ApplicationContext @@ -1063,7 +1063,7 @@ Binding binding = (Binding) childPaths.nextElement(); String name = binding.getName(); StringBuffer childPath = new StringBuffer(path); -if (!/.equals(path)) +if (!/.equals(path) !path.endsWith(/)) childPath.append(/); childPath.append(name); Object object = binding.getObject(); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer: Michael Smith
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: lunes 19 de noviembre de 2001 19:29 Para: Tomcat Developers List Asunto: [VOTE] New committer: Michael Smith Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp INSTALL.txt
remm01/11/19 10:46:32 Modified:webapp INSTALL.txt Log: - Fix typo in the package name. Submitted by Daniel Rall dlr at finemaltcoding.com, and forwarded by Jon. Revision ChangesPath 1.6 +1 -1 jakarta-tomcat-connectors/webapp/INSTALL.txt Index: INSTALL.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/INSTALL.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- INSTALL.txt 2001/11/01 22:20:51 1.5 +++ INSTALL.txt 2001/11/19 18:46:32 1.6 @@ -74,7 +74,7 @@ In this example, I'm instructing the WebApp connector to connect to the servlet container waiting for requests on the current localhost host and bound to port 8008 (note, this port is the one you specified in your -server.xml file for the org.apache.catalina.connectors.warp.WarpConnector +server.xml file for the org.apache.catalina.connector.warp.WarpConnector connector, not your HTTP one). A brief detailed description of the above-mentioned directives is: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Watchdog-4.0 - False positive from GetRealPathTestServlet
Simple patch, but
server/servlet-tests/WEB-INF/classes/tests/javax_servlet/ServletContext/GetRealPathTestServlet.java
Yeilds a false positive when the test is run.
Attached is a simple patch to rectify.
More to follow later
Index: GetRealPathTestServlet.java
===
RCS file:
/home/cvspublic/jakarta-watchdog-4.0/src/server/servlet-tests/WEB-INF/classes/tests/javax_servlet/ServletContext/GetRealPathTestServlet.java,v
retrieving revision 1.1
diff -r1.1 GetRealPathTestServlet.java
90c90
if(path!=null) {
---
if(realPath!=null) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Michael Smith
+1 - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, November 19, 2001 10:29 AM Subject: [VOTE] New committer: Michael Smith Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Watchdog-4.0 -- tag_int.jsp tests functionality notmentioned in detail in spec
Hi,
The following test:
server/jsp-tests/jsp/tagext/LifeCycle/tag_int.jsp
Is testing functionality not really explained clearly in the
Specification.
Test code:
%--
Test for defining an int variable.
--%
%@ taglib uri=/TestLib.tld prefix=x %
%! public static Integer increment(Integer i) {
if (i != null)
return new Integer(i.intValue()+1);
return new Integer(0);
}
%
%! public static int valueof(Integer i) {
if (i != null)
return i.intValue();
return 0;
}
%
x:define id=i scope=page life=nested
(1) i was %= i %; % i = increment(i); % i is now %= valueof(i) %
/x:define
x:define id=i scope=page life=nested
(2) i was %= i %; % i = increment(i); % i is now %= valueof(i) %
/x:define
x:define id=i scope=page life=at_begin
(3) i was %= i %; % i = increment(i); % i is now %= valueof(i) %
/x:define
(4) i was %= i %; % i = increment(i); % i is now %= valueof(i) %
**
GOLDENFILE OUTPUT:
(1) i was null; i is now 0
(2) i was 0; i is now 1
(3) i was 0; i is now 1
(4) i was 0; i is now 1
**
Issue:
In (3) since the life of the variable is described as at_begin the
value
should also be available via the PageContext.The value of i is not
synchronized
with the pageContext after the end of the define tag.
Hence in (4) i starts afresh with 0.
Recommendation:
The attached patch excludes the tag_int tests from running until a
clarification is made against the specification.
Index: jsp-gtest.xml
===
RCS file: /home/cvspublic/jakarta-watchdog-4.0/src/conf/jsp-gtest.xml,v
retrieving revision 1.9
diff -u -r1.9 jsp-gtest.xml
--- jsp-gtest.xml 2001/08/09 17:35:13 1.9
+++ jsp-gtest.xml 2001/11/19 19:53:47
@@ -1585,6 +1585,7 @@
/
--
+!--
gtest request=GET /jsp-tests/jsp/tagext/LifeCycle/tag_int.jsp HTTP/1.0
debug=0 host=${host} port=${port}
goldenFile=${wgdir}/tagext/LifeCycle/tag_int.html
@@ -1592,6 +1593,7 @@
assertion=Test for defining an int variable, specified in the Java Server
Pages Specification v1.2, Sec 6.4.7
testStrategy=testing LifeCycle process
/
+--
!--
gtest request=GET /jsp-tests/jsp/tagext/LifeCycle/tag_nonempty_body_1.jsp
HTTP/1.0
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4954] New: - When specifying CATALINA_BASE explicitly, that dir has to have shared/lib/jasper-*.jar in it
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=4954. 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=4954 When specifying CATALINA_BASE explicitly, that dir has to have shared/lib/jasper-*.jar in it Summary: When specifying CATALINA_BASE explicitly, that dir has to have shared/lib/jasper-*.jar in it Product: Tomcat 4 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In using the a recent nightly build (jakarta-tomcat-4.0-2009.zip), when specifying CATALINA_BASE explicitly in a different location as CATALINA_HOME, that different location has to have shared/lib/jasper-*.jar in it in order for JSP files to be compilable by Jasper and therefore run within CATALINA_BASE. Is this the future requirement when using JSPs of CATALINA_BASE (to copy the jasper libs from CATALINA_HOME's shared subdir to CATALINA_BASE's shared subdir), or can the jasper libs reside somewhere else, like in common/lib, as a default? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Change the order of releases mentioned on the TC web page
Endre Stølsvik wrote: On Mon, 19 Nov 2001, Bojan Smojver wrote: | Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the | releases in the order from the oldest to the newest in the description | section. | | I propose those are listed in the more natural order, from the newest to | the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) TC 4.0 and TC 3.3 are just as new, but implements different levels of specs. What about that? Well, as you all know, I'm a 3.3 guy, so I'd have no problems listing 3.3 first ;-) But the reality is that Tomcat 4.0 is the future since it implements a newer specification set. Therefore it should be listed first. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Change the order of releases mentioned on the TC web page
Agreed. Bojan Larry Isaacs wrote: +1, I would also be +1 for listing Servlet 2.3/JSP 1.2/Tomcat 4.0 first in the impatient section as well, since that spec is newer. Larry P.S. I remembered to update the news page, but not this one. Thanks for noticing. -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 12:18 AM To: Tomcat Dev List Subject: [VOTE] Change the order of releases mentioned on the TC web page Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the releases in the order from the oldest to the newest in the description section. I propose those are listed in the more natural order, from the newest to the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) Vote to change the order of releases on the Tomcat web page: [ ] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Change the order of releases mentioned on the TC web page
+1 Amy Bojan Smojver wrote: Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the releases in the order from the oldest to the newest in the description section. I propose those are listed in the more natural order, from the newest to the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x) Vote to change the order of releases on the Tomcat web page: [ ] +1. I agree with the proposal and I will help support it. [ ] +0. I agree with the proposal but I will not be able support it. [ ] -0. I don't agree with the proposal but I won't stop it. [ ] -1. I disagree with the proposal and will explain my reasons. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Michael Smith
+1 Amy Remy Maucherat wrote: Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [JTC] APACHE_CONFIG_VARS and 2.0.28 / jkant
I'm currently stucked with Apache 2.0.27/2.0.28
and the config_vars.mk used in JTC (jk/webapp).
It's still unclear if we should included it in all
make file and what to do when you install Apache 2.0 in a
FHS manner, as does my RPM, everything is broken.
All the Apache stuff assume everything under $prefix, which
is not the case in the FHS method (/var/www2/{manual, error, html, icons),
/etc/httpd2/conf/, /var/log/httpd2/, /var/run/httpd2.pid.
I've got to patch heavily apxs, apachectl and httpd.conf/ssl.conf
to make it works, but the config_vars.mk path is still constructed
from $prefix/build/config_vars.mk whereas it should be presented
by APXS with -q (ie apxs -q CONFIG_VARS.MK). I send today many
mails on Tomcat-dev (for JTC devs) and on new-httpd list
and hope some of this points will be fixed, but I'm not Apache 2.0
commiter and so could apply necessary patches ;(
BTW, build.xml for jkant will also need updates since we
assume to have include under apache.home/include and on
Linux FHS it's on /usr/include/apache or /usr/include/apache2
A patch is attached, I'll try to commit it tomorrow :)
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 19, 2001 3:33 PM
To: Tomcat Developers List
Subject: [JTC] APACHE_CONFIG_VARS and 2.0.28
Hi to all JTCs,
I'm trying to rebuild jk and webapp from JTC and
notice we try to include config_vars.mk, which
is awaited under $prefix/build/.
Problem, it fit well for Apache 2.0 using default
packaging (ie all under /usr/local/apache) but fail
when we have it installed under another directory,
ie /usr/lib/apache2 (see my latest RPM), to make
it more FHS compatible.
What could we do to have JTC works in such situation
since I'm not sure we need to included config_vars.mk !!!
build.xml.diff
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Watchdog-4.0 - GTest patch for whitspace comparison.
Hi,
After reading through GTest, and the JSP/Servlet-Gtest.xml, none of the
tests set the exactMatch property to true to do whitespace comparison
between the response from the server, and the contents of the
goldenfile. This patch, will make GTest do a byte for byte comparison
of the response and goldenfile. If any length or byte differeces
appear, it will dump a hex representation (ascii on the right side, hex
on the left) to help the test writer figure out what's wrong. Make's
it easier in my opinion anyway :).
I plan to start going through and correcting the whitespace issues as
I come across them, so there will probably be more patches to come down
the pipe.
Anyway, attached is the patch to GTest (GTest.patch.txt) as well as
sample output (sample.txt) of what this code produces when exactMatch is
set to true.
Anyone care to comment?
Thanks,
-rl
Index: GTest.java
===
RCS file:
/home/cvspublic/jakarta-watchdog-4.0/src/tools/org/apache/tomcat/task/GTest.java,v
retrieving revision 1.3
diff -u -r1.3 GTest.java
--- GTest.java 2001/09/28 04:09:56 1.3
+++ GTest.java 2001/11/19 21:36:00
@@ -15,6 +15,11 @@
// derived from Jsp
public class GTest extends Task {
+
+private static final String ZEROS = ;
+private static final int SHORTPADSIZE = 4;
+private static final int BYTEPADSIZE = 2;
+
String prefix=http://localhost:8080/test;;
String host=localhost;
int port=8080;
@@ -376,9 +381,9 @@
boolean cmp=true;
if(exactMatch)
- cmp=compare(responseBody, expResult.toString() );
+ cmp=compare(responseBody.getBytes(), expResult.toString().getBytes() );
else
- cmp=compareWeek( responseBody, expResult.toString());
+ cmp=compareWeak( responseBody, expResult.toString());
if( cmp != testCondition ) {
responseStatus = false;
@@ -521,30 +526,200 @@
}
}
+/*
+ * codecompare/code compares the two byte arrays passed
+ * in to verify that the lengths of the arrays are equal, and
+ * that the content of the two arrays, byte for byte are equal.
+ *
+ * @param fromServer a codebyte[]/code value
+ * @param fromGoldenFile a codebyte[]/code value
+ * @return codeboolean/code true if equal, otherwise false
+ */
+private boolean compare( byte[] fromServer, byte[] fromGoldenFile ) {
+if ( fromServer == null || fromGoldenFile == null ) {
+return false;
+}
+
+/*
+ * Check to see that the respose and golden file lengths
+ * are equal. If they are not, dump the hex and don't
+ * bother comparing the bytes. If they are equal,
+ * iterate through the byte arrays and compare each byte.
+ * If the bytes don't match, dump the hex representation
+ * of the server response and the goldenfile and return
+ * false.
+ */
+
+if ( fromServer.length != fromGoldenFile.length ) {
+StringBuffer sb = new StringBuffer( 50 );
+sb.append( Response and golden file lengths do not match!\n );
+sb.append( Server response length: );
+sb.append( fromServer.length );
+sb.append( \nGoldenfile length: );
+sb.append( fromGoldenFile.length );
+System.out.println( sb.toString() );
+sb = null;
+// dump the hex representation of the byte arrays
+dumpHex( fromServer, fromGoldenFile );
+
+return false;
+
+} else {
+
+int i = 0;
+int j = 0;
+
+while ( ( i fromServer.length ) ( j fromGoldenFile.length ) ) {
+if ( fromServer[ i ] != fromGoldenFile[ j ] ) {
+System.out.println( Error at position + ( i + 1 ) );
-// Compare the actual result and the expected result.
-private boolean compare(String str1, String str2) {
- //System.out.println(In compare);
- if ( str1==null || str2==null) return false;
- if ( str1.length() != str2.length() ) {
- System.out.println(Wrong size + str1.length() + + str2.length() );
- return false;
- }
-
-for(int i=0; istr1.length() ; i++ ) {
-if (str1.charAt( i ) != str2.charAt( i ) ) {
- System.out.println(Error at + i + + str1.charAt(1) +
- str2.charAt(i));
-return false;
+// dump the hex representation of the byte arrays
+dumpHex( fromServer, fromGoldenFile );
+
+return false;
+}
+
+i++;
+j++;
+}
+}
+
+return true;
+}
+
+/*
+ * codedumpHex/code helper method to dump formatted
+ * hex output of the server response and the goldenfile.
+ *
+ * @param
Re: [PATCH] Watchdog-4.0 - GTest patch for whitspace comparison.
Forgot to mention, I changed the method name : compareWeek, to
compareWeak.
On Mon, 2001-11-19 at 17:04, Ryan Lubke wrote:
Hi,
After reading through GTest, and the JSP/Servlet-Gtest.xml, none of the
tests set the exactMatch property to true to do whitespace comparison
between the response from the server, and the contents of the
goldenfile. This patch, will make GTest do a byte for byte comparison
of the response and goldenfile. If any length or byte differeces
appear, it will dump a hex representation (ascii on the right side, hex
on the left) to help the test writer figure out what's wrong. Make's
it easier in my opinion anyway :).
I plan to start going through and correcting the whitespace issues as
I come across them, so there will probably be more patches to come down
the pipe.
Anyway, attached is the patch to GTest (GTest.patch.txt) as well as
sample output (sample.txt) of what this code produces when exactMatch is
set to true.
Anyone care to comment?
Thanks,
-rl
Index: GTest.java
===
RCS file:
/home/cvspublic/jakarta-watchdog-4.0/src/tools/org/apache/tomcat/task/GTest.java,v
retrieving revision 1.3
diff -u -r1.3 GTest.java
--- GTest.java2001/09/28 04:09:56 1.3
+++ GTest.java2001/11/19 21:36:00
@@ -15,6 +15,11 @@
// derived from Jsp
public class GTest extends Task {
+
+private static final String ZEROS = ;
+private static final int SHORTPADSIZE = 4;
+private static final int BYTEPADSIZE = 2;
+
String prefix=http://localhost:8080/test;;
String host=localhost;
int port=8080;
@@ -376,9 +381,9 @@
boolean cmp=true;
if(exactMatch)
- cmp=compare(responseBody, expResult.toString() );
+ cmp=compare(responseBody.getBytes(), expResult.toString().getBytes() );
else
- cmp=compareWeek( responseBody, expResult.toString());
+ cmp=compareWeak( responseBody, expResult.toString());
if( cmp != testCondition ) {
responseStatus = false;
@@ -521,30 +526,200 @@
}
}
+/*
+ * codecompare/code compares the two byte arrays passed
+ * in to verify that the lengths of the arrays are equal, and
+ * that the content of the two arrays, byte for byte are equal.
+ *
+ * @param fromServer a codebyte[]/code value
+ * @param fromGoldenFile a codebyte[]/code value
+ * @return codeboolean/code true if equal, otherwise false
+ */
+private boolean compare( byte[] fromServer, byte[] fromGoldenFile ) {
+if ( fromServer == null || fromGoldenFile == null ) {
+return false;
+}
+
+/*
+ * Check to see that the respose and golden file lengths
+ * are equal. If they are not, dump the hex and don't
+ * bother comparing the bytes. If they are equal,
+ * iterate through the byte arrays and compare each byte.
+ * If the bytes don't match, dump the hex representation
+ * of the server response and the goldenfile and return
+ * false.
+ */
+
+if ( fromServer.length != fromGoldenFile.length ) {
+StringBuffer sb = new StringBuffer( 50 );
+sb.append( Response and golden file lengths do not match!\n );
+sb.append( Server response length: );
+sb.append( fromServer.length );
+sb.append( \nGoldenfile length: );
+sb.append( fromGoldenFile.length );
+System.out.println( sb.toString() );
+sb = null;
+// dump the hex representation of the byte arrays
+dumpHex( fromServer, fromGoldenFile );
+
+return false;
+
+} else {
+
+int i = 0;
+int j = 0;
+
+while ( ( i fromServer.length ) ( j fromGoldenFile.length ) ) {
+if ( fromServer[ i ] != fromGoldenFile[ j ] ) {
+System.out.println( Error at position + ( i + 1 ) );
-// Compare the actual result and the expected result.
-private boolean compare(String str1, String str2) {
- //System.out.println(In compare);
- if ( str1==null || str2==null) return false;
- if ( str1.length() != str2.length() ) {
- System.out.println(Wrong size + str1.length() + + str2.length() );
- return false;
- }
-
-for(int i=0; istr1.length() ; i++ ) {
-if (str1.charAt( i ) != str2.charAt( i ) ) {
- System.out.println(Error at + i + + str1.charAt(1) +
-str2.charAt(i));
-return false;
+// dump the hex representation of the byte arrays
+dumpHex( fromServer, fromGoldenFile );
+
+return false;
+}
+
+i++;
DO NOT REPLY [Bug 4955] New: - Page forward failure on URL parameter with no value (String index out of range)
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=4955. 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=4955 Page forward failure on URL parameter with no value (String index out of range) Summary: Page forward failure on URL parameter with no value (String index out of range) Product: Tomcat 3 Version: 3.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When the Wiki convention of using a parameter with no value is used in the page attribute of a jsp:forward tag a 'String index out of bounds exception' is thrown for the index value where an '=' would normally be. E.g. jsp:forward page=wiki.jsp?MyTopic/ produces an exception at 7. The exception does not occur on a normally (user) entered URL or link - only on a 'forward'. The exception does not occur in Tomcat 3.2 or 4.0. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.c jk_env.c jk_channel_socket.c
[EMAIL PROTECTED] wrote: costin 01/11/19 10:14:38 Modified:jk/native/common jk_registry.c jk_env.c jk_channel_socket.c Log: Patch from Michael Smith. One change I didn't apply is the signature change in jk_env_objectFactory_t. The problem with the worker_factory is that it is specific to workers, while objectFactory can create any kind of jk object. In time we should replace worker_factory and use the new method. ( I'll start this soon, I'm working on a proposal ) Ah. That'd be my misunderstanding of how things work... _without_ that signature change, though, things still won't compile (well, they probably will. With _really_ nasty warnings). I suppose the right thing to do here is to change env-registerFactory() to take a void * as the last argument - then we're making _explicit_ the fact that we're doing Very Dodgy Things :-) Since we're casting this argument later on anyway (because it isn't what it's declared at) this should be a local change, but I'll have to check. Does this sound sensible? It's worth noting (but not actually worth changing things) that C doesn't allow you to portably cast function pointers to data pointers (and a void pointer IS a data pointer). I've not yet encountered an actual implementation where this is an issue, but a lot of compilers warn about it. Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4956] New: - There are two BODY tags found in a source code
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=4956. 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=4956 There are two BODY tags found in a source code Summary: There are two BODY tags found in a source code Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the http source code of the HelloWorldExample I found two BODY tags. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.c jk_env.c jk_channel_socket.c
On Tue, 20 Nov 2001, Michael Smith wrote: Ah. That'd be my misunderstanding of how things work... _without_ that signature change, though, things still won't compile (well, they probably will. With _really_ nasty warnings). I suppose the right thing to do here is to change env-registerFactory() to take a Well, the right thing would be to change the workers to use the right factory method. It is on my todo list, I hope to get to it this week. It's worth noting (but not actually worth changing things) that C doesn't allow you to portably cast function pointers to data pointers (and a void pointer IS a data pointer). I've not yet encountered an actual implementation where this is an issue, but a lot of compilers warn about it. Sorry, it's a long time since I last programmed C. I have a hard time re-getting used with it :-) Exceptions/stackTrace are the thing I miss the most, followed by getters/setters. ( for the second - I think I'll add get/setProperty to all new objects, for the first - I'm still looking for a trick that doesn't involve setjmp ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.cjk_env.c jk_channel_socket.c
[EMAIL PROTECTED] wrote: On Tue, 20 Nov 2001, Michael Smith wrote: Ah. That'd be my misunderstanding of how things work... _without_ that signature change, though, things still won't compile (well, they probably will. With _really_ nasty warnings). I suppose the right thing to do here is to change env-registerFactory() to take a Well, the right thing would be to change the workers to use the right factory method. It is on my todo list, I hope to get to it this week. oh, ok - that's fine then. Things work anyway because everything gets cast in 15 different directions before it actually get used, but I tend to be fairly zealous in trying to get code I work on or use to compile without warnings :-) It's worth noting (but not actually worth changing things) that C doesn't allow you to portably cast function pointers to data pointers (and a void pointer IS a data pointer). I've not yet encountered an actual implementation where this is an issue, but a lot of compilers warn about it. Sorry, it's a long time since I last programmed C. I have a hard time re-getting used with it :-) Exceptions/stackTrace are the thing I miss the most, followed by getters/setters. ( for the second - I think I'll add get/setProperty to all new objects, for the first - I'm still looking for a trick that doesn't involve setjmp ) Not a problem.. Just thought I'd point it out. Exceptions are nice, but there isn't any portable way to implement them in C (apart from setjmp tricks, but that has a tendency to play havoc with... well, everything, if you use them in a larger program.) - when you do most of your programming in C, you get used to it and find different ways to design your code (and hey, I _like_ C. Call me insane if you will - you wouldn't be the first :-)) Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] - Watchdog 4.0 - 3 New HttpServletResponse tests + Patchesto support new tests.
Hi,
I've added 3 tests to javax_servlet_http/HttpServletResponse to
validate that headers set after sendError() or sendRedirect are
called are ignored by the container (this was an issue at one point).
The 3 new tests are:
SendErrorIgnoreHeaderTestServlet.java
SendError_StringIgnoreHeaderTestServlet.java
SendRedirectIgnoreHeaderTestServlet.java
These should be placed in
${WATCHDOG{/src/server/servlet-tests/WEB-INF/classes/tests/javax_servlet_http/HttpServletResponse
To support these tests, I've added a new method to GTest,
setUnexpectedHeaders (set in the servlet or jsp gtest.xml like so:
unexpectedHeaders=key:value ).
This will setup a hashtable of headers to compare against the server
response. The logic to checkResponse has been updated accordingly.
More to come.
Comments welcome.
-rl
Index: GTest.java
===
RCS file:
/home/cvspublic/jakarta-watchdog-4.0/src/tools/org/apache/tomcat/task/GTest.java,v
retrieving revision 1.3
diff -u -r1.3 GTest.java
--- GTest.java 2001/09/28 04:09:56 1.3
+++ GTest.java 2001/11/19 23:54:31
@@ -35,6 +35,10 @@
String responseMatch;
// the response should include the following headers
Hashtable expectHeaders;
+
+// the response should not include the following headers
+Hashtable unexpectedHeaders;
+
// Match request line
String returnCode=;
@@ -197,10 +201,21 @@
//Ramesh
public void setExpectHeaders( String s ) {
- this.expectHeaders=new Hashtable();
- getHeaderDetails( s, expectHeaders );
+this.expectHeaders=new Hashtable();
+getHeaderDetails( s, expectHeaders );
- //parseHeader( s, expectHeaders );
+//parseHeader( s, expectHeaders );
+}
+
+ /**
+ * codesetUnexpectedHeaders/code sets an ArrayList
+ * with headers that are not expected to be found in a response
+ *
+ * @param s a codeString/code value
+ */
+public void setUnexpectedHeaders( String s ) {
+this.unexpectedHeaders = new Hashtable();
+getHeaderDetails( s, unexpectedHeaders );
}
public void setResponseMatch( String s ) {
@@ -329,30 +344,46 @@
if( expectHeaders != null ) {
// Check if we got the expected headers
if(headers==null) {
- System.out.println(ERROR no response header, expecting header);
+System.out.println(ERROR no response header, expecting header);
}
Enumeration e=expectHeaders.keys();
while( e.hasMoreElements()) {
- String key=(String)e.nextElement();
- String value=(String)expectHeaders.get(key);
- String respValue=(String)headers.get(key);
- if( respValue==null || respValue.indexOf( value ) 0 ) {
- System.out.println(ERROR expecting header + key + : +
- value + GOT: + respValue+ HEADERS( +
headers + ));
- if ( resultOut != null )
- {
- expectedString = expectedHeader + key + :+ value
+ /expectedHeader\n;
- actualString = actualHeader+ key + : + respValue
+ /actualHeader\n;
- resultOut.write(expectedString.getBytes() );
- resultOut.write(actualString.getBytes() );
+String key=(String)e.nextElement();
+String value=(String)expectHeaders.get(key);
+String respValue=(String)headers.get(key);
+if( respValue==null || respValue.indexOf( value ) 0 ) {
+System.out.println(ERROR expecting header + key + : +
+ value + GOT: + respValue+ HEADERS( +
+headers + ));
+if ( resultOut != null )
+{
+expectedString = expectedHeader + key + :+ value +
+/expectedHeader\n;
+actualString = actualHeader+ key + : + respValue +
+/actualHeader\n;
+resultOut.write(expectedString.getBytes() );
+resultOut.write(actualString.getBytes() );
- }
+}
- return false;
- }
+return false;
+}
}
-
}
+
+// check to see if any unexpected headers we're recieved
+if ( unexpectedHeaders != null ) {
+if ( headers != null ) {
+Enumeration e = unexpectedHeaders.keys();
+while( e.hasMoreElements() ) {
+String key = (String) e.nextElement();
+String value = (String) unexpectedHeaders.get( key );
+String respValue = (String) headers.get( key );
+if ( respValue != null respValue.indexOf( value ) 0 ) {
+System.out.println( ERROR Unexpected header: + key + : +
+value +
+
DO NOT REPLY [Bug 4959] New: - jasper error if the jsp name is only formed by numbers
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=4959. 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=4959 jasper error if the jsp name is only formed by numbers Summary: jasper error if the jsp name is only formed by numbers Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The name of my jsps projects are only numbers for example 101010297.jsp I use this extrange names because i descompose the jsp name and i get the section where the jsp is, extrange but i thing is usefull. I'm new with tomcat and i can't make it, i always have a jasper exception, and if i change the jsp name to jsp101010297.jps, all is ok. Is a bug?? (Is the first time that i report one) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.cjk_env.c jk_channel_socket.c
On Tue, 20 Nov 2001, Michael Smith wrote: Not a problem.. Just thought I'd point it out. Exceptions are nice, but there isn't any portable way to implement them in C (apart from setjmp tricks, but that has a tendency to play havoc with... well, everything, if you use them in a larger program.) - when you do most of your programming in C, you get used to it and find different ways to design your code (and hey, I _like_ C. Call me insane if you will - you wouldn't be the first :-)) I was thinking to something simpler - similar with what JNI is doing. In jk_env ( which needs to be extended so each thread will get an individual copy - including a pool, etc ) we can add a 'lastException' field, with a string error message. Throw will just set it, and the caller will still have to check it explicitely ( as in JNI programming - which is not very difficult ). For stack traces - again in jk_env we can have a small array, and each method could have a ENTRY/EXIT macro at start and end ( the overhead is very small - just copying a pointer and incrementing a counter, and it can be disabled easily ). Object oriented programming is not bad, most complex programs are doing that (look at GNOME's object system ). We don't need something that sophisticated, but this kind of tools would make it much easier for java programmers to understand and contribute to jk. In the same topic - using get/setProperty for configuring the objects ( java style). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: CS143
Hey Micael, you sent this letter to [EMAIL PROTECTED], not the person you intended Ed --- Micael Padraig Og mac Grene [EMAIL PROTECTED] wrote: Hi, Greg, I am working late tonight, cannot sleep. So, I thought I would put together a little grading tool for CS143. If you like it, feel free to change it, use it, sell it, whatever. ;-) The way it works is you put the unzipped files in c:\jdk1.3\jre\classes\ and go there on the command line or any IDE tool that runs the java command and run java cs143.test.Test. A screen will come up and, if you were a student, you would enter cs143 harry harry (course, name, password). This will tell the student, if their class implements the tag interface Testable whether or not they pass the test set for their class. You can give the test the class must test prior to them building the classes. The student can keep changing their classes until they get a pass. Each attempt is recording it a log file. I sent a copy to Erika, in case Mark Vanbeek might find it helpful. Hope he can join us Tuesday. Micael ATTACHMENT part 2 application/x-zip-compressed name=cs143.zip -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4961] New: - JDBCStore problems with Oracle, others(?)
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=4961. 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=4961 JDBCStore problems with Oracle, others(?) Summary: JDBCStore problems with Oracle, others(?) Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Looking at the source code for JDBCStore.java, i found a query in public String [] keys() that does not run under Oracle... The query is select count(s.id), s.id from session s, session c group by c.id. Oracle throws an ORA-00979: not a GROUP BY expression -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm01/11/19 19:33:07
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- After (late) review by Glenn, it turns out that the permission checks are not
needed, and would be bad in some ways since that would force running
Catalina with AllPermissions (which isn't required).
Thanks to Glenn for the help.
Revision ChangesPath
1.29 +4 -29
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- WebappClassLoader.java2001/11/15 02:20:32 1.28
+++ WebappClassLoader.java2001/11/20 03:33:07 1.29
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.28 2001/11/15 02:20:32 remm Exp $
- * $Revision: 1.28 $
- * $Date: 2001/11/15 02:20:32 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.29 2001/11/20 03:33:07 remm Exp $
+ * $Revision: 1.29 $
+ * $Date: 2001/11/20 03:33:07 $
*
*
*
@@ -122,7 +122,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.28 $ $Date: 2001/11/15 02:20:32 $
+ * @version $Revision: 1.29 $ $Date: 2001/11/20 03:33:07 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -371,9 +371,6 @@
*/
public void setDebug(int debug) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
this.debug = debug;
}
@@ -396,9 +393,6 @@
*/
public void setDelegate(boolean delegate) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
this.delegate = delegate;
}
@@ -441,7 +435,6 @@
*/
public void addPermission(Permission permission) {
if ((securityManager != null) (permission != null)) {
-securityManager.checkPermission(allPermission);
permissionList.add(permission);
}
}
@@ -462,9 +455,6 @@
*/
public void setJarPath(String jarPath) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
this.jarPath = jarPath;
}
@@ -485,9 +475,6 @@
*/
public void addRepository(String repository) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
// Ignore any of the standard repositories, as they are set up using
// either addJar or addRepository
if (repository.startsWith(/WEB-INF/lib)
@@ -518,9 +505,6 @@
*/
synchronized void addRepository(String repository, File file) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
// Note : There should be only one (of course), but I think we should
// keep this a bit generic
@@ -554,9 +538,6 @@
synchronized void addJar(String jar, JarFile jarFile, File file)
throws IOException {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
if (jar == null)
return;
if (jarFile == null)
@@ -1470,9 +1451,6 @@
*/
public void start() throws LifecycleException {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
started = true;
}
@@ -1484,9 +1462,6 @@
* @exception LifecycleException if a lifecycle error occurs
*/
public void stop() throws LifecycleException {
-
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
started = false;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm01/11/19 21:06:35
Modified:catalina/src/share/org/apache/catalina/loader Tag:
tomcat_40_branch WebappClassLoader.java
Log:
- After (late) review by Glenn, it turns out that the permission checks are not
needed, and would be bad in some ways since that would force running
Catalina with AllPermissions (which isn't required).
Thanks to Glenn for the help.
Revision ChangesPath
No revision
No revision
1.15.2.8 +4 -29
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.15.2.7
retrieving revision 1.15.2.8
diff -u -r1.15.2.7 -r1.15.2.8
--- WebappClassLoader.java2001/11/03 02:27:32 1.15.2.7
+++ WebappClassLoader.java2001/11/20 05:06:34 1.15.2.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.15.2.7 2001/11/03 02:27:32 remm Exp $
- * $Revision: 1.15.2.7 $
- * $Date: 2001/11/03 02:27:32 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.15.2.8 2001/11/20 05:06:34 remm Exp $
+ * $Revision: 1.15.2.8 $
+ * $Date: 2001/11/20 05:06:34 $
*
*
*
@@ -122,7 +122,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.15.2.7 $ $Date: 2001/11/03 02:27:32 $
+ * @version $Revision: 1.15.2.8 $ $Date: 2001/11/20 05:06:34 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -365,9 +365,6 @@
*/
public void setDebug(int debug) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
this.debug = debug;
}
@@ -390,9 +387,6 @@
*/
public void setDelegate(boolean delegate) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
this.delegate = delegate;
}
@@ -406,7 +400,6 @@
*/
public void setPermissions(String path) {
if (securityManager != null) {
-securityManager.checkPermission(allPermission);
if( path.startsWith(jndi:) || path.startsWith(jar:jndi:) ) {
permissionList.add(new JndiPermission(path + *));
} else {
@@ -442,9 +435,6 @@
*/
public void setJarPath(String jarPath) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
this.jarPath = jarPath;
}
@@ -465,9 +455,6 @@
*/
public void addRepository(String repository) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
// Ignore any of the standard repositories, as they are set up using
// either addJar or addRepository
if (repository.startsWith(/WEB-INF/lib)
@@ -497,9 +484,6 @@
*/
synchronized void addRepository(String repository, File file) {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
// Note : There should be only one (of course), but I think we should
// keep this a bit generic
@@ -533,9 +517,6 @@
synchronized void addJar(String jar, JarFile jarFile, File file)
throws IOException {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
if (jar == null)
return;
if (jarFile == null)
@@ -1436,9 +1417,6 @@
*/
public void start() throws LifecycleException {
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
-
started = true;
}
@@ -1450,9 +1428,6 @@
* @exception LifecycleException if a lifecycle error occurs
*/
public void stop() throws LifecycleException {
-
-if (securityManager != null)
-securityManager.checkPermission(allPermission);
started = false;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/http Parameters.java
billbarker01/11/19 21:38:30
Modified:src/share/org/apache/tomcat/util/http Parameters.java
Log:
Handle missing '=' from RequestDispatcher.include.
Fix for bug #4955
Reported By: Gareth Cronin [EMAIL PROTECTED]
Revision ChangesPath
1.19 +1 -0
jakarta-tomcat/src/share/org/apache/tomcat/util/http/Parameters.java
Index: Parameters.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/http/Parameters.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- Parameters.java 2001/09/14 04:16:35 1.18
+++ Parameters.java 2001/11/20 05:38:30 1.19
@@ -542,6 +542,7 @@
int nameStart=pos;
int nameEnd=str.indexOf('=', nameStart );
int nameEnd2=str.indexOf('', nameStart );
+ if( nameEnd2== -1 ) nameEnd2=end;
if( (nameEnd2!=-1 )
( nameEnd==-1 || nameEnd nameEnd2) ) {
nameEnd=nameEnd2;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4955] - Page forward failure on URL parameter with no value (String index out of range)
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=4955. 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=4955 Page forward failure on URL parameter with no value (String index out of range) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-19 21:54 --- This has been fixed in the CVS HEAD, and will appear in the next nightly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin saved.jsp
patrickl01/11/19 21:54:03 Added: webapps/admin saved.jsp Log: New success file Revision ChangesPath 1.1 jakarta-tomcat-4.0/webapps/admin/saved.jsp Index: saved.jsp === !-- Standard Struts Entries -- %@ page language=java % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % html:html locale=true !-- Standard Content -- %@ include file=header.jsp % !-- Body -- body bgcolor=white center h2 bean:message key=save.success/ /h2 /center /body !-- Standard Footer -- %@ include file=footer.jsp % /html:html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4948] - Class.getPackage() returns null in classes loaded by webapp class loader
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=4948. 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=4948 Class.getPackage() returns null in classes loaded by webapp class loader --- Additional Comments From [EMAIL PROTECTED] 2001-11-19 22:42 --- The problem is that by loading from parent rather than parent2, Tomcat will no longer do an automatic reload if you make changes in WEB-INF/classes. Of course, you can still cause a reload by touching web.xml after you update the classes. If this works for you, by all means continue with the change backed out. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.1.txt
billbarker01/11/19 22:39:21 Modified:.RELEASE-NOTES-3.3.1.txt Log: Update to reflect change to o.a.t.util.http.Parameters Revision ChangesPath 1.4 +4 -1 jakarta-tomcat/RELEASE-NOTES-3.3.1.txt Index: RELEASE-NOTES-3.3.1.txt === RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.1.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- RELEASE-NOTES-3.3.1.txt 2001/11/17 06:34:08 1.3 +++ RELEASE-NOTES-3.3.1.txt 2001/11/20 06:39:21 1.4 @@ -3,7 +3,7 @@ Release Notes = -$Id: RELEASE-NOTES-3.3.1.txt,v 1.3 2001/11/17 06:34:08 billbarker Exp $ +$Id: RELEASE-NOTES-3.3.1.txt,v 1.4 2001/11/20 06:39:21 billbarker Exp $ This document describes the changes that have been made since the @@ -64,6 +64,9 @@ untrusted web applications couldn't run the JspServlet because jasper.jar and tools.jar weren't accessible. +4955 Fixed bug in the parsing of the query string to + RequestDispatcher.include/forward wasn't handling the case where only + the parameter name was specified. Configuration: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4826] - Can't configure AutoWebApp dir to absolute value on Windows
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=4826. 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=4826 Can't configure AutoWebApp dir to absolute value on Windows [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-19 23:03 --- It seems that this has already been fixed, and has been in the nightly build for about a week now. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
