DO NOT REPLY [Bug 34192] - jsvc compilation failure: x86_64 not supported
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34192 --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 11:36 --- (In reply to comment #1) Whic configure script did you have in mind? There are four in the jakarta-tomcat-connectors module: one for JK, one for JK2, one for native JNI, and one for the mod_webapp connector. None of them have close to 2630 lines... the one to run tomcat as service under linux, in the jsvc-src directory. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Henri Yandell wrote: 19 votes were recorded, and thus the proposed Tomcat PMC is: Keith Wannamaker (keith) Mark Thomas (markt) Larry Isaacs (larryi) Filip Hanik (fhanik) Tim Funk (funkman) Kin-man Chung (kinman) Henri Gomez (hgomez) Mladen Turk (mturk) Costin Manolache (costin) Jim Jagielski (jim) Bill Barker (billbarker) Ian Darwin (idarwin) Peter Rossbach (pero) Kurt Miller (truk) Glenn Nielsen (glenn) Jean-Frederic Clere (jfclere) Amy Roh (amyroh) Jeanfrancois Arcand (jfarcand) Remy Maucherat (remm) Yoav Shapira (yoavs) The result was: 13 - Remy 5 - Yoav 1 - Costin (that's funny, but I can count 20 people) Thanks a lot for taking care of this, which also was a great mechanism for determining who would be on the PMC (I don't see Jan Luehe there, though, so he would have to be added to the list). And thanks to the voters, of course ;) What's the next step now ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Request.java
remm2005/04/01 03:36:52
Modified:catalina/src/share/org/apache/catalina/realm
GenericPrincipal.java JAASRealm.java
catalina/src/share/org/apache/catalina/connector
Request.java
Log:
- Commit my proposed changes to GenericPrincipal, and use it to remove the
role map in the JAAS realm.
- Let me know if I did it wrong ;)
Revision ChangesPath
1.5 +33 -14
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/GenericPrincipal.java
Index: GenericPrincipal.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/GenericPrincipal.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- GenericPrincipal.java 27 Feb 2004 14:58:45 - 1.4
+++ GenericPrincipal.java 1 Apr 2005 11:36:51 - 1.5
@@ -65,25 +65,29 @@
*/
public GenericPrincipal(Realm realm, String name, String password,
List roles) {
-
-super();
-this.realm = realm;
-this.name = name;
-this.password = password;
-if (roles != null) {
-this.roles = new String[roles.size()];
-this.roles = (String[]) roles.toArray(this.roles);
-if (this.roles.length 0)
-Arrays.sort(this.roles);
-}
+this(realm, name, password, roles, null);
}
-public GenericPrincipal(String name, String password,
-List roles) {
+/**
+ * Construct a new Principal, associated with the specified Realm, for
the
+ * specified username and password, with the specified role names
+ * (as Strings).
+ *
+ * @param realm The Realm that owns this principal
+ * @param name The username of the user represented by this Principal
+ * @param password Credentials used to authenticate this user
+ * @param roles List of roles (must be Strings) possessed by this user
+ * @param userPrincipal - the principal to be returned from the request
+ *getUserPrincipal call if not null; if null, this will be
returned
+ */
+public GenericPrincipal(Realm realm, String name, String password,
+List roles, Principal userPrincipal) {
super();
+this.realm = realm;
this.name = name;
this.password = password;
+this.userPrincipal = userPrincipal;
if (roles != null) {
this.roles = new String[roles.size()];
this.roles = (String[]) roles.toArray(this.roles);
@@ -92,6 +96,7 @@
}
}
+
// -
Properties
@@ -140,6 +145,20 @@
}
+/**
+ * The authenticated Principal to be exposed to applications.
+ */
+protected Principal userPrincipal = null;
+
+public Principal getUserPrincipal() {
+if (userPrincipal != null) {
+return userPrincipal;
+} else {
+return this;
+}
+}
+
+
// - Public
Methods
1.12 +3 -63
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JAASRealm.java
Index: JAASRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JAASRealm.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JAASRealm.java6 Oct 2004 16:11:34 - 1.11
+++ JAASRealm.java1 Apr 2005 11:36:51 - 1.12
@@ -20,9 +20,7 @@
import java.security.Principal;
import java.util.ArrayList;
-import java.util.HashMap;
import java.util.Iterator;
-import java.util.Map;
import java.util.List;
import javax.security.auth.Subject;
@@ -170,12 +168,6 @@
*/
protected List userClasses = new ArrayList();
- /**
- * Map associating each user codePrincipal/code object
- * with an array of role codePrincipal/codes.
- * This Map is read when codehasRole/code is called.
- */
- protected Map roleMap = new HashMap();
/**
* Whether to use context ClassLoader or default ClassLoader.
@@ -417,52 +409,6 @@
}
}
- /**
- * Returns codetrue/code if the specified user
codePrincipal/code has the specified
- * security role, within the context of this codeRealm/code;
otherwise return
- * codefalse/code. This will be true when
- * an associated role codePrincipal/code can be found whose
codegetName/code
-
DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=15845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=15845 --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 13:43 --- (In reply to comment #20) Unneded objects created for JSP page compiles are now dereferenced so that they are eligible for GC. Patch applied to both Tomcat 4.1 Jasper 2 and Tomcat 5.0 Jasper 2. We have just hit on this problem in a production system (build 4.1.18). The problem is particularly prevalent because we publish out new JSPs (dynamic content) on a daily basis. While I understand this bug is designated closed I would like to know if it has been fixed in subsequent 4.x releases (cant find any evidence of this) and secondly if it is still an issue in 5.x (i.e. when it was eventually fixed). We can patch our cut of the Tomcat code with the fork() for Javac (which was introduced in 4.1.19) and by referencing the compiler instance in the JspCompilationContext class but this is non ideal and does not fix the core problem. We would like to move to a Tomcat version that fixes this issue while minimising the 'jump' in releases we must take to accomplish this. Guidance much appreciated. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
What's the next step now ? Next is to draft a resolution to supply to the board, making Tomcat a TLP. It's easiest to look over the approved minutes and look at similar resolutions and use them as a guide. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] PMC Chair
Hi, Next is to draft a resolution to supply to the board, making Tomcat a TLP. It's easiest to look over the approved minutes and look at similar resolutions and use them as a guide. Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav --- Draft TLP resolution --- X. Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX] be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Hi Mladen, for getting the Apache13 and Netscape connectors compiled I had to patch jk_connect.c: http://www.apache.org/~fuankg/mod_jk/jk_connect.c.diff if you have no better idea I would like to get that in... This is related to MetroWerks compiler treating warnings as errors, if I remember correctly? Why don't you use GCC? Yep. Because Metrowerks is still the 'official' NetWare compiler, and Apache is still built with it; also the build systems are currently only to support MW. In addition the gcc crosscompiler versions floating around have issues which prevent building with gcc. Novell has now internally modified gcc self, and ported their own linker to Linux; but they did not yet make this the official compiler, nor release the linker source. Also I would like to mention that I'm probably way more frustrated about those banana patches than you cause I reported that compiler bug directly to the Novell manager who was reponsible for Metrowerks connection years ago, I even wrote a sample to demonstrate the problem; and after that three more versions of the stupid compiler were released and they from Metrowerks werre not able to fix it greets, Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Günter Knauf wrote: Hi Mladen, Also I would like to mention that I'm probably way more frustrated about those banana patches than you cause I reported that compiler bug directly to the Novell manager who was reponsible for Metrowerks connection years ago, I even wrote a sample to demonstrate the problem; and after that three more versions of the stupid compiler were released and they from Metrowerks werre not able to fix it Do you have any proposal what should we do? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? Congratulations to Remy. Also thank you Yoav for moving the formalities along. Regards, -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Yoav Shapira wrote: Hi, Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX] I've always be amazed how anyone could come upwith such pompous prose ;) So to be added to the PMC list: Larry Isaacs (larryi) Jim Jagielski (jim) Ian Darwin (idarwin) Kurt Miller (truk) Glenn Nielsen (glenn) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Final Four weekend
Hi, I'll be gone this weekend to the lovely (I think/hope) city of St. Louis. I wanted to bring up three items before I have to leave for the airport: - Bugzilla 6582. It looks like a simple issue, the patch is there, and it's been around long enough that I'm tired of seeing that red line at the top of the Bugzilla report ;) Can someone with servletapi-5 please take care of it (or resolve/invalid/wontfix if that's the correct thing to do). ;) - TCKs for 5.5.9, just a reminder that it'd be great to have those run this weekend, so that we can have a stability vote early next week. - What's the status of the Servlet/JSP Specs? I see no new JSRs, but maybe maintenance releases are coming? It'd be nice to have an update from someone on the Expert Group as to what's going on. Have a good weekend everyone ;) Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] / mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml jndi-resources-howto.xml
yoavs 2005/04/01 05:52:10 Modified:webapps/docs changelog.xml jndi-resources-howto.xml Log: Bugzilla 34248. Revision ChangesPath 1.279 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.278 retrieving revision 1.279 diff -u -r1.278 -r1.279 --- changelog.xml 31 Mar 2005 10:31:54 - 1.278 +++ changelog.xml 1 Apr 2005 13:52:10 - 1.279 @@ -36,6 +36,9 @@ bug34237/bug: Added note and links to context and host configuration references in JNDI DataSources HowTo to aid the clueless. (yoavs) /update + update +bug34248/bug: Update JavaMail download instructions to include JAF. (yoavs) + /update /changelog /subsection 1.10 +5 -2 jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml Index: jndi-resources-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jndi-resources-howto.xml 30 Nov 2004 17:24:46 - 1.9 +++ jndi-resources-howto.xml 1 Apr 2005 13:52:10 - 1.10 @@ -387,10 +387,13 @@ h34. Install the JavaMail libraries/h3 pa href=http://java.sun.com/products/javamail/downloads/index.html; target=_blank -Download the JavaMail API/a./p +Download the JavaMail API/a. The JavaMail API requires the Java Activation +Framework (JAF) API as well. The Java Activation Framework can be downloaded +from a href=http://java.sun.com/products/javabeans/glasgow/jaf.html;Sun's site/a. +/p pThis download includes 2 vital libraries for the configuration; -activation.jar and mail.jar. Unpackage the JavaMail distribution and place +activation.jar and mail.jar. Unpackage both distributions and place them into $CATALINA_HOME/common/lib so that they are available to Tomcat during the initialization of the mail Session Resource. strongNote:/strong placing these jars in both common/lib and a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34248] - The directions for installing JavaMail are not accurate.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34248. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34248 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 15:52 --- Page updated and clarified. Thanks for pointing this out. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34250] - Commit changes button should have confirmation dialog
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34250. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34250 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 15:53 --- Changing to an enhancement request. It's one of those ever-continuing dialogs about how big and how red the destruction button should be ;) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Mladen Turk wrote: Günter Knauf wrote: Hi Mladen, Also I would like to mention that I'm probably way more frustrated about those banana patches than you cause I reported that compiler bug directly to the Novell manager who was reponsible for Metrowerks connection years ago, I even wrote a sample to demonstrate the problem; and after that three more versions of the stupid compiler were released and they from Metrowerks werre not able to fix it H Metrowerks used to be good back when I used it (early PowerPC Mac days). It was stricter than most compilers -- perhaps even causing some warnings to be errors. I understand how this can cause issues building open source software, but for my own development I always appreciated the compiler being stricter than others -- it made porting a lot easier. [I now use Java and am dismayed at what C compilers let you get away with.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. Congratulations to Remy. Also thank you Yoav for moving the formalities along. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Well the GCC 3.2 used on my Linux PPC reports also many warnings :-) Making all in common make[1]: Entering directory `/root/jakarta-tomcat-connectors-1.2.10-src/jk/native/common' /bin/sh /usr/share/apache2/build/libtool --silent --mode=compile gcc -I/usr/include/apache2-prefork -g -O2 -O2 -fsigned-char -fPIC -Wall -fno-strict-aliasing -D_LARGEFILE_SOURCE -g -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -DHAVE_APR -I/usr/include/apache2-prefork -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -I /usr/lib/jvm/java-1.4.2-ibm/include -I /usr/lib/jvm/java-1.4.2-ibm/include/ -c jk_ajp12_worker.c In file included from jk_uri_worker_map.h:35, from jk_service.h:34, from jk_ajp12_worker.h:27, from jk_ajp12_worker.c:25: jk_mt.h:81: warning: function declaration isn't a prototype In file included from jk_uri_worker_map.h:36, from jk_service.h:34, from jk_ajp12_worker.h:27, from jk_ajp12_worker.c:25: jk_shm.h:91: warning: function declaration isn't a prototype jk_shm.h:99: warning: function declaration isn't a prototype jk_shm.h:118: warning: function declaration isn't a prototype jk_shm.h:127: warning: function declaration isn't a prototype jk_shm.h:134: warning: function declaration isn't a prototype jk_shm.h:138: warning: function declaration isn't a prototype jk_shm.h:141: warning: function declaration isn't a prototype On Apr 1, 2005 4:06 PM, Jess Holle [EMAIL PROTECTED] wrote: Mladen Turk wrote: Günter Knauf wrote: Hi Mladen, Also I would like to mention that I'm probably way more frustrated about those banana patches than you cause I reported that compiler bug directly to the Novell manager who was reponsible for Metrowerks connection years ago, I even wrote a sample to demonstrate the problem; and after that three more versions of the stupid compiler were released and they from Metrowerks werre not able to fix it H Metrowerks used to be good back when I used it (early PowerPC Mac days). It was stricter than most compilers -- perhaps even causing some warnings to be errors. I understand how this can cause issues building open source software, but for my own development I always appreciated the compiler being stricter than others -- it made porting a lot easier. [I now use Java and am dismayed at what C compilers let you get away with.] -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Final Four weekend
Yoav Shapira wrote: Hi, I'll be gone this weekend to the lovely (I think/hope) city of St. Louis. I wanted to bring up three items before I have to leave for the airport: - Bugzilla 6582. It looks like a simple issue, the patch is there, and it's been around long enough that I'm tired of seeing that red line at the top of the Bugzilla report ;) Can someone with servletapi-5 please take care of it (or resolve/invalid/wontfix if that's the correct thing to do). ;) - TCKs for 5.5.9, just a reminder that it'd be great to have those run this weekend, so that we can have a stability vote early next week. - What's the status of the Servlet/JSP Specs? I see no new JSRs, but maybe maintenance releases are coming? It'd be nice to have an update from someone on the Expert Group as to what's going on. Jan said the new maintenance oriented JSR would start this summer for inclusion in J2EE 5.0 (they're not in a hurry eh ;) ). Have a good weekend everyone ;) Good WE too :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Query on Tomcat 4.1.31 , 4.1.29
Here is the link to 4.1.31 and its release notes http://archive.apache.org/dist/jakarta/tomcat-4/v4.1.31/ Thanks, Keith sun fire wrote: Hi, Where can I find the enhancements of Tomcat version 4.1.31 over 4.1.29 ? All releases available belong to the 5.x versions and 4.* versions don't seem to be available on the web site for me to see the change logs. Are there, Appreciate your help. Are some of the bug-fixes from 4.1.29 - 4.1.31 related to security issues ? Thanks , Sunil - Do you Yahoo!? Better first dates. More second dates. Yahoo! Personals - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34250] - Commit changes button should have confirmation dialog
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34250. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34250 --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 16:28 --- (In reply to comment #1) Changing to an enhancement request. It's one of those ever-continuing dialogs about how big and how red the destruction button should be ;) OK, fair enough ;o) But it's just a boring grey button at the moment with no warning at all... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
From: Remy Maucherat [EMAIL PROTECTED] Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. Okay, that makes sense. Thanks for the clarification. Congratulations to Remy. Also thank you Yoav for moving the formalities along. Rémy -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Remy Maucherat wrote: Henri Yandell wrote: 19 votes were recorded, and thus the proposed Tomcat PMC is: Keith Wannamaker (keith) Mark Thomas (markt) Larry Isaacs (larryi) Filip Hanik (fhanik) Tim Funk (funkman) Kin-man Chung (kinman) Henri Gomez (hgomez) Mladen Turk (mturk) Costin Manolache (costin) Jim Jagielski (jim) Bill Barker (billbarker) Ian Darwin (idarwin) Peter Rossbach (pero) Kurt Miller (truk) Glenn Nielsen (glenn) Jean-Frederic Clere (jfclere) Amy Roh (amyroh) Jeanfrancois Arcand (jfarcand) Remy Maucherat (remm) Yoav Shapira (yoavs) The result was: 13 - Remy 5 - Yoav 1 - Costin (that's funny, but I can count 20 people) It's a fraud! I demand a recount. sorry I couldn't help myself. ;-) Thanks a lot for taking care of this, which also was a great mechanism for determining who would be on the PMC (I don't see Jan Luehe there, though, so he would have to be added to the list). And thanks to the voters, of course ;) What's the next step now ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? Congratulations to Remy. Also thank you Yoav for moving the formalities along. Congratulation Remy ! I think a lot of people agree that anyone who is an active committer should be in the PMC ( that's what jakarta has been doing for a long time ). It's 'should' - not 'must' - that means you are not required to do this if you really don't want to. I think Remy has already sent additional lists of people who are active but have not voted. I assume those who really don't want will have to send email to Remy to be taken out of the list before it goes to the board. Regarding 'emeritus status' - I think usually people who have not participated in the last 6 months ( or 1 year ) can be moved to 'emeritus' - unless they ask to remain in the list of active committers. ( for example because they plan to return to active soon, etc :-). We could send a mail to everyone in the avail list, and if we don't get an answer or we get an 'I don't care' - we should do the switch. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Costin Manolache wrote: Kurt Miller wrote: Congratulation Remy ! I think a lot of people agree that anyone who is an active committer should be in the PMC ( that's what jakarta has been doing for a long time ). It's 'should' - not 'must' - that means you are not required to do this if you really don't want to. Right, obviously, anyone can refuse to be on a PMC, which most of the time does not deal with actual development issues. I think Remy has already sent additional lists of people who are active but have not voted. I assume those who really don't want will have to send email to Remy to be taken out of the list before it goes to the board. Yes. Regarding 'emeritus status' - I think usually people who have not participated in the last 6 months ( or 1 year ) can be moved to 'emeritus' - unless they ask to remain in the list of active committers. ( for example because they plan to return to active soon, etc :-). We could send a mail to everyone in the avail list, and if we don't get an answer or we get an 'I don't care' - we should do the switch. Doesn't seem like a bad idea ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Remy Maucherat wrote: Kurt Miller wrote: From: Yoav Shapira [EMAIL PROTECTED] Below is the draft resolution we agreed on previously, so it should be pretty close. We need to make sure the PMC names are correct and complete. Congrats to Remy and thanks everyone for voting, and of course thanks Henri ;) Yoav While my low level of involvement probably doesn't merit being in the PMC, I'm concerned that only those names that appear in the PMC list will retain active committer status. I'm sure there are other committers who fall into my category. Will the 50+ committers who are not on the PMC be move to emeritus status? If not how will that be decided? The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. +1 To get things started, since I'm probably close to the 6 month inactivity limit ( in either direction :), I would like to ask to stay in the active list :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] JK 1.2.10 Released
Hi, Also I would like to mention that I'm probably way more frustrated about those banana patches than you cause I reported that compiler bug directly to the Novell manager who was reponsible for Metrowerks connection years ago, I even wrote a sample to demonstrate the problem; and after that three more versions of the stupid compiler were released and they from Metrowerks werre not able to fix it Do you have any proposal what should we do? there's no other way than what I did: define own types and cast. Here's the whole problem: - from clib sys/socket.h which is used with Apache 1.3: int setsockopt( SKT s, int level, int name, char *val, int len ); - from libc sys/socket.h which is used with Apache 2.x: int setsockopt(int s, int level, int optname, const void * optval, size_t optlen); and there's really _no_ compiler switch to tell CodeWarrior to treat 'const char*' - 'char*' differences as warnings than as errors. But I think on the other side the Metrowerks CodeWarrior is not the only compiler which behaves abnormal, and that's one of the reasons why Apache2 uses own types whenever it makes sense; Apache 1.3 did not so much, and therefore you see it building with a couple of warnings on many platforms - and even with gcc you see them if developers would use -Wall greetz, Guen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
Costin Manolache wrote: Remy Maucherat wrote: The official ASF policy calls for a 6 month inactivity. No Tomcat committer has ever been removed in 5+ years. It seems reasonable to me that if they don't at least ask for it that they would now be removed. +1 To get things started, since I'm probably close to the 6 month inactivity limit ( in either direction :), I would like to ask to stay in the active list :-) I think those people at least deserve direct question, something like: Hay man, do you have time and will to continue with the Tomcat or not? Also, I would suggest that the first filter is subscription to tomcat developers list. I mean what is the purpose of being tomcat committer if not being subscribed to the list? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] PMC Chair
I've always be amazed how anyone could come upwith such pompous prose ;) Thank goodness for copy paste! Congrats to Remm to all who participated. I'll be glad to see Tomcat become a top level project (it struck me as ironic that Ant made this move before Tomcat, when Ant originated as the TC build tool). Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Indirect jsp:include does not seem to work
Hello all, I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. I looked in the code. ApplicationDispatcher correctly identifies the first request to strutsAction.do as Path Based Include. But when struts action forwards to detail jsp, ApplicationDispatcher identifies it as Path Based Forward. doForward() is called instead of doInclude(), and ApplicationDispatcher flushes and closes the response writer. Thus, Jasper cannot write the rest of master page content to writer, and throws org.apache.jasper.JasperException: Stream closed. Without thinking much, I commented out writer flushing in ApplicationDispatcher.doForward(). It seems to work on Tomcat 4.1.31, but failed on Tomcat 5.0. Anyway, I am not sure that I did a right thing and that all buffers are properly being closed now. Would be great if Tomcat devs look into it. Btw, Jetty does not work as I want, too. BUT: I tried to create a proxy JSP page, which is included in main JSP page. This proxy page includes strutsAction.do, which forwards to real JSP page that I want to include (whew!) Jetty works perfectly fine with this proxy JSP page! Also, Resin works fine both with direct including of struts action from main page, and with proxy JSP page. So, I believe that this is a Tomcat bug. Thanks, Michael Jouravlev. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34268] New: - DefaultContext is not loading a Resource for all contexts.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34268. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34268 Summary: DefaultContext is not loading a Resource for all contexts. Product: Tomcat 5 Version: 5.5.7 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] As of right now to set up a JNDI Resource in Tomcat you can no longer set it in the DefaultContext, you have to set the Resource in each individual contexts. If it is set in the DefaultContext the app will not be able to find it. The documentation also does not reflect this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=15845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=15845 --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 20:09 --- Looks like it was fixed in 4.1.20 but I would urge you to update to 4.1.31 if at all possible. The regression testing will take the same time and there is a significant number of fixes between 4.1.20 and 4.1.31 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not work
I found bug #21440 in ASF bug database which looks awful like the one I have. It was entered in July, 2003 and is still not resolved. Tomcat devs considered against attempting to fix this bug (if confirmed it is actually one) in 4.1.x. and that its severity 'minor', since this is a corner case that should not occur often. I am sorry, this is not the corner case. I need this functionality. And considering that my hosting provider uses Tomcat 4.x, I might be able to persuade him to use a patch, if it were available. My provider does not have intentions to switch to Tomcat 5 now (which has this bug too, by the way). Resin works, and Jetty works with a proxy JSP page. So, for development I can use other servlet containers, but I need Tomcat to be patched for production, including 4.x (at least 4.1.x). I tested my app on 4.0.6, 4.1.31 and 5.0.28, it did not work. Thank you, Michael. I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. [skipped] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34260] - Bring up a dead node, the node will not get session data update from others.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34260. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34260 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 20:37 --- I checked throughly today, and find out the problem to be one of our computer in intranet has a tomcat instance and sending out wrong information tcp listen address 127.0.0.1:4002. I changed the multicast port, and it is fine. This is not a bug. sorry for the confusion. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21440] - jsp:include whose target performs a 'forward' does not behave as expected
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=21440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21440 --- Additional Comments From [EMAIL PROTECTED] 2005-04-01 20:39 --- (In reply to comment #2) Agree this is severity 'minor', since this is a corner case that should not occur often. ... I think I am against attempting to fix this bug (if confirmed it is actually one) in 4.1.x. This bug does not seem to be fixed yet. This functionality is needed, it is not a corner case. Tomcat 5.0.28 seem to have this bug too. Please, fix it, including Tomcat 4.1.x too. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
You cannot perform a forward inside an include. [Just like you can't set any headers, including cookies, in an include or a host of other things while in an include.] -Tim Michael J. wrote: Hello all, I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. I looked in the code. ApplicationDispatcher correctly identifies the first request to strutsAction.do as Path Based Include. But when struts action forwards to detail jsp, ApplicationDispatcher identifies it as Path Based Forward. doForward() is called instead of doInclude(), and ApplicationDispatcher flushes and closes the response writer. Thus, Jasper cannot write the rest of master page content to writer, and throws org.apache.jasper.JasperException: Stream closed. Without thinking much, I commented out writer flushing in ApplicationDispatcher.doForward(). It seems to work on Tomcat 4.1.31, but failed on Tomcat 5.0. Anyway, I am not sure that I did a right thing and that all buffers are properly being closed now. Would be great if Tomcat devs look into it. Btw, Jetty does not work as I want, too. BUT: I tried to create a proxy JSP page, which is included in main JSP page. This proxy page includes strutsAction.do, which forwards to real JSP page that I want to include (whew!) Jetty works perfectly fine with this proxy JSP page! Also, Resin works fine both with direct including of struts action from main page, and with proxy JSP page. So, I believe that this is a Tomcat bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
Here is what I found at: http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html#8828 The jsp:include element allows you to include either a static or dynamic resource in a JSP page. The results of including static and dynamic resources are quite different. If the resource is static, its content is included in the calling JSP page. If the resource is dynamic, it acts on a request and sends back a result that is included in the JSP page. When the include action is finished, the JSP container continues processing the remainder of the JSP page. So, what I am doing is perfectly legitimate. I include a dynamic resource (spec does not clarify the type of resource or its nesting level). It should return result, to be included in the main page. And JSP container continues processing the remainder of the JSP page, which Tomcat does not do. It is a bug. Resin works exactly as I expect, and Jetty works too with a proxy JSP page. I have not tried other servers yet. Thank you, Michael. On Apr 1, 2005 10:39 AM, Tim Funk [EMAIL PROTECTED] wrote: You cannot perform a forward inside an include. [Just like you can't set any headers, including cookies, in an include or a host of other things while in an include.] -Tim Michael J. wrote: Hello all, I have master jsp page, and I try to jsp:include page=/strutsAction.do, which forwards to detail jsp page, but this does not work. On Tomcat 4.x and 5.x the detail page content is included, but further content from the master page is stripped out. According to jsp specs, if I include a resource with jsp:include, its content should be included in the page. Afaik the spec does not specify nesting level. I looked in the code. ApplicationDispatcher correctly identifies the first request to strutsAction.do as Path Based Include. But when struts action forwards to detail jsp, ApplicationDispatcher identifies it as Path Based Forward. doForward() is called instead of doInclude(), and ApplicationDispatcher flushes and closes the response writer. Thus, Jasper cannot write the rest of master page content to writer, and throws org.apache.jasper.JasperException: Stream closed. Without thinking much, I commented out writer flushing in ApplicationDispatcher.doForward(). It seems to work on Tomcat 4.1.31, but failed on Tomcat 5.0. Anyway, I am not sure that I did a right thing and that all buffers are properly being closed now. Would be great if Tomcat devs look into it. Btw, Jetty does not work as I want, too. BUT: I tried to create a proxy JSP page, which is included in main JSP page. This proxy page includes strutsAction.do, which forwards to real JSP page that I want to include (whew!) Jetty works perfectly fine with this proxy JSP page! Also, Resin works fine both with direct including of struts action from main page, and with proxy JSP page. So, I believe that this is a Tomcat bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Request.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 01, 2005 3:36 AM Subject: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Request.java remm2005/04/01 03:36:52 Modified:catalina/src/share/org/apache/catalina/realm GenericPrincipal.java JAASRealm.java catalina/src/share/org/apache/catalina/connector Request.java Log: - Commit my proposed changes to GenericPrincipal, and use it to remove the role map in the JAAS realm. - Let me know if I did it wrong ;) Cluster has code to serialize GP that will need to be updated (but I don't see a good way myself off the top of my head :(). But with this, at least Cluster+JAAS is less broken than it was before. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
Michael J. wrote: Here is what I found at: http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html#8828 [snip] So, what I am doing is perfectly legitimate... A syntax reference is not the same as a specification. Specifications are (supposedly) more rigorous and more precise in their specification of required behaviour. Tomcat is the reference implementation for the Servlet and JSP specifications. It might be helpful if everybody who is interested in this discussion could please read JSP4.5 (section 4.5 of the JSP spec, version 1.2, since you are talking about Tomcat 4). See also SRV.8, that is, section 8 of the Servlet spec (Version 2.3, for Tomcat 4), which defines how the underlying include and forward mechanisms work; pay particular attention to sections 8.3 and 8.4 (compare the first lines of each of those sections). Resin works exactly as I expect, and Jetty works too with a proxy JSP page. I have not tried other servers yet. I have experienced this error too, and I wish Tomcat worked that way, but I haven't yet found anything in the Specifications that would allow me to change how it works :-) As implied by the spec, there may be different results depending on the sizes of buffers used by the implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Documentation Error
The documentation at http://www.uportal.org/administrators/building.html does not mention the server.home property... Before deploying uPortal you may need to modify the build.properties. Edit the file and find the deploy.home property. ...should read... Before deploying uPortal you may need to modify the build.properties. Edit the file and find the server.home and deploy.home properties. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
A syntax reference is not the same as a specification. Specifications are (supposedly) more rigorous and more precise in their specification of required behaviour. Tomcat is the reference implementation for the Servlet and JSP specifications. It might be helpful if everybody who is interested in this discussion could please read [spec list skipped] I will read the specs, but I am having a deja vu: California Driver's Handbook is for drivers, who don't know how to drive anyway. It is just a funny comics pamphlet. California Vehicle Code is a real thing for cops, and contains all the proper rules. spec-quote version=2.4 section=8.4 Before the forward method of the RequestDispatcher interface returns, the response content must be sent and committed, and closed by the servlet container. /spec-quote Frankly speaking, as a user I don't care about dispatchers, responses and containers. I just want to include a _resource_, which is allowed according to Sun's quick reference card for JSP 1.2. Ok, Sun apparently is screwed up, mixing the requirements, but it should not be my problem, because its syntax reference card works for me :) I want my problem to be solved. And this works in other containers. I understand that Tomcat has to go by the real spec, not by the comics book. Then, in this case spec should be updated. This functionality is important to me. And currently I cannot implement it on Tomcat without a... er... patch, which I did myself and which can break something else. So I would prefer a real fix from Tomcat pros. The language for the 2.3 spec is similar. Bottom line: Resin is wrong ;-). Wrong or not, it works great for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation Error
Durfee, Bernard wrote: The documentation at http://www.uportal.org/administrators/building.html does not mention the server.home property... Wrong list. This is the list for problems with Tomcat. We have nothing to do with uportal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indirect jsp:include does not seem to work
Now I understand: you want real life to work like the comic book! :-) :-) (Don't take that personally, it's April 1 today after all). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Request.java
Bill Barker wrote: remm2005/04/01 03:36:52 Modified:catalina/src/share/org/apache/catalina/realm GenericPrincipal.java JAASRealm.java catalina/src/share/org/apache/catalina/connector Request.java Log: - Commit my proposed changes to GenericPrincipal, and use it to remove the role map in the JAAS realm. - Let me know if I did it wrong ;) Cluster has code to serialize GP that will need to be updated (but I don't see a good way myself off the top of my head :(). But with this, at least Cluster+JAAS is less broken than it was before. I didn't think about that kind of issues at all. It's one of the reasons I didn't do it before 5.5.9 ;) Maybe it would be good to standardize on JAAS + JAAC for the next big release. When serializing the session, the principal is marked as transient. I don't know much besides that. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
luehe 2005/04/01 13:18:28
Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Do not add context path to login and error pages, since we are
comparing them against request.getRequestPathMB().toString(),
which does not include context path.
hasResourcePermission() used to compare login and error pages against
request.getDecodedRequestURI(), which does include context path, but
this was changed in rev 1.49 to compare them against
request.getRequestPathMB().toString(), to be consistent with
findSecurityConstraints().
Revision ChangesPath
1.51 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
Index: RealmBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- RealmBase.java25 Mar 2005 08:29:34 - 1.50
+++ RealmBase.java1 Apr 2005 21:18:28 - 1.51
@@ -703,13 +703,13 @@
if ((config != null)
(Constants.FORM_METHOD.equals(config.getAuthMethod( {
String requestURI = request.getRequestPathMB().toString();
-String loginPage = context.getPath() + config.getLoginPage();
+String loginPage = config.getLoginPage();
if (loginPage.equals(requestURI)) {
if (log.isDebugEnabled())
log.debug( Allow access to login page + loginPage);
return (true);
}
-String errorPage = context.getPath() + config.getErrorPage();
+String errorPage = config.getErrorPage();
if (errorPage.equals(requestURI)) {
if (log.isDebugEnabled())
log.debug( Allow access to error page + errorPage);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34272] New: - Patch to externalize the JspServlet Options implementation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34272. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34272 Summary: Patch to externalize the JspServlet Options implementation Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Options like the tld cache cannot be set via external configuration. The attached patch allows the org.apache.jasper.Options implementation used by the JspServlet to be set via an engineOptionsClass parameter: servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class ... init-param param-nameengineOptionsClass/param-name param-valueorg.jboss.web.tomcat.tc5.jasper.JspServletOptions/param-value /init-param load-on-startup3/load-on-startup /servlet -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34272] - Patch to externalize the JspServlet Options implementation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34272. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34272 --- Additional Comments From [EMAIL PROTECTED] 2005-04-02 08:25 --- Created an attachment (id=14608) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14608action=view) Patch for engineOptionsClass option patch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
