DO NOT REPLY [Bug 14281] - AccessLogValve doesn't export BytesSent info from servlets...
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=14281. 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=14281 AccessLogValve doesn't export BytesSent info from servlets... [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 08:00 --- If the servlet doesn't set the content-length, then the number of bytes sent can't be logged (it is not known). -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardWrapper.java
[EMAIL PROTECTED] wrote: costin 2002/11/05 13:35:00 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java Log: Use commons-logging. Add a short message for servlets that take a long time to load ( right now it's 200 ms - we can increase it, but no need to make it configurable, it's mostly do debug perf. ). I used idea to edit the file - and it removed unused imports and forced me to fix some name mismatches... Probably should go back to emacs... Especially since it converted the imports to * imports (evil, evil). Please stop using it or disable the feature (and can you revert the changes on the imports ?). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14257] - jsp will execute 2 times
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=14257. 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=14257 jsp will execute 2 times [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 08:19 --- I don't know. I wouldn't have believed it without the test case. In any case, it looks like a client side thing to me; I don't see anything Tomcat could do to prevent this. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: costin 2002/11/05 13:35:00 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java Log: Use commons-logging. Add a short message for servlets that take a long time to load ( right now it's 200 ms - we can increase it, but no need to make it configurable, it's mostly do debug perf. ). I used idea to edit the file - and it removed unused imports and forced me to fix some name mismatches... Probably should go back to emacs... Especially since it converted the imports to * imports (evil, evil). Please stop using it or disable the feature (and can you revert the changes on the imports ?). I can revert the change - I just had it on my computer for a long while, it's really not that important. I would like to slowly move all the logging to c-l, but there is no urgency. Regarding Idea - it warned me that about 10 imports were not beeing used - and I let it 'fix' it. It seems it uses * if more than 5 files in the same package are used. Overall I'm really impressed with idea - I don't think I'll be able to return to emacs. The code completion and runtime correction is great, and the speed is decent. And with few fixes I was able to even run tomcat inside and debug it... I still have 20 more days to evaluate it, but so far it seems its worth the money. I'll just try once more with netbeans and eclipse. BTW - what's evil in import * ? I never understood. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14289] - Character Encodings Suggestion
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=14289. 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=14289 Character Encodings Suggestion --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 08:41 --- This would violate the Servlet/JSP spec (which requires iso-latin-1 unless otherwise specified). But, since it is an enhancement, I won't do the knee- jerk WONTFIX on it. It would be a totally Tomcat-specific and totally non- portable feature however. As an alternative, it seems to me that this should be easy enough to do in a Filter. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 12:13 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java [EMAIL PROTECTED] wrote: costin 2002/11/05 13:35:00 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java Log: Use commons-logging. Add a short message for servlets that take a long time to load ( right now it's 200 ms - we can increase it, but no need to make it configurable, it's mostly do debug perf. ). I used idea to edit the file - and it removed unused imports and forced me to fix some name mismatches... Probably should go back to emacs... Especially since it converted the imports to * imports (evil, evil). Please stop using it or disable the feature (and can you revert the changes on the imports ?). +1 Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14281] - AccessLogValve doesn't export BytesSent info from servlets...
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=14281. 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=14281 AccessLogValve doesn't export BytesSent info from servlets... [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 08:44 --- But this worked ok before 4.1.x. I just upgrade my apps from 4.0.6 to 4.1.12. Is correct to set the content-length mandatory to make the AccessValve knows BytesSent? I think it doesn't have much sense. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
Costin Manolache wrote: I'm getting closer - Remy or Kin-Man, I need your help. As I expected, the flush() was hiding some other behaviors. Right now I'm looking at ApplicationDispatcher.doForward(). What happens is: - error happens - we forward to the error page - error page executes, put the data in the out buffer - BEFORE: the out buffer was commited - now we just return from servlet to doForward() - The commiting and closing response reached ( line 471 ) What happens here is response is a ResponseFacade, and finish is called. But the real flushing and closing doesn't actually happens. I changed the code to first flush/close, the call finish - and it now seems to work fine. But I'm not sure what else may be affected by this - or if it's safe to make the change ( well, for 5.0 it may be, but what about 4.1 ? ) In any case, I expect this to have caused some weird behavior for normal forward - since forward doesn't seem to really flush/close as it was supposed to do ( unless response is not facade - does this case ever happen ? ). A bit strange no other test detected that, normal servlets don't have flush/close that the jsp page had. No, that wouldn't work. forward does a fake flush/close, because some further error page processing may occur (based on the status code, for example). I think we'll have to do the commit in the JSP error page itself (and call close right away in the case, rather than flush). I hope it's doable. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader LocaStrings_fr.properties
hgomez 2002/11/06 01:21:19
Added: catalina/src/share/org/apache/catalina/session
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/authenticator
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/connector/http10
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/cluster
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/startup
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/connector/http
LocalString_fr.properties
catalina/src/share/org/apache/catalina/realm
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/loader
LocaStrings_fr.properties
Log:
Add french translations
Revision ChangesPath
1.1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings_fr.properties
Index: LocalStrings_fr.properties
===
applicationSession.session.ise=état de session invalide
applicationSession.value.iae=valeur nulle
fileStore.alreadyStarted=Le File Store a déjà été démarré
fileStore.notStarted=Le File Store n''a pas encore été démarré
fileStore.saving=Sauvegarde de la Session {0} vers le fichier {1}
fileStore.loading=Chargement de la Session {0} depuis le fichier {1}
fileStore.removing=Retrait de la Session {0} du fichier {1}
JDBCStore.alreadyStarted=Le JDBC Store a déjà été démarré
JDBCStore.notStarted=Le JDBC Store n''a pas encore été démarré
JDBCStore.saving=Sauvegarde de la Session {0} vers la base de données {1}
JDBCStore.loading=Chargement de la Session {0} depuis la base de données {1}
JDBCStore.removing=Retrait de la Session {0} de la base de données {1}
JDBCStore.SQLException=Erreur SQL {0}
JDBCStore.checkConnectionDBClosed=La connexion à la base de données est nulle ou a
été trouvé fermé. Tentative de réouverture.
JDBCStore.checkConnectionDBReOpenFail=La tentative de réouverture re-open de la base
de données a échoué. La base de données est peut être arrétée.
JDBCStore.checkConnectionSQLException=Une exception SQL s''est produite {0}
JDBCStore.checkConnectionClassNotFoundException=La classe du driver JDBC n''a pas
été trouvée {0}
managerBase.complete=L''alimentation du générateur de nombre aléatoire est terminé
managerBase.getting=Prise du composant d''algorithme empreinte de message (message
digest) pour l''algorithme {0}
managerBase.gotten=Prise du composant d''algorithme empreinte de message (message
digest) terminée
managerBase.random=Exception durant l''initialisation de la classe du générateur de
nombre aléatoire {0}
managerBase.seeding=Alimentation de la classe du générateur de nombre aléatoire {0}
serverSession.value.iae=valeur nulle
standardManager.alreadyStarted=Le Manager a été démarré
standardManager.createSession.ise=createSession: Trop de sessions actives
standardManager.expireException=processsExpire: Exception lors de l''expiration
de la session
standardManager.loading=Chargement des sessions qui ont persistés depuis {0}
standardManager.loading.cnfe=ClassNotFoundException lors du chargement de sessions
persistantes: {0}
standardManager.loading.ioe=IOException lors du chargement des sessions
persistantes: {0}
standardManager.notStarted=Le Manager n''a pas encore été démarré
standardManager.sessionTimeout=Réglage du délai d''inactivité (timeout) de session
invalide {0}
standardManager.unloading=Sauvegarde des sessions ayant persistées vers {0}
standardManager.unloading.ioe=IOException lors de la sauvegarde de sessions
persistantes: {0}
standardManager.managerLoad=Exception au chargement des sessions depuis le stockage
persistant (persistent storage)
standardManager.managerUnload=Exception au déchargement des sessions vers le
stockage persistant (persistent storage)
standardSession.attributeEvent=L''écouteur d''évènement Attribut de Session
(attribute event listener) a généré une exception
standardSession.invalidate.ise=invalidate: Session déjà invalidée
standardSession.isNew.ise=isNew: Session déjà invalidée
standardSession.getAttribute.ise=getAttribute: Session déjà invalidée
standardSession.getAttributeNames.ise=getAttributeNames: Session déjà invalidée
standardSession.getCreationTime.ise=getCreationTime: Session déjà invalidée
standardSession.getMaxInactiveInterval.ise=getMaxInactiveInterval: Session déjà
invalidée
standardSession.getValueNames.ise=getAttributeNames: Session déjà invalidée
standardSession.notSerializable=Impossible de sérialiser l''attribut de session {0}
pour la session {1}
standardSession.removeAttribute.ise=removeAttribute: Session déjà invalidée
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup LocalStrings_fr.properties
hgomez 2002/11/06 01:23:37
Added: catalina/src/share/org/apache/catalina/session
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/core
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/cluster
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/authenticator
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/security
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/realm
LocalStrings_fr.properties
catalina/src/share/org/apache/catalina/loader
LocaStrings_fr.properties
catalina/src/share/org/apache/catalina/startup
LocalStrings_fr.properties
Log:
Add french translations
Revision ChangesPath
1.1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/LocalStrings_fr.properties
Index: LocalStrings_fr.properties
===
applicationSession.session.ise=état de session invalide
applicationSession.value.iae=valeur nulle
fileStore.alreadyStarted=Le File Store a déjà été démarré
fileStore.notStarted=Le File Store n''a pas encore été démarré
fileStore.saving=Sauvegarde de la Session {0} vers le fichier {1}
fileStore.loading=Chargement de la Session {0} depuis le fichier {1}
fileStore.removing=Retrait de la Session {0} du fichier {1}
JDBCStore.alreadyStarted=Le JDBC Store a déjà été démarré
JDBCStore.notStarted=Le JDBC Store n''a pas encore été démarré
JDBCStore.saving=Sauvegarde de la Session {0} vers la base de données {1}
JDBCStore.loading=Chargement de la Session {0} depuis la base de données {1}
JDBCStore.removing=Retrait de la Session {0} de la base de données {1}
JDBCStore.SQLException=Erreur SQL {0}
JDBCStore.checkConnectionDBClosed=La connexion à la base de données est nulle ou a
été trouvé fermé. Tentative de réouverture.
JDBCStore.checkConnectionDBReOpenFail=La tentative de réouverture re-open de la base
de données a échoué. La base de données est peut être arrétée.
JDBCStore.checkConnectionSQLException=Une exception SQL s''est produite {0}
JDBCStore.checkConnectionClassNotFoundException=La classe du driver JDBC n''a pas
été trouvée {0}
managerBase.complete=L''alimentation du générateur de nombre aléatoire est terminé
managerBase.getting=Prise du composant d''algorithme empreinte de message (message
digest) pour l''algorithme {0}
managerBase.gotten=Prise du composant d''algorithme empreinte de message (message
digest) terminée
managerBase.random=Exception durant l''initialisation de la classe du générateur de
nombre aléatoire {0}
managerBase.seeding=Alimentation de la classe du générateur de nombre aléatoire {0}
serverSession.value.iae=valeur nulle
standardManager.alreadyStarted=Le Manager a été démarré
standardManager.createSession.ise=createSession: Trop de sessions actives
standardManager.expireException=processsExpire: Exception lors de l''expiration
de la session
standardManager.loading=Chargement des sessions qui ont persistés depuis {0}
standardManager.loading.cnfe=ClassNotFoundException lors du chargement de sessions
persistantes: {0}
standardManager.loading.ioe=IOException lors du chargement des sessions
persistantes: {0}
standardManager.notStarted=Le Manager n''a pas encore été démarré
standardManager.sessionTimeout=Réglage du délai d''inactivité (timeout) de session
invalide {0}
standardManager.unloading=Sauvegarde des sessions ayant persistées vers {0}
standardManager.unloading.ioe=IOException lors de la sauvegarde de sessions
persistantes: {0}
standardManager.managerLoad=Exception au chargement des sessions depuis le stockage
persistant (persistent storage)
standardManager.managerUnload=Exception au déchargement des sessions vers le
stockage persistant (persistent storage)
standardSession.attributeEvent=L''écouteur d''évènement Attribut de Session
(attribute event listener) a généré une exception
standardSession.invalidate.ise=invalidate: Session déjà invalidée
standardSession.isNew.ise=isNew: Session déjà invalidée
standardSession.getAttribute.ise=getAttribute: Session déjà invalidée
standardSession.getAttributeNames.ise=getAttributeNames: Session déjà invalidée
standardSession.getCreationTime.ise=getCreationTime: Session déjà invalidée
standardSession.getMaxInactiveInterval.ise=getMaxInactiveInterval: Session déjà
invalidée
standardSession.getValueNames.ise=getAttributeNames: Session déjà invalidée
standardSession.notSerializable=Impossible de sérialiser l''attribut de session {0}
pour la session {1}
standardSession.removeAttribute.ise=removeAttribute: Session déjà invalidée
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteOutputStream.java CoyoteResponse.java OutputBuffer.java
remm2002/11/06 01:26:42
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteOutputStream.java CoyoteResponse.java
OutputBuffer.java
Log:
- Port patch.
- Finish the response when close is called on the stream or writer.
- This is slightly experimental, and could cause problems. Please test.
Revision ChangesPath
1.2 +2 -6
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteOutputStream.java
Index: CoyoteOutputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteOutputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteOutputStream.java 7 Mar 2002 04:27:23 - 1.1
+++ CoyoteOutputStream.java 6 Nov 2002 09:26:42 - 1.2
-116,17 +116,13
*/
public void flush()
throws IOException {
-if (ob.flushCharsNeeded())
-ob.flushChars();
-ob.flushBytes();
+ob.flush();
}
public void close()
throws IOException {
-if (ob.flushCharsNeeded())
-ob.flushChars();
-ob.flushBytes();
+ob.close();
}
1.28 +4 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
Index: CoyoteResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- CoyoteResponse.java 4 Oct 2002 07:03:08 - 1.27
+++ CoyoteResponse.java 6 Nov 2002 09:26:42 - 1.28
-501,7 +501,6
} catch(Throwable t) {
t.printStackTrace();
}
-coyoteResponse.finish();
}
1.8 +4 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- OutputBuffer.java 12 Mar 2002 03:48:58 - 1.7
+++ OutputBuffer.java 6 Nov 2002 09:26:42 - 1.8
-301,6 +301,8
public void close()
throws IOException {
+if (closed)
+return;
if (suspended)
return;
-320,6 +322,8
flush();
closed = true;
+
+coyoteResponse.finish();
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Overwhelmed docs
I'll add an 'impatient page' in jk docs with strict minimum, will need help for IIS/NES. I think the same should be done for jk2. Pier Fumagalli wrote: Forwarding... Pier Lambert, Stephen : CO IR [EMAIL PROTECTED] wrote: Is there any way the web site could be updated to include an install guide similar to the format John Turner has created? Perhaps, you could pass on this request! Do you take a look at site documentation ? for jk http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/doc/ the same included in TC 4.1.12 doc at : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html Also Redhat RPM are allready available : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/rpms/ Thanks to study docs and prebuilt rpms ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
symlinks in test build 4.1.14 not working
Hi, I was testing the 4.1.14 build in the hope it will fix the follow symlinks outside the basedir problem we have. With a normal config I can not browse the directory structure or access files. With the added Resources tag and allowLinking attribute I can browse the directories but not retrieve any files. Below is the relevant extract of the config I'm useing as gleaned by searching the list: Context path= docBase=ROOT debug=0 privileged=false reloadable=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=prnj_log. suffix=.txt timestamp=true/ Resources className=org.apache.naming.resources.FileDirContext allowLinking=true docBase= / /Context -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14059] - HTTP Response does not respond correctly to flush()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059 HTTP Response does not respond correctly to flush() [EMAIL PROTECTED] changed: What|Removed |Added Summary|HTP Response does not |HTTP Response does not |respond correctly to flush()|respond correctly to flush() --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 09:33 --- The bug report was very inaccurate. Try not to use the JDK HTTP client if you want to use advanced functionality. I've added a patch to finish the response when the stream or writer is closed, and this will be included in Tomcat 4.1.15 unless testing reveals it causes problems. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: symlinks in test build 4.1.14 not working
M wrote: Hi, I was testing the 4.1.14 build in the hope it will fix the follow symlinks outside the basedir problem we have. With a normal config I can not browse the directory structure or access files. With the added Resources tag and allowLinking attribute I can browse the directories but not retrieve any files. I doubt the case sensitivity check (needed for Windows and OS X, so always enabled by default now) is compatible with symlinking. Try disabling it to see if it helps (caseSensitive=false). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources FileDirContext.java
remm2002/11/06 01:57:18
Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java
Log:
- Don't do the case sensitivity check if allow linking is used (this is a Unix
specific
option).
Revision ChangesPath
1.15 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/FileDirContext.java
Index: FileDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- FileDirContext.java 18 Sep 2002 13:54:33 - 1.14
+++ FileDirContext.java 6 Nov 2002 09:57:17 - 1.15
-895,7 +895,7
}
// Case sensitivity check
-if (caseSensitive) {
+if (!allowLinking caseSensitive) {
String fileAbsPath = file.getAbsolutePath();
if (fileAbsPath.endsWith(.))
fileAbsPath = fileAbsPath + /;
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: symlinks in test build 4.1.14 not working
Remy Maucherat wrote: M wrote: Hi, I was testing the 4.1.14 build in the hope it will fix the follow symlinks outside the basedir problem we have. With a normal config I can not browse the directory structure or access files. With the added Resources tag and allowLinking attribute I can browse the directories but not retrieve any files. I doubt the case sensitivity check (needed for Windows and OS X, so always enabled by default now) is compatible with symlinking. Try disabling it to see if it helps (caseSensitive=false). Spot on. That fixes it, many thanks. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources FileDirContext.java
remm2002/11/06 02:00:05
Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java
Log:
- Port all changes.
Revision ChangesPath
1.2 +31 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/FileDirContext.java
Index: FileDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- FileDirContext.java 18 Jul 2002 16:47:33 - 1.1
+++ FileDirContext.java 6 Nov 2002 10:00:05 - 1.2
-154,6 +154,12
protected boolean caseSensitive = true;
+/**
+ * Allow linking.
+ */
+protected boolean allowLinking = false;
+
+
// - Properties
-208,6 +214,22
}
+/**
+ * Set allow linking.
+ */
+public void setAllowLinking(boolean allowLinking) {
+this.allowLinking = allowLinking;
+}
+
+
+/**
+ * Is linking allowed.
+ */
+public boolean getAllowLinking() {
+return allowLinking;
+}
+
+
// - Public Methods
-217,6 +239,7
public void release() {
caseSensitive = true;
+allowLinking = false;
absoluteBase = null;
base = null;
super.release();
-866,12 +889,13
if (canPath == null)
return null;
-if (!canPath.startsWith(absoluteBase)) {
+// Check to see if going outside of the web application root
+if ((!allowLinking) (!canPath.startsWith(absoluteBase))) {
return null;
}
-// Windows only check
-if ((caseSensitive) (File.separatorChar == '\\')) {
+// Case sensitivity check
+if (!allowLinking caseSensitive) {
String fileAbsPath = file.getAbsolutePath();
if (fileAbsPath.endsWith(.))
fileAbsPath = fileAbsPath + /;
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14292] New: - Status message not included in HTTP response
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=14292. 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=14292 Status message not included in HTTP response Summary: Status message not included in HTTP response Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JkCoyote does not write a status message after the status code in the HTTP response header. This causes problems with some proxies, e.g., domains hosted by Strato which are forwarded through Strato's proxies. There are actually 2 bugs which cause the problem: 1. JkCoyoteHandler.java always appends an empty status message instead of the real one to the generated message. Here is my fix (relative to the current CVS repository): --- JkCoyoteHandler.java2002-11-06 10:51:19.0 +0100 +++ JkCoyoteHandler.java_new2002-11-06 10:08:56.0 +0100 @@ -284,7 +284,10 @@ msg.appendInt( res.getStatus() ); // s-b conversion, message -msg.appendBytes( null ); + MessageBytes mb = new MessageBytes(); + mb.setString(res.getMessage()); + c2b.convert (mb); +msg.appendBytes(mb); // XXX add headers 2. Newly created Coyote Responses contain a status message of NULL instead of OK. Here is my fix: --- Response.java 2002-11-06 10:46:36.0 +0100 +++ Response.java_new 2002-11-06 10:04:49.0 +0100 @@ -102,7 +102,7 @@ /** * Status message. */ -protected String message = null; +protected String message = OK; /** @@ -316,7 +316,7 @@ contentLength = -1; status = 200; -message = null; +message = OK; headers.clear(); // Force the PrintWriter to flush its data to the output @@ -524,7 +524,7 @@ characterEncoding = Constants.DEFAULT_CHARACTER_ENCODING; contentLength = -1; status = 200; -message = null; +message = OK; commited = false; errorException = null; errorURI = null; CU, Stefan -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-5 build.xml
remm2002/11/06 02:14:34
Modified:.build.xml
Log:
- Copy LICENSE to the ${base.path} because of the modeler.
Revision ChangesPath
1.57 +1 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- build.xml 5 Nov 2002 19:25:49 - 1.56
+++ build.xml 6 Nov 2002 10:14:33 - 1.57
-787,6 +787,7
!-- commons-digester needs ../LICENSE --
!-- That is ugly XXX needs a review --
copy file=LICENSE tofile=../LICENSE/
+copy file=LICENSE tofile=${base.path}/LICENSE/
!-- Downdown any sub package or tools needed. --
antcall target=downloadgz
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14293] New: - GetMethod_HEADTest test failed.
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=14293.
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=14293
GetMethod_HEADTest test failed.
Summary: GetMethod_HEADTest test failed.
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The watchdog test makes a HEAD request but Tomcat (using mod_jk 1.2.0).
The result is:
+++
jakarta@vtxclere:~/jakarta-tomcat-4.1.12 telnet localhost 443
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /servlet-tests/GetMethod_HEADTest HTTP/1.0
HTTP/1.1 200
Date: Wed, 06 Nov 2002 09:12:04 GMT
Server: Apache/1.3.27 (Unix) mod_jk/1.2.0
status: GetMethod_HEADTest PASSED
Content-Length: 15
Connection: close
Content-Type: text/plain
Arbitrary text
Connection closed by foreign host.
+++
That is not Ok, HEAD should not contain data.
The servlet code that causes the error is the following:
+++
public void service ( HttpServletRequest request, HttpServletResponse
response ) throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println( Arbitrary text );
+++
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14292] - Status message not included in HTTP response
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=14292. 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=14292 Status message not included in HTTP response --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 10:20 --- -1 to the patch to Response.java, which would cause problems to HTTP/1.1. Instead, you should check for null in the first case and do something else. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources messages.properties
hgomez 2002/11/06 02:41:06
Modified:jasper/src/share/org/apache/jasper/resources
messages.properties
Log:
Correct typos
Revision ChangesPath
1.28 +9 -9
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- messages.properties 16 May 2002 19:27:17 - 1.27
+++ messages.properties 6 Nov 2002 10:41:06 - 1.28
-42,13 +42,13
jsp.error.page.multiple.buffer=Page directive: can't have multiple occurrences of
buffer
jsp.error.page.invalid.buffer=Page directive: invalid value for buffer
jsp.error.page.multiple.autoflush=Page directive: can't have multiple occurrences
of autoFlush
-jsp.error.page.invalid.autoflush==Page directive: invalid value for autoFlush
+jsp.error.page.invalid.autoflush=Page directive: invalid value for autoFlush
jsp.error.page.multiple.threadsafe=Page directive: can't have multiple occurrences
of isThreadSafe
-jsp.error.page.invalid.threadsafe==Page directive: invalid value for isThreadSafe
+jsp.error.page.invalid.threadsafe=Page directive: invalid value for isThreadSafe
jsp.error.page.multiple.info=Page directive: can't have multiple occurrences of info
-jsp.error.page.invalid.info==Page directive: invalid value for info
+jsp.error.page.invalid.info=Page directive: invalid value for info
jsp.error.page.multiple.iserrorpage=Page directive: can't have multiple occurrences
of isErrorPage
-jsp.error.page.invalid.iserrorpage==Page directive: invalid value for isErrorPage
+jsp.error.page.invalid.iserrorpage=Page directive: invalid value for isErrorPage
jsp.error.page.multiple.errorpage=Page directive: can't have multiple occurrences
of errorPage
jsp.error.page.multiple.language=Page directive: can't have multiple occurrences of
language
jsp.error.page.defafteruse.language=Page directive: can't define language after a
scriptlet
-68,7 +68,7
jsp.error.usebean.notinsamefile=useBean tag must begin and end in the same physical
file
jsp.error.unable.loadclass=Unable to load class {0}
jsp.error.unable.compile=Unable to compile class for JSP
-jsp.error.unable.load=Unable to compile class for JSP
+jsp.error.unable.load=Unable to load class for JSP
jsp.error.unable.rename=Unable to rename class file {0} to {1}
jsp.error.mandatory.attribute={0}: Mandatory attribute {1} missing
jsp.engine.info=Jasper JSP 1.1 Engine
-174,11 +174,11
\-mapped Generate separate write() calls for each HTML line in the JSP\n\
\-die[#] Generate an error return code (#) on fatal errors.\n\
\If the number is absent or unparsable it defaults to 1.\n\
-\-uribase dir The uri directory compilations shoule be relative to\n\
+\-uribase dir The uri directory compilations should be relative to\n\
\(Default is /)\n\
\-uriroot dir The root directory that uri files should be resolved\n\
\against, (Default is the directory jspc is invoked from)\n\
-\-webinc file Creates partial servlet mapings for the -webapp option\n\
+\-webinc file Creates partial servlet mapings for the -webapp option.\n\
\-webxml file Creates a complete web.xml when using the -webapp option.\n\
\-ieplugin clsid Java Plugin classid for Internet Explorer\n\
\-sax2 driverclassname Driver class name for the SAX 2.0 parser to be used\n\
-199,7 +199,7
jspc.webinc.header=\n\
!--\n\
Automatically created by Tomcat JspC.\n\
-Place this fragement in the web.xml before all icon, display-name,\n\
+Place this fragment in the web.xml before all icon, display-name,\n\
description, distributable, and context-param elements.\n\
--\n
jspc.webinc.footer=\n\
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resourcesmessages_fr.properties
This should end the french translation of Tomcat 4.1 Catalina 2.0. Changes should be back ported to Tomcat 4.0 and now tomcat-jasper should be translated (may be 99% of the works is allready done from the translation done in TC 4.1 jasper). Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
hgomez 2002/11/06 03:38:35
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Correct typos (could someone validate the fixes ???)
Revision ChangesPath
1.54 +12 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- messages.properties 4 Nov 2002 19:15:33 - 1.53
+++ messages.properties 6 Nov 2002 11:38:35 - 1.54
-43,13 +43,13
jsp.error.page.multiple.buffer=Page directive: can't have multiple occurrences of
buffer
jsp.error.page.invalid.buffer=Page directive: invalid value for buffer
jsp.error.page.multiple.autoflush=Page directive: can't have multiple occurrences
of autoFlush
-jsp.error.page.invalid.autoflush==Page directive: invalid value for autoFlush
+jsp.error.page.invalid.autoflush=Page directive: invalid value for autoFlush
jsp.error.page.multiple.threadsafe=Page directive: can't have multiple occurrences
of isThreadSafe
-jsp.error.page.invalid.threadsafe==Page directive: invalid value for isThreadSafe
+jsp.error.page.invalid.threadsafe=Page directive: invalid value for isThreadSafe
jsp.error.page.multiple.info=Page directive: can't have multiple occurrences of info
-jsp.error.page.invalid.info==Page directive: invalid value for info
+jsp.error.page.invalid.info=Page directive: invalid value for info
jsp.error.page.multiple.iserrorpage=Page directive: can't have multiple occurrences
of isErrorPage
-jsp.error.page.invalid.iserrorpage==Page directive: invalid value for isErrorPage
+jsp.error.page.invalid.iserrorpage=Page directive: invalid value for isErrorPage
jsp.error.page.multiple.errorpage=Page directive: can't have multiple occurrences
of errorPage
jsp.error.page.multiple.language=Page directive: can't have multiple occurrences of
language
jsp.error.page.defafteruse.language=Page directive: can't define language after a
scriptlet
-74,7 +74,7
jsp.error.usebean.notinsamefile=useBean tag must begin and end in the same physical
file
jsp.error.unable.loadclass=Unable to load class {0}
jsp.error.unable.compile=Unable to compile class for JSP
-jsp.error.unable.load=Unable to compile class for JSP
+jsp.error.unable.load=Unable to load class for JSP
jsp.error.unable.rename=Unable to rename class file {0} to {1}
jsp.error.mandatory.attribute={0}: Mandatory attribute {1} missing
jsp.engine.info=Jasper JSP 1.1 Engine
-112,7 +112,9
jsp.error.setproperty.beanNotFound=setProperty: Bean {0} not found
jsp.error.getproperty.beanNotFound=getProperty: Bean {0} not found
jsp.error.setproperty.ClassNotFound=setProperty: Class {0} not found
-jsp.error.setproperty.invalidSyantax=setProperty: can't have non-null value when
property=*
+# typo ?
+#jsp.error.setproperty.invalidSayntax=setProperty: can't have non-null value when
property=*
+jsp.error.setproperty.invalidSyntax=setProperty: can't have non-null value when
property=*
jsp.error.setproperty.beanInfoNotFound=setproperty: beanInfo for bean {0} not found
jsp.error.setproperty.paramOrValue=setProperty: either param or value can be present
jsp.error.setproperty.arrayVal=setProperty: can't set array property {0} through a
string constant value
-186,11 +188,11
\-mapped Generate separate write() calls for each HTML line in the JSP\n\
\-die[#] Generate an error return code (#) on fatal errors.\n\
\If the number is absent or unparsable it defaults to 1.\n\
-\-uribase dir The uri directory compilations shoule be relative to\n\
+\-uribase dir The uri directory compilations should be relative to\n\
\(Default is /)\n\
\-uriroot dir The root directory that uri files should be resolved\n\
\against, (Default is the directory jspc is invoked from)\n\
-\-webinc file Creates partial servlet mapings for the -webapp option\n\
+\-webinc file Creates partial servlet mappings for the -webapp option\n\
\-webxml file Creates a complete web.xml when using the -webapp option.\n\
\-ieplugin clsid Java Plugin classid for Internet Explorer\n\
\-sax2 driverclassname Driver class name for the SAX 2.0 parser to be used\n\
-211,7 +213,7
jspc.webinc.header=\n\
!--\n\
Automatically created by Tomcat JspC.\n\
-Place this fragement in the web.xml before all icon, display-name,\n\
+Place this fragment in the web.xml before all icon, display-name,\n\
description, distributable, and context-param elements.\n\
--\n
jspc.webinc.footer=\n\
--
To unsubscribe,
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages_fr.properties
hgomez 2002/11/06 03:38:49
Added: jasper2/src/share/org/apache/jasper/resources
messages_fr.properties
Log:
Add french translation
Revision ChangesPath
1.1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_fr.properties
Index: messages_fr.properties
===
# $Id: messages_fr.properties,v 1.1 2002/11/06 11:38:49 hgomez Exp $
#
# Default localized string information
# Localized this the Default Locale as is fr_FR
jsp.error.bad.servlet.engine=Version de moteur de servlet incorrecte!
jsp.error.no.scratch.dir=Le moteur de JSP engine n''est pas configuré avec un
répertoire de travail.\
\n Merci d''ajouter \jsp.initparams=scratchdir=dir-name\ \
\n dans le fichier servlets.properties de ce contexte.
jsp.error.bad.scratch.dir=Le paramêtre scratchDir que vous avez spécifié: {0} est
inutilisable.
jsp.message.scratch.dir.is=Le répertoire de travail (scratch dir) pour le moteur de
JSP est: {0}
jsp.message.parent_class_loader_is=Le chargeur de classe parent (class loader) est:
{0}
jsp.message.dont.modify.servlets=IMPORTANT: Ne pas modifier les servlets générées
jsp.error.not.impl.comments=Erreur interne: Commentaires non implémentés
jsp.error.not.impl.directives=Erreur interne: Directives non implémentées
jsp.error.not.impl.declarations=Erreur interne: Declarations non implémentées
jsp.error.not.impl.expressions=Erreur interne: Expressions non implémentées
jsp.error.not.impl.scriptlets=Erreur interne: Scriptlets non implémentés
jsp.error.not.impl.usebean=Erreur interne: useBean non implémenté
jsp.error.not.impl.getp=Erreur interne: getProperty non implémenté
jsp.error.not.impl.setp=Erreur interne: setProperty non implémenté
jsp.error.not.impl.plugin=Erreur interne: plugin non implémenté
jsp.error.not.impl.forward=Erreur interne: forward non implémenté
jsp.error.not.impl.include=Erreur interne: include non implémenté
jsp.error.unavailable=La JSP a été marquée comme non disponible
jsp.error.usebean.missing.attribute=useBean: l''identificateur d''attribut (id
attribute) est manquant ou mal orthographié
jsp.error.usebean.missing.type=useBean ({0}): La classe ou le type d''attribut doit
être\
spécifié:
jsp.error.usebean.duplicate=useBean: Nom de bean dupliqué: {0}
jsp.error.usebean.prohibited.as.session=Impossible d''utiliser comme bean de session
{0} car c''est interdit\
par la directive jsp définie précédemment:
jsp.error.usebean.not.both=useBean: Impossible de spécifier à la fois la classe et
l''attribut beanName:
jsp.error.usebean.bad.type.cast=useBean ({0}): Le type ({1}) n''est pas assignable
depuis la classe ({2})
jsp.error.usebean.invalid.scope=Portée incorrecte ({1}) dans le useBean: ({0}).
jsp.error.classname=Impossible de déterminer le nom de classe d''après le fichier
.class
jsp.warning.bad.type=Attention: mauvais type dans le fichier .class
jsp.error.data.file.write=Erreur lors de l''écriture du fichier de données
jsp.error.page.multiple.contenttypes=Directive de page: on ne peut avoir plusieurs
occurrences du contentType
#Directive de Page: valeur incorrecte pour pageEncoding
jsp.error.page.invalid.contenttype=Directive de Page: valeur incorrecte pour
contentType
jsp.error.page.multiple.session=Directive de Page: on ne peut avoir plusieurs
occurrences de session
jsp.error.page.invalid.session=Directive de Page: valeur incorrecte pour session
jsp.error.page.multiple.buffer=Directive de Page: on ne peut avoir plusieurs
occurrences de buffer
jsp.error.page.invalid.buffer=Directive de Page: valeur incorrecte pour buffer
jsp.error.page.multiple.autoflush=Directive de Page: on ne peut avoir plusieurs
occurrences d''autoFlush
jsp.error.page.invalid.autoflush=Directive de Page: valeur incorrecte pour autoFlush
jsp.error.page.multiple.threadsafe=Directive de Page: on ne peut avoir plusieurs
occurrences d''isThreadSafe
jsp.error.page.invalid.threadsafe=Directive de Page: valeur incorrecte pour
isThreadSafe
jsp.error.page.multiple.info=Directive de Page: on ne peut avoir plusieurs
occurrences d''info
jsp.error.page.invalid.info=Directive de Page: valeur incorrecte pour info
jsp.error.page.multiple.iserrorpage=Directive de Page: on ne peut avoir plusieurs
occurrences d''isErrorPage
jsp.error.page.invalid.iserrorpage=Directive de Page: valeur incorrecte pour
isErrorPage
jsp.error.page.multiple.errorpage=Directive de Page: on ne peut avoir plusieurs
occurrences d''errorPage
jsp.error.page.multiple.language=Directive de Page: on ne peut avoir plusieurs
occurrences de language
jsp.error.page.defafteruse.language=Directive de Page: on ne peut définir language
après un scriptlet
jsp.error.page.nomapping.language=Directive de Page: Pas de correspondance pour
language:
jsp.error.page.multiple.extends=Directive de Page: on
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources messages_fr.properties
jfclere 2002/11/06 03:39:41
Modified:jasper/src/share/org/apache/jasper/resources
messages_fr.properties
Log:
Quick review: Some typos.
Revision ChangesPath
1.2 +3 -3
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messages_fr.properties
Index: messages_fr.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources/messages_fr.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- messages_fr.properties6 Nov 2002 10:40:52 - 1.1
+++ messages_fr.properties6 Nov 2002 11:39:41 - 1.2
-98,7 +98,7
jsp.error.paramexpected=Le tag \param\ est attendu avec les attributs \name\ et
\value\ après le tag \params\.
jsp.error.paramexpectedonly=Le tag \param\ est attendu avec les attributs
\name\ et \value\ sans le tag \params\.
jsp.error.closeindividualparam=Le tag param doit être fermé avec \/\
-jsp.error.closeparams=Le tag param tag doit être fermé avec /params
+jsp.error.closeparams=Le tag \param\ doit être fermé avec \/params\
jsp.error.plugin.notype=type non déclaré dans jsp:plugin
jsp.error.plugin.nocode=code non déclaré dans jsp:plugin
jsp.error.plugin.notclosed=jsp:plugin non fermé
-116,7 +116,7
jsp.warning.sendErrToClient=Attention: Valeur incorrecte pour le initParam
sendErrToClient. Utilisation de la valeur par défaut \false\
jsp.warning.classDebugInfo=Attention: Valeur incorrecte pour le initParam
classdebuginfo. Utilisation de la valeur par défaut \false\
jsp.error.badtaglib=Impossible d''ouvrir le taglibrary {0} : {1}
-jsp.error.badGetReader=Impossible de créer un lecteur (reader) quand le flux
n''utilse pas des tampons (not buffered)
+jsp.error.badGetReader=Impossible de créer un lecteur (reader) quand le flux
n''utilise pas des tampons (not buffered)
jsp.warning.unknown.element.in.TLD=Attention: Elément inconnu {0} dans le TLD
jsp.warning.unknown.element.in.tag=Attention: Elément inconnu {0} dans le tag
jsp.warning.unknown.element.in.attribute=Attention: Elément inconnu {0} dans
l''attribute
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resourcesmessages_fr.properties
Henri Gomez wrote: This should end the french translation of Tomcat 4.1 Catalina 2.0. Changes should be back ported to Tomcat 4.0 and now tomcat-jasper should be translated (may be 99% of the works is allready done from the translation done in TC 4.1 jasper). I have (quiclky) reviewed it and committed the typos I have found. Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resourcesmessages_fr.properties
[EMAIL PROTECTED] wrote: jfclere 2002/11/06 03:39:41 You should probably port them to tomcat-jasper ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resourcesmessages_fr.properties
[EMAIL PROTECTED] wrote: hgomez 2002/11/06 03:38:49 Added: jasper2/src/share/org/apache/jasper/resources messages_fr.properties Log: Add french translation Ok this should be the last part of french translation (ouf). French readers should make a revue and make necessary changes. BTW, did there is some tools which could be add in build script to check in translation are correct, ie don't miss some late keywords... -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14059] - HTTP Response does not respond correctly to flush()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14059 HTTP Response does not respond correctly to flush() --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 11:51 --- Remy, Thank you. Sorry for not being more concise out of the gate. It has been a learning process all around. Over the past few days working the issue, I have found that using the JDK http client is not the correct way to go. I have started testing the Jakarta httpclient. I pulled the last nightly build down. It handles the chunking issue fine. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardWrapper.java
In case you weren't joking ...
It can easily break compatibility if someone introduces a new class with
the same class name as another class in a different package.
ex:
import foo.*; /* has class A */
import bar.*; /* has class B */
class Foo {
A a;
B b;
}
Imagine time going by and another developer creates another class called
A in the bar package. The code above will not recompile because of the
abiguous class name.
-Tim
Costin Manolache wrote:
BTW - what's evil in import * ? I never understood.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13538] - Cannot set relative path in %@include ... %directive
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=13538. 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=13538 Cannot set relative path in %@include ... %directive [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:14 --- Doesn't work when using a WAR as a docBase value -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13538] - Cannot set relative path in %@include ... %directive
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=13538. 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=13538 Cannot set relative path in %@include ... %directive [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:19 --- *** This bug has been marked as a duplicate of 13583 *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13583] - Relative includes/forwards with ../s broken
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=13583. 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=13583 Relative includes/forwards with ../s broken [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:19 --- *** Bug 13538 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 10629] - include directive fails when referencing Parent Path within a WAR
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=10629. 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=10629 include directive fails when referencing Parent Path within a WAR [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:27 --- This bug still exists in tomcat version - 4.1.12. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
remm2002/11/06 05:27:54
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
Log:
- Should fix bug 13583.
- Normalize request dispatcher path.
Revision ChangesPath
1.5 +24 -23
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ApplicationContext.java 23 Oct 2002 19:57:30 - 1.4
+++ ApplicationContext.java 6 Nov 2002 13:27:54 - 1.5
-542,7 +542,8
if (!path.startsWith(/))
throw new IllegalArgumentException
(sm.getString(applicationContext.requestDispatcher.iae, path));
-if (normalize(path) == null)
+path = normalize(path);
+if (path == null)
return (null);
// Construct a fake request to be mapped by our Context
-1019,26 +1020,26
*/
private String normalize(String path) {
-String normalized = path;
+String normalized = path;
-// Normalize the slashes and add leading slash if necessary
-if (normalized.indexOf('\\') = 0)
-normalized = normalized.replace('\\', '/');
-
-// Resolve occurrences of /../ in the normalized path
-while (true) {
-int index = normalized.indexOf(/../);
-if (index 0)
-break;
-if (index == 0)
-return (null); // Trying to go outside our context
-int index2 = normalized.lastIndexOf('/', index - 1);
-normalized = normalized.substring(0, index2) +
-normalized.substring(index + 3);
-}
+// Normalize the slashes and add leading slash if necessary
+if (normalized.indexOf('\\') = 0)
+normalized = normalized.replace('\\', '/');
+
+// Resolve occurrences of /../ in the normalized path
+while (true) {
+int index = normalized.indexOf(/../);
+if (index 0)
+break;
+if (index == 0)
+return (null); // Trying to go outside our context
+int index2 = normalized.lastIndexOf('/', index - 1);
+normalized = normalized.substring(0, index2) +
+normalized.substring(index + 3);
+}
-// Return the normalized path that we have completed
-return (normalized);
+// Return the normalized path that we have completed
+return (normalized);
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardWrapper.java
Tim Funk wrote:
In case you weren't joking ...
It can easily break compatibility if someone introduces a new class with
the same class name as another class in a different package.
ex:
import foo.*; /* has class A */
import bar.*; /* has class B */
class Foo {
A a;
B b;
}
Imagine time going by and another developer creates another class called
A in the bar package. The code above will not recompile because of the
abiguous class name.
I think costin is speaking about importing java.io.*
or org.apache.*.
BTW, there is ant task, for example CheckStyle
(http://checkstyle.sourceforge.net/) which could be used
and which may be integrated in build/gump to clean code
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 10629] - include directive fails when referencing Parent Path within a WAR
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=10629. 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=10629 include directive fails when referencing Parent Path within a WAR [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:36 --- Don't reopen the same bug many times. *** This bug has been marked as a duplicate of 13583 *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13583] - Relative includes/forwards with ../s broken
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=13583. 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=13583 Relative includes/forwards with ../s broken [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:36 --- *** Bug 10629 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
remm2002/11/06 05:37:03
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
Log:
- Add path normalization for getResource and getResourceAsStream.
Revision ChangesPath
1.6 +17 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ApplicationContext.java 6 Nov 2002 13:27:54 - 1.5
+++ ApplicationContext.java 6 Nov 2002 13:37:03 - 1.6
-597,6 +597,11
*/
public URL getResource(String path)
throws MalformedURLException {
+
+path = normalize(path);
+if (path == null)
+return (null);
+
DirContext resources = context.getResources();
if (resources != null) {
String fullPath = context.getName() + path;
-636,6 +641,10
*/
public InputStream getResourceAsStream(String path) {
+path = normalize(path);
+if (path == null)
+return (null);
+
DirContext resources = context.getResources();
if (resources != null) {
try {
-658,6 +667,10
* param path Collection path
*/
public Set getResourcePaths(String path) {
+
+path = normalize(path);
+if (path == null)
+return (null);
DirContext resources = context.getResources();
if (resources != null) {
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationContext.java
remm2002/11/06 05:39:36
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
Log:
- Port patch for bug 13583.
Revision ChangesPath
1.40 +15 -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.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- ApplicationContext.java 28 Jun 2002 01:35:34 - 1.39
+++ ApplicationContext.java 6 Nov 2002 13:39:36 - 1.40
-589,7 +589,8
if (!path.startsWith(/))
throw new IllegalArgumentException
(sm.getString(applicationContext.requestDispatcher.iae, path));
-if (normalize(path) == null)
+path = normalize(path);
+if (path == null)
return (null);
// Construct a fake request to be mapped by our Context
-649,6 +650,11
*/
public URL getResource(String path)
throws MalformedURLException {
+
+path = normalize(path);
+if (path == null)
+return (null);
+
DirContext resources = context.getResources();
if (resources != null) {
String fullPath = context.getName() + path;
-687,6 +693,10
* param path The path to the desired resource.
*/
public InputStream getResourceAsStream(String path) {
+
+path = normalize(path);
+if (path == null)
+return (null);
DirContext resources = context.getResources();
if (resources != null) {
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13583] - Relative includes/forwards with ../s broken
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=13583. 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=13583 Relative includes/forwards with ../s broken [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 13:41 --- This should be fixed in Tomcat 4.1.15. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
Remy Maucherat wrote: Costin Manolache wrote: I'm getting closer - Remy or Kin-Man, I need your help. As I expected, the flush() was hiding some other behaviors. Right now I'm looking at ApplicationDispatcher.doForward(). What happens is: - error happens - we forward to the error page - error page executes, put the data in the out buffer - BEFORE: the out buffer was commited - now we just return from servlet to doForward() - The commiting and closing response reached ( line 471 ) What happens here is response is a ResponseFacade, and finish is called. But the real flushing and closing doesn't actually happens. I changed the code to first flush/close, the call finish - and it now seems to work fine. But I'm not sure what else may be affected by this - or if it's safe to make the change ( well, for 5.0 it may be, but what about 4.1 ? ) In any case, I expect this to have caused some weird behavior for normal forward - since forward doesn't seem to really flush/close as it was supposed to do ( unless response is not facade - does this case ever happen ? ). A bit strange no other test detected that, normal servlets don't have flush/close that the jsp page had. No, that wouldn't work. forward does a fake flush/close, because some further error page processing may occur (based on the status code, for example). I think we'll have to do the commit in the JSP error page itself (and call close right away in the case, rather than flush). I hope it's doable. Given the risk of this refactoring, I propose delaying it in 4.1.x until at least after the next stable release. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/xdocs/images jakarta.gif
hgomez 2002/11/06 06:23:35 Modified:jk/xdocs/images jakarta.gif Log: Update jakarta logo to the new one ;) Revision ChangesPath 1.2 +77 -50jakarta-tomcat-connectors/jk/xdocs/images/jakarta.gif Binary file -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardWrapper.java
On Wed, 2002-11-06 at 06:55, Tim Funk wrote:
In case you weren't joking ...
It can easily break compatibility if someone introduces a new class with
the same class name as another class in a different package.
IMHO, the more important reason to not use import xx.* is because it
is harder for a developer to figure out where a class is coming from...
So I see it as a code readability issue.
Cheers,
-bob
ex:
import foo.*; /* has class A */
import bar.*; /* has class B */
class Foo {
A a;
B b;
}
Imagine time going by and another developer creates another class called
A in the bar package. The code above will not recompile because of the
abiguous class name.
-Tim
Costin Manolache wrote:
BTW - what's evil in import * ? I never understood.
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
JSPC problems with webapp option
Hi all, I toyed a bit with the webapp option of JSPC, and a few things seemed really odd. - Although there are options to generate web.xml files or fragments, this makes no sense as the generated files are now meant to be put in the work directory instead. This was probably done as a workaround for the slow Jasper runtime (that has been fixed). I think those options should be removed, and it should be made clear that the target directory should be the webapp's work directory. - There should be an optional compilation flag (also compile if present). That's very convinient IMO. I propose -c (with false being the default). Those changes should be simple to implement (I plan to do it, and integrate them in 4.1.15). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/xdocs style.xsl.in
hgomez 2002/11/06 06:31:52
Modified:jk/xdocs style.xsl.in
Log:
New jakarta logo, new image size
Revision ChangesPath
1.15 +1 -1 jakarta-tomcat-connectors/jk/xdocs/style.xsl.in
Index: style.xsl.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/style.xsl.in,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- style.xsl.in 28 Sep 2002 06:06:37 - 1.14
+++ style.xsl.in 6 Nov 2002 14:31:52 - 1.15
-99,7 +99,7
table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td align=left
-img src={$images}/jakarta.gif border=0 width=270
height=75 align=left/
+img src={$images}/jakarta.gif border=0 width=505
height=48 align=left/
/td
td align=right
img src={$images}/mod_jk.jpg border=0 align=right/
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[PATCH][JK] Ajp13Processor connection leak prevention
Adjusted Ajp13Processor's run() method to protect against unexpected
unchecked excpetions, preventing the possibility of a leak in
Ajp13Connector's request processor pool.
Index: Ajp13Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
retrieving revision 1.9
diff -u -u -r1.9 Ajp13Processor.java
--- Ajp13Processor.java 7 Jun 2002 18:54:21 - 1.9
+++ Ajp13Processor.java 6 Nov 2002 08:01:14 -
@@ -547,14 +547,16 @@
logger.log(socket assigned.);
}
- // Process the request from this socket
- process(socket);
-
- // Finish up this request
-if (debug 0) {
-logger.log(recycling myself ...);
+try {
+// Process the request from this socket
+process(socket);
+} finally {
+// Finish up this request
+if (debug 0) {
+logger.log(recycling myself ...);
+}
+connector.recycle(this);
}
- connector.recycle(this);
}
// Tell threadStop() we have shut ourselves down successfully
On another note, what's the most robust Java and Apache httpd
connector code bases these days for Tomcat 4.1? Not trying to start a
religious war -- interested in your opinions. Please send me to the
appropriate docs if this is a RTFM question.
Thanks!
--
Daniel Rall [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
New jakarta logo to be included in tomcat 3/4/5 ?
Hi, I just updated in jtc/jk docs the jakarta logo by the new one. Any objection I do the same for the others tomcat projects ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: JSPC problems with webapp option
There are some people that would like to precompile the webapp and then just deploy the generated servlets with there webapp, to remove this option would really hinder their ability to due this (although the package naming already makes this tough to do and there are patches floating around to allow the packages to be generated from the dir structure, I also belive there are bugs about this) Just my 2 cents.. John -Original Message- From: Remy Maucherat [mailto:remm;apache.org] Sent: Wednesday, November 06, 2002 9:29 AM To: Tomcat Developers List Subject: JSPC problems with webapp option Hi all, I toyed a bit with the webapp option of JSPC, and a few things seemed really odd. - Although there are options to generate web.xml files or fragments, this makes no sense as the generated files are now meant to be put in the work directory instead. This was probably done as a workaround for the slow Jasper runtime (that has been fixed). I think those options should be removed, and it should be made clear that the target directory should be the webapp's work directory. - There should be an optional compilation flag (also compile if present). That's very convinient IMO. I propose -c (with false being the default). Those changes should be simple to implement (I plan to do it, and integrate them in 4.1.15). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
Remy Maucherat wrote: In any case, I expect this to have caused some weird behavior for normal forward - since forward doesn't seem to really flush/close as it was supposed to do ( unless response is not facade - does this case ever happen ? ). A bit strange no other test detected that, normal servlets don't have flush/close that the jsp page had. No, that wouldn't work. forward does a fake flush/close, because some further error page processing may occur (based on the status code, for example). I think we'll have to do the commit in the JSP error page itself (and call close right away in the case, rather than flush). I hope it's doable. Can you point me to the code doing this extra processing ? I'm a bit confused: - for jsps ( with flush-in-release ) that just can't work, since the flush is already done by the jsp page. - the comment ( or the message ) in forward is probably wrong. - my bigger question is when is the response not a facade ? My understanding is that facades are used all the time, so the second part of the if will never happen I do see your point - if forward() flushes then the extra error processing is broken. That's another argument to not do the flush() in release() :-) And it does explain who is generating the stack trace. I have a feeling we just need to clear the error flags after the jsp error page - I'm pretty sure the jsp error page was executed and the data is in the out buffer. Somehow the servlet error processing kicks in and overrides the jsp error page. Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Antw: RE: JSPC problems with webapp option
Indeed, I'm one of those persons. I generate the web.xml fragment for my entire webapp, and integrate it into my original web.xml using xslt. I deploy only the generated servlets, no JSP or Java sources at all. It would be really bad if I couldn't do that anymore. -- Sebastian [EMAIL PROTECTED] 06.11.02 16:20:42 There are some people that would like to precompile the webapp and then just deploy the generated servlets with there webapp, to remove this option would really hinder their ability to due this (although the package naming already makes this tough to do and there are patches floating around to allow the packages to be generated from the dir structure, I also belive there are bugs about this) Just my 2 cents.. John -Original Message- From: Remy Maucherat [mailto:remm;apache.org] Sent: Wednesday, November 06, 2002 9:29 AM To: Tomcat Developers List Subject: JSPC problems with webapp option Hi all, I toyed a bit with the webapp option of JSPC, and a few things seemed really odd. - Although there are options to generate web.xml files or fragments, this makes no sense as the generated files are now meant to be put in the work directory instead. This was probably done as a workaround for the slow Jasper runtime (that has been fixed). I think those options should be removed, and it should be made clear that the target directory should be the webapp's work directory. - There should be an optional compilation flag (also compile if present). That's very convinient IMO. I propose -c (with false being the default). Those changes should be simple to implement (I plan to do it, and integrate them in 4.1.15). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: JSPC problems with webapp option
Hi Remy, being another toyer I believe your second point is covered by the --compile flag. What I personally lack is the possibility to get warnings when compiling. (As opposed to errors only.) Grüsse, Michael -Original Message- From: Remy Maucherat [mailto:remm;apache.org] Sent: Wednesday, November 06, 2002 3:29 PM To: Tomcat Developers List Subject: JSPC problems with webapp option Hi all, I toyed a bit with the webapp option of JSPC, and a few things seemed really odd. - Although there are options to generate web.xml files or fragments, this makes no sense as the generated files are now meant to be put in the work directory instead. This was probably done as a workaround for the slow Jasper runtime (that has been fixed). I think those options should be removed, and it should be made clear that the target directory should be the webapp's work directory. - There should be an optional compilation flag (also compile if present). That's very convinient IMO. I propose -c (with false being the default). Those changes should be simple to implement (I plan to do it, and integrate them in 4.1.15). Comments ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
Costin Manolache wrote: Remy Maucherat wrote: In any case, I expect this to have caused some weird behavior for normal forward - since forward doesn't seem to really flush/close as it was supposed to do ( unless response is not facade - does this case ever happen ? ). A bit strange no other test detected that, normal servlets don't have flush/close that the jsp page had. No, that wouldn't work. forward does a fake flush/close, because some further error page processing may occur (based on the status code, for example). I think we'll have to do the commit in the JSP error page itself (and call close right away in the case, rather than flush). I hope it's doable. Can you point me to the code doing this extra processing ? I'm a bit confused: - for jsps ( with flush-in-release ) that just can't work, since the flush is already done by the jsp page. - the comment ( or the message ) in forward is probably wrong. - my bigger question is when is the response not a facade ? My understanding is that facades are used all the time, so the second part of the if will never happen That code was already there before the facades. I don't think it is used anymore, but would leave it anyway in 4.1.x (it could be removed in 5). I do see your point - if forward() flushes then the extra error processing is broken. That's another argument to not do the flush() in release() :-) And it does explain who is generating the stack trace. The error page and status report processing is in ErrorReport/DispatcherValve. That's where the stack trace is output unless the response has been committed (by flushing usually). I have a feeling we just need to clear the error flags after the jsp error page - I'm pretty sure the jsp error page was executed and the data is in the out buffer. Somehow the servlet error processing kicks in and overrides the jsp error page. Yes, that's likely the right explanation. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC problems with webapp option
Although I'm just a user, I would like to warnings also. On a related note, --compile isn't covered in the documentation. I stumbled across it when I look at the source code a month back. It might be nice to output the warnings to a file for those who have large webapps with thousands of jsp files. peter Eriksson, Michael wrote: Hi Remy, being another toyer I believe your second point is covered by the --compile flag. What I personally lack is the possibility to get warnings when compiling. (As opposed to errors only.) Grüsse, Michael -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime PageContextImpl.java
costin 2002/11/06 07:38:45
Modified:jasper2/src/share/org/apache/jasper/runtime Tag:
tomcat_4_branch PageContextImpl.java
Log:
Revert the flush-in-release patch for 4.1 tree.
Revision ChangesPath
No revision
No revision
1.11.2.3 +1 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
retrieving revision 1.11.2.2
retrieving revision 1.11.2.3
diff -u -r1.11.2.2 -r1.11.2.3
--- PageContextImpl.java 29 Oct 2002 22:29:05 - 1.11.2.2
+++ PageContextImpl.java 6 Nov 2002 15:38:44 - 1.11.2.3
-178,10 +178,7
((JspWriterImpl)out).flushBuffer();
// push it into the including jspWriter
} else {
- //out.flush();
- // As discussed on the main list - this allows Content-Length
-// to work with servlets
-((JspWriterImpl)out).flushBuffer();
+ out.flush();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC problems with webapp option
Remy Maucherat wrote: Hi all, I toyed a bit with the webapp option of JSPC, and a few things seemed really odd. - Although there are options to generate web.xml files or fragments, this makes no sense as the generated files are now meant to be put in the work directory instead. This was probably done as a workaround for the slow Jasper runtime (that has been fixed). I think those options should be removed, and it should be made clear that the target directory should be the webapp's work directory. - There should be an optional compilation flag (also compile if present). That's very convinient IMO. I propose -c (with false being the default). Those changes should be simple to implement (I plan to do it, and integrate them in 4.1.15). Comments ? +1 Here is a related idea we may want to do sometime in the future. Add a flag to the manager deploy and install commands which forces a compile of all JSP pages before the context is made available. Kind of a precompile all JSP pages as the webapp is installed option. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC problems with webapp option
peter lin wrote: Although I'm just a user, I would like to warnings also. On a related note, --compile isn't covered in the documentation. I stumbled across it when I look at the source code a month back. It might be nice to output the warnings to a file for those who have large webapps with thousands of jsp files. I didn't know about --compile. I'll rename it to -compile and document it (to be consistent). Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
Remy Maucherat wrote: Can you point me to the code doing this extra processing ? I'm a bit confused: - for jsps ( with flush-in-release ) that just can't work, since the flush is already done by the jsp page. - the comment ( or the message ) in forward is probably wrong. - my bigger question is when is the response not a facade ? My understanding is that facades are used all the time, so the second part of the if will never happen That code was already there before the facades. I don't think it is used anymore, but would leave it anyway in 4.1.x (it could be removed in 5). I already reverted the patch in 4.1.x - it's too dangerous for the stable tree. So you are saying that forward() used to do a flush, but it was changed when facades where added to just set the flag - to improve the error handling. Sounds consistent with the behavior we have now. Could you add a little comment ( or at least remove the debug message that says 'flushing' ) ? The new behavior ( no real flush ) seems correct. Costin I do see your point - if forward() flushes then the extra error processing is broken. That's another argument to not do the flush() in release() :-) And it does explain who is generating the stack trace. The error page and status report processing is in ErrorReport/DispatcherValve. That's where the stack trace is output unless the response has been committed (by flushing usually). I have a feeling we just need to clear the error flags after the jsp error page - I'm pretty sure the jsp error page was executed and the data is in the out buffer. Somehow the servlet error processing kicks in and overrides the jsp error page. Yes, that's likely the right explanation. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Client-cert authentication.
Thanks a lot Bob and Jean-frederic for the response but I´m afraid I don´t understand clearly the solution: As far as I know, when I configure the server.xml of the Tomcat/conf directory in order to use the keystore where I´ve imported the trusted certs of the chain I thought I was saying tomcat that the keystore for the authentication was that, and it wasn´t necesary to configure another trusted keystore. Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false keystoreFile=C:\Documents and Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore keystorePass=396947j protocol=TLS algorithm=SunX509 keystoreType=JKS/ Is necesary to configure both keystores? Thanks again, and sorry for my question if it´s something clear for everyone. - Original Message - From: Bob Herrmann [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 05, 2002 9:58 PM Subject: Re: Client-cert authentication. As someone else already pointed out, you need to configure the trust stores (Which tell tomcat what clients to trust.) You can do that by changing some config files, or like this on the command line (with redhat) export CATALINA_OPTS=-Djavax.net.ssl.trustStore=/home/bob/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit Cheers, -bob export CATALINA -Djavax.net.ssl.trustStore=/home/bob/issues/ssl/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit On Tue, 2002-11-05 at 11:35, Moisés Serrano Martínez wrote: I´ve a small (or big) problem configuring Tomcat 4.1.12. Does anyone know how to configure the client side of the matter? What I have done is : 1) Create a selfsigned certificate (master certificate). 2) With the master create another one intemediate for localhost (signed with the private key of the master one) - Import the chain into a keystore: server.keystore ( the master and localhost, this last one with the private key) 3) With the localhost certificate create a user certificate (signed with the private key of localhost). - Import the user certificate into the server.keystore. 4) Import the chain into a keystore: server.keystore - At this point all must be ok because the server authentication works perfectly, when a client try to connect to localhost. 5) Configure the server.xml: - Define a SSL Coyote HTTP/1.1 Connector on port 8443: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=3 scheme=https secure=true useURIValidationHack=false - Locate the keystore inside the factory, CoyoteServerSocketFactory, with clientAuth=false. Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false keystoreFile=C:\Documents and Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore keystorePass=396947j protocol=TLS algorithm=SunX509 keystoreType=JKS/ 6) Configure the web.xml, if the auth.method selected is BASIC everything works fine, the problem begins when I try that a context works with client authentication. ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app display-nameadminWeb/display-name welcome-file-list welcome-fileadminWeb.jsp/welcome-file /welcome-file-list security-constraint web-resource-collection web-resource-nameadminWeb/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config security-role descriptionAn example role defined in conf/tomcat-users.xml/description role-nameadmin/role-name /security-role /web-app 7) In the client side: - Generate a p12 keystore in order to import the user certificate and his private key. - Import in the Client (browser) the master, the intermediate (localhost) and the user certificates. - The user certificate in the p12 format (with the private key) and the other ones with the X509 format: localhost.cer and master.cer. At the end, the result is: type Status report message No hay cadena de certificados del cliente en esta peticion description
DO NOT REPLY [Bug 5585] - Error page not displayed
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=5585. 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=5585 Error page not displayed [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 16:07 --- After reading discussion Re: costin: fix reverted http://marc.theaimsgroup.com/?t=10364461881r=1w=2 I think this bug can be reopened Or I'm not right? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Client-cert authentication.
Moisés Serrano Martínez wrote: Thanks a lot Bob and Jean-frederic for the response but I´m afraid I don´t understand clearly the solution: As far as I know, when I configure the server.xml of the Tomcat/conf directory in order to use the keystore where I´ve imported the trusted certs of the chain I thought I was saying tomcat that the keystore for the authentication was that, and it wasn´t necesary to configure another trusted keystore. Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false keystoreFile=C:\Documents and Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore keystorePass=396947j protocol=TLS algorithm=SunX509 keystoreType=JKS/ Is necesary to configure both keystores? Tomcat is only going to ask for the client certificates it could check therefore it needs the CA certificate that signed the client certificates. The CA certificate are stored in special keystores file. The keystoreFile you specified in the server.xml is for the server certificate and server private key (That is why it is protected by a password, you have one for each Tomcat you run on the machine). The CA certificates are not encrypted because that the public keys of the CA's, they have to be in a different files (I normaly use one per JVM). Thanks again, and sorry for my question if it´s something clear for everyone. - Original Message - From: Bob Herrmann [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 05, 2002 9:58 PM Subject: Re: Client-cert authentication. As someone else already pointed out, you need to configure the trust stores (Which tell tomcat what clients to trust.) You can do that by changing some config files, or like this on the command line (with redhat) export CATALINA_OPTS=-Djavax.net.ssl.trustStore=/home/bob/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit Cheers, -bob export CATALINA -Djavax.net.ssl.trustStore=/home/bob/issues/ssl/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit On Tue, 2002-11-05 at 11:35, Moisés Serrano Martínez wrote: I´ve a small (or big) problem configuring Tomcat 4.1.12. Does anyone know how to configure the client side of the matter? What I have done is : 1) Create a selfsigned certificate (master certificate). 2) With the master create another one intemediate for localhost (signed with the private key of the master one) - Import the chain into a keystore: server.keystore ( the master and localhost, this last one with the private key) 3) With the localhost certificate create a user certificate (signed with the private key of localhost). - Import the user certificate into the server.keystore. 4) Import the chain into a keystore: server.keystore - At this point all must be ok because the server authentication works perfectly, when a client try to connect to localhost. 5) Configure the server.xml: - Define a SSL Coyote HTTP/1.1 Connector on port 8443: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=3 scheme=https secure=true useURIValidationHack=false - Locate the keystore inside the factory, CoyoteServerSocketFactory, with clientAuth=false. Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false keystoreFile=C:\Documents and Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore keystorePass=396947j protocol=TLS algorithm=SunX509 keystoreType=JKS/ 6) Configure the web.xml, if the auth.method selected is BASIC everything works fine, the problem begins when I try that a context works with client authentication. ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app display-nameadminWeb/display-name welcome-file-list welcome-fileadminWeb.jsp/welcome-file /welcome-file-list security-constraint web-resource-collection web-resource-nameadminWeb/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nameadmin/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config security-role descriptionAn example role defined in conf/tomcat-users.xml/description role-nameadmin/role-name /security-role /web-app 7) In the
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c jk_vm_default.c jk_channel_jni.c
mturk 2002/11/06 08:32:25
Modified:jk/native2/common jk_worker_jni.c jk_vm_default.c
jk_channel_jni.c
Log:
Fix the JNI disabling for multi-process servers, moving disabled from
factory to the init.
Also, check if the JVM aborted.
Revision ChangesPath
1.33 +9 -9 jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
Index: jk_worker_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- jk_worker_jni.c 31 Oct 2002 11:55:36 - 1.32
+++ jk_worker_jni.c 6 Nov 2002 16:32:25 - 1.33
-234,6 +234,15
return JK_ERR;
}
+/* Allow only the first child to execute the worker */
+if (_this-workerEnv-childId != 0) {
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ workerJni.Init() Skipping initialization for the %d %d\n,
+ _this-workerEnv-childId,
+ _this-workerEnv-childProcessId);
+return JK_ERR;
+}
+
props=_this-workerEnv-initData;
jniWorker = _this-worker_private;
-462,15 +471,6
}
wEnv = env-getByName( env, workerEnv );
-/* Allow only the first child to execute the worker */
-if (wEnv-childId != 0) {
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- workerJni.factory() Skipping initialization for the %d %d\n,
- wEnv-childId, wEnv-childProcessId);
-result-disabled = 1;
-return JK_OK;
-}
-
/* No singleton - you can have multiple jni workers,
running different bridges or starting different programs inprocess*/
1.27 +9 -4 jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c
Index: jk_vm_default.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- jk_vm_default.c 31 Oct 2002 11:55:36 - 1.26
+++ jk_vm_default.c 6 Nov 2002 16:32:25 - 1.27
-193,14 +193,18
{
jk2_jni_error_signaled = JK_TRUE;
jk2_jni_error_code = code;
-
+
+#ifdef DEBUG
fprintf(stderr, JVM error hook called %d\n, code);
+#endif
}
static void jk2_jni_abort_hook()
{
jk2_jni_abort_signaled = JK_TRUE;
+#ifdef DEBUG
fprintf(stderr, JVM abort hook\n);
+#endif
}
/** Load the VM. Must be called after init.
-276,7 +280,8
int err;
JavaVM *jvm = (JavaVM *)jkvm-jvm;
- if( jvm == NULL ) return NULL;
+ if (jvm == NULL || jk2_jni_abort_signaled)
+ return NULL;
#if defined LINUX defined APACHE2_SIGHACK
/* [V] This message is important. If there are signal mask issues,*
-324,7 +329,7
int err;
JavaVM *jvm = (JavaVM *)jkvm-jvm;
-if( jvm == NULL ) {
+if (jvm == NULL || jk2_jni_abort_signaled) {
return;
}
-608,7 +613,7
int err;
JavaVM *jvm = (JavaVM *)jkvm-jvm;
-if( jvm == NULL ) {
+if (jvm == NULL || jk2_jni_abort_signaled) {
return;
}
1.37 +5 -5 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
Index: jk_channel_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- jk_channel_jni.c 31 Oct 2002 11:55:36 - 1.36
+++ jk_channel_jni.c 6 Nov 2002 16:32:25 - 1.37
-129,6 +129,11
jk_channel_t *jniW=jniWB-object;
jk_workerEnv_t *wEnv=jniW-workerEnv;
+if (wEnv-childId != 0) {
+if( jniW-worker != NULL )
+jniW-worker-mbean-disabled=JK_TRUE;
+return JK_ERR;
+}
if( wEnv-vm == NULL ) {
env-l-jkLog(env, env-l, JK_LOG_INFO,
channel_jni.init() no VM found\n );
-628,11 +633,6
wEnv = env-getByName( env, workerEnv );
-if (wEnv-childId != 0) {
-result-disabled = 1;
-return JK_OK;
-}
-
ch=(jk_channel_t *)pool-calloc(env, pool, sizeof( jk_channel_t));
ch-recv= jk2_channel_jni_recv;
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Client-cert authentication.
On Wed, 2002-11-06 at 10:55, Moisés Serrano Martínez wrote: Thanks a lot Bob and Jean-frederic for the response but I´m afraid I don´t understand clearly the solution: As I understand it, Tomcat uses a keystore and a truststore. Tomcat uses the keystore to answer the client's who are you? question. The answer (Who is this Tomcat server) is retrieved from the keystore. (I am a trusted Tomcat server for Acme corp, my certificate is signed by some central authority.) The truststore is used when Tomcat wants to verify who the client is, Do I trust this client? (Should this client really be allowed to access this site?) Tomcat only asks this, or verifies the client, if the Connector has clientauth=true **OR** if a resource is marked up in the web.xml as requiring CLIENT-CERT The keystore can be set in the server.xml. The truststore must be set using the JDK's property files or via an environment variable (like I mentioned in my earlier email.) This is a tad kludgy because verifying the certs of the client seem to be fairly rare in practice. (I imagine this is because verifying the client certs is something B2B requires and not so much needed by the casual JSP developer.) Cheers, -bob As far as I know, when I configure the server.xml of the Tomcat/conf directory in order to use the keystore where I´ve imported the trusted certs of the chain I thought I was saying tomcat that the keystore for the authentication was that, and it wasn´t necesary to configure another trusted keystore. Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false keystoreFile=C:\Documents and Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore keystorePass=396947j protocol=TLS algorithm=SunX509 keystoreType=JKS/ Is necesary to configure both keystores? Thanks again, and sorry for my question if it´s something clear for everyone. - Original Message - From: Bob Herrmann [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 05, 2002 9:58 PM Subject: Re: Client-cert authentication. As someone else already pointed out, you need to configure the trust stores (Which tell tomcat what clients to trust.) You can do that by changing some config files, or like this on the command line (with redhat) export CATALINA_OPTS=-Djavax.net.ssl.trustStore=/home/bob/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit Cheers, -bob export CATALINA -Djavax.net.ssl.trustStore=/home/bob/issues/ssl/cacerts.jks -Djavax.net.ssl.trustStorePassword=changeit On Tue, 2002-11-05 at 11:35, Moisés Serrano Martínez wrote: I´ve a small (or big) problem configuring Tomcat 4.1.12. Does anyone know how to configure the client side of the matter? What I have done is : 1) Create a selfsigned certificate (master certificate). 2) With the master create another one intemediate for localhost (signed with the private key of the master one) - Import the chain into a keystore: server.keystore ( the master and localhost, this last one with the private key) 3) With the localhost certificate create a user certificate (signed with the private key of localhost). - Import the user certificate into the server.keystore. 4) Import the chain into a keystore: server.keystore - At this point all must be ok because the server authentication works perfectly, when a client try to connect to localhost. 5) Configure the server.xml: - Define a SSL Coyote HTTP/1.1 Connector on port 8443: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=3 scheme=https secure=true useURIValidationHack=false - Locate the keystore inside the factory, CoyoteServerSocketFactory, with clientAuth=false. Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false keystoreFile=C:\Documents and Settings\mserrano\.jbuilder4\Claves\CA_almacen\ca\server.keystore keystorePass=396947j protocol=TLS algorithm=SunX509 keystoreType=JKS/ 6) Configure the web.xml, if the auth.method selected is BASIC everything works fine, the problem begins when I try that a context works with client authentication. ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app display-nameadminWeb/display-name welcome-file-list welcome-fileadminWeb.jsp/welcome-file /welcome-file-list security-constraint web-resource-collection web-resource-nameadminWeb/web-resource-name
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk aphowto.xml
hgomez 2002/11/06 08:59:51 Modified:jk/xdocs/jk aphowto.xml Log: Add aix binaries link Revision ChangesPath 1.15 +1 -0 jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml Index: aphowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/aphowto.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- aphowto.xml 28 Oct 2002 14:37:06 - 1.14 +++ aphowto.xml 6 Nov 2002 16:59:51 - 1.15 -169,6 +169,7 p table trthLocation/ththContents/th/tr + trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/aix/;aix/a/tdtdSAVF including mod_jk for Apache 2.0 for iSeries V5R1/V5R2/td/tr trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/iseries/;iseries/a/tdtdSAVF including mod_jk for Apache 2.0 for iSeries V5R1/V5R2/td/tr trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/linux/;linux/a/tdtdmod_jk.so (Apache 1.3 standard API and EAPI and Apache 2.0) for some Linux Archs/td/tr trtda href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/macosx/;macosx/a/tdtdContains the mod_jk.so for MacOS X/td/tr -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk quickhowto.xml
hgomez 2002/11/06 09:00:32 Modified:jk/xdocs menu.jk.idx Added: jk/xdocs/jk quickhowto.xml Log: Add the Quick HowTo for impatients (how many on tomcat-user list :-) Revision ChangesPath 1.3 +1 -0 jakarta-tomcat-connectors/jk/xdocs/menu.jk.idx Index: menu.jk.idx === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/menu.jk.idx,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- menu.jk.idx 8 Oct 2002 17:56:42 - 1.2 +++ menu.jk.idx 6 Nov 2002 17:00:32 - 1.3 @@ -1,6 +1,7 @@ ?xml version=1.0 encoding=ISO-8859-1? section name=JK +document href=jk/quickhowto.xml/ document href=jk/aphowto.xml/ document href=jk/domhowto.xml/ document href=jk/iishowto.xml/ 1.1 jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml Index: quickhowto.xml === ?xml version=1.0? document properties titleQuick Start JK Configuration Guide/title author email=[EMAIL PROTECTED]Henri Gomez/author date$Date: 2002/11/06 17:00:32 $/date /properties section name=Introduction p This document describes the configuration files used by JK on the Tomcat and Web Server side for the impatients: ul li bworkers.properties/b is used on the webserver side. For the Apache servers the default path is in the ServerRoot/conf directory. /li li bWebServers/b add-ons to be set on the webserver side. /li /ul /p p We'll give here minimum servers configuration and an example bworkers.properties/b to be able to install and check quickly your configuration. /p /section section name=Minimum workers.properties p Here is the minimun workers.properties, using just ajp12, ajp13 and load-balancing to connect your Apache webserver to the Tomcat engine /p p screen note# Define 3 workers, 2 real workers using ajp12, ajp13 and the last one being a loadbalancing worker/note readworker.list=worker1, worker2, worker3/read note# Set properties for worker1 (ajp12)/note readworker.worker1.type=ajp12/read readworker.worker1.host=locahost/read readworker.worker1.port=8007/read readworker.worker1.lbfactor=5/read note# Set properties for worker2 (ajp13)/note readworker.worker2.type=ajp13/read readworker.worker2.host=locahost/read readworker.worker2.port=8009/read readworker.worker2.lbfactor=50/read readworker.worker2.cachesize=10/read readworker.worker2.cache_timeout=600/read readworker.worker2.socket_keepalive=1/read readworker.worker2.socket_timeout=300/read note# Set properties for worker3 (lb) which use worker1 and worker2/note readworker.worker3.balanced_workers=worker1,worker2/read /screen /p /section section name=Minimum Apache WebServer configuration p You should first have bmod_jk.so/b (unix) or bmod_jk.dll/b (Windows) installed in your Apache module directory (see your Apache documentation to locate it). /p p Usual locations on Unix: ul li/usr/lib/apache/li li/usr/lib/apache2/li li/usr/local/apache/libexec/li /ul /p p Usual locations on Windows : ul liC:\Program Files\Apache Group\Apache\modules\/li liC:\Program Files\Apache Group\Apache2\modules/li /ul /p p You'll find prebuilt binaries a href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/;here/a /p p Here is the minimum which should be set in bhttpd.conf/b directly or included from another file, the default path is in the ServerRoot/conf directory. /p p screen note# Load mod_jk module/note readLoadModulejk_module libexec/mod_jk.so/read note# Declare the module for lt;IfModule directivegt;/note readAddModule mod_jk.c/read note# Where to find workers.properties/note readJkWorkersFile /etc/httpd/conf/workers.properties/read note# Where to put jk logs/note readJkLogFile /var/log/httpd/mod_jk.log/read note# Set the jk log level [debug/error/info]/note readJkLogLevelinfo/read note# Select the log format/note readJkLogStampFormat [%a %b %d %H:%M:%S %Y] /read note# JkOptions indicate to send SSL KEY SIZE, /note readJkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories/read note# JkRequestLogFormat set the request format /note readJkRequestLogFormat %w %V %T/read note# Send servlet for context /examples to worker named worker1/note readJkMount /examples/servlet/* worker2/read note# Send JSPs for context /examples to worker named worker1/note readJkMount /examples/*.jsp worker2/read /screen /p /section section name=Minimum IIS WebServer configuration p Minimum configuration for
DO NOT REPLY [Bug 14275] - Problems creating DataSource
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=14275. 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=14275 Problems creating DataSource --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 17:02 --- I looked at a documentation, it said add an entry like the one below: ResourceLink name=linkToGlobalResource global=simpleValue type=java.lang.Integer/ Should this element be part of GlobalNamingResources? Could you show me or point me to an example of how I would incorporate this in the server.xml -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14302] New: - Jspc can't be used to compile the entire web application
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=14302. 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=14302 Jspc can't be used to compile the entire web application Summary: Jspc can't be used to compile the entire web application Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The simples example which is fail for me is to compile the standard /admin application. The generated web.xml include to web.xml fails on parsing. It looks like jspc can't handle JSP's in the subrirectories correctly. My suggestion is to add an unit test for jspc that will build /admin application with all precompiled JSP's. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk quickhowto.xml
hgomez 2002/11/06 09:05:10
Modified:jk/xdocs/jk quickhowto.xml
Log:
Typos ;{
Revision ChangesPath
1.2 +3 -3 jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml
Index: quickhowto.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- quickhowto.xml6 Nov 2002 17:00:32 - 1.1
+++ quickhowto.xml6 Nov 2002 17:05:10 - 1.2
-99,9 +99,9
readJkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories/read
note# JkRequestLogFormat set the request format /note
readJkRequestLogFormat %w %V %T/read
-note# Send servlet for context /examples to worker named worker1/note
+note# Send servlet for context /examples to worker named worker2 (ajp13)/note
readJkMount /examples/servlet/* worker2/read
-note# Send JSPs for context /examples to worker named worker1/note
+note# Send JSPs for context /examples to worker named worker2 (ajp13)/note
readJkMount /examples/*.jsp worker2/read
/screen
/p
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk quickhowto.xml
hgomez 2002/11/06 09:11:27 Modified:jk/xdocs/jk quickhowto.xml Log: Shorter name Revision ChangesPath 1.3 +3 -3 jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml Index: quickhowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- quickhowto.xml6 Nov 2002 17:05:10 - 1.2 +++ quickhowto.xml6 Nov 2002 17:11:27 - 1.3 @@ -1,7 +1,7 @@ ?xml version=1.0? document properties -titleQuick Start JK Configuration Guide/title +titleQuick Start JK HowTo/title author email=[EMAIL PROTECTED]Henri Gomez/author date$Date$/date /properties @@ -71,7 +71,7 @@ Usual locations on Windows : ul liC:\Program Files\Apache Group\Apache\modules\/li - liC:\Program Files\Apache Group\Apache2\modules/li + liC:\Program Files\Apache Group\Apache2\modules\/li /ul /p p -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
[possible bug] -- Re: costin: fix reverted
On a related note, i just discovered some behavior that may be a bug. In my case, I have a request filter that buffers the output, so that I can gzip it and time the internal time. when a page hits an exception, it correctly forwards to my error page. but what ends up happening is the buffer isn't flushed, therefore the output has unwanted data. According to the spec, reset is supposed to be called on ServletOutputStream, but when I print out debug messages, I never see it call reset() or resetBuffer() in my output wrapper. It's unclear to me if this part of the spec applies to requests that are forwarded. the relevant section from the spec is below. 5.1 -- The reset method clears data in the buffer when the response is not committed. Headers and status codes set by the servlet prior to the reset call must be cleared as well. The resetBuffer method clears content in the buffer if the response is not committed without clearing the headers and status code. does someone know what the correct behavior should be? peter lin Costin Manolache wrote: Remy Maucherat wrote: Can you point me to the code doing this extra processing ? I'm a bit confused: - for jsps ( with flush-in-release ) that just can't work, since the flush is already done by the jsp page. - the comment ( or the message ) in forward is probably wrong. - my bigger question is when is the response not a facade ? My understanding is that facades are used all the time, so the second part of the if will never happen That code was already there before the facades. I don't think it is used anymore, but would leave it anyway in 4.1.x (it could be removed in 5). I already reverted the patch in 4.1.x - it's too dangerous for the stable tree. So you are saying that forward() used to do a flush, but it was changed when facades where added to just set the flag - to improve the error handling. Sounds consistent with the behavior we have now. Could you add a little comment ( or at least remove the debug message that says 'flushing' ) ? The new behavior ( no real flush ) seems correct. Costin I do see your point - if forward() flushes then the extra error processing is broken. That's another argument to not do the flush() in release() :-) And it does explain who is generating the stack trace. The error page and status report processing is in ErrorReport/DispatcherValve. That's where the stack trace is output unless the response has been committed (by flushing usually). I have a feeling we just need to clear the error flags after the jsp error page - I'm pretty sure the jsp error page was executed and the data is in the out buffer. Somehow the servlet error processing kicks in and overrides the jsp error page. Yes, that's likely the right explanation. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Coyote/Http11 under load
I'm using http11 on a busy site with more or less Tomcat 3.3 head (3.3.2-dev). I set up the connector with ServerSoTimeout=5000, SoTimeout=5000, maxThreads 100, maxSpare 50, minSpare 20. This yields severe performance problems after only a short time in service. On reverting back to http10, the performance goes back up and remains up. I checked with optimizeit and the threads with coyote look to be doing what they are supposed to. So, I started using ab to test the server with concurrent connections. The results I get with 20 concurrent connections: coyote/http11 4.2rq/sec, 63kb/sec http10 6.3rq/sec, 92kb/sec Any similar experiences or ideas? I'm continuing to investigate. Keith -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
I just tested - adding 'removeAttribute' in PageContextImpl after the error page solves the problem. The problem was pretty simple: - exception happens - jsp error page called and executed - normal servlet exception handling is now processing the exception - output is reset by the error handler. I'm pretty sure cleaning the exception after the jsp error page is the right thing to do. I don't know how will this deal with the case where an exception happens in the error page - but I can add code to verify the exception is the same ( i.e. remove only if the throwable is the same ) Costin Costin Manolache wrote: Remy Maucherat wrote: Can you point me to the code doing this extra processing ? I'm a bit confused: - for jsps ( with flush-in-release ) that just can't work, since the flush is already done by the jsp page. - the comment ( or the message ) in forward is probably wrong. - my bigger question is when is the response not a facade ? My understanding is that facades are used all the time, so the second part of the if will never happen That code was already there before the facades. I don't think it is used anymore, but would leave it anyway in 4.1.x (it could be removed in 5). I already reverted the patch in 4.1.x - it's too dangerous for the stable tree. So you are saying that forward() used to do a flush, but it was changed when facades where added to just set the flag - to improve the error handling. Sounds consistent with the behavior we have now. Could you add a little comment ( or at least remove the debug message that says 'flushing' ) ? The new behavior ( no real flush ) seems correct. Costin I do see your point - if forward() flushes then the extra error processing is broken. That's another argument to not do the flush() in release() :-) And it does explain who is generating the stack trace. The error page and status report processing is in ErrorReport/DispatcherValve. That's where the stack trace is output unless the response has been committed (by flushing usually). I have a feeling we just need to clear the error flags after the jsp error page - I'm pretty sure the jsp error page was executed and the data is in the out buffer. Somehow the servlet error processing kicks in and overrides the jsp error page. Yes, that's likely the right explanation. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14304] New: - RequestDispatcher.forward() problem in a Filter
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=14304. 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=14304 RequestDispatcher.forward() problem in a Filter Summary: RequestDispatcher.forward() problem in a Filter Product: Tomcat 4 Version: 4.1.14 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the following circumstances: 1. a Filter is assigned to a URL in a webapp 2. that Filter calls request.getRequestDispatcher(OTHER_RESOURCE).forward(request, response) 3. OTHER_RESOURCE is larger than the resource at the URL the OTHER_RESOURCE is truncated. Expected Behavior: OTHER_RESOURCE is returned to the HTTP client Actual Behavior: OTHER_RESOURCE is returned truncated to the HTTP client. I haven't confirmed this yet, but I think OTHER_RESOURCE is being truncated to the Content-Length of the requested resource. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14304] - RequestDispatcher.forward() problem in a Filter
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=14304. 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=14304 RequestDispatcher.forward() problem in a Filter --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 18:14 --- More information about this: I have tested this on 4.1.12 and 4.1.14, and the behavior is the same. On 4.1.14, I tested this with the following 4 statements: request.getRequestDispatcher(OTHER_RESOURCE).forward(request, response); request.getRequestDispatcher(OTHER_RESOURCE).include(request, response); getFilterConfig().getServletContext().getRequestDispatcher(OTHER_RESOURCE).forward(request, response); getFilterConfig().getServletContext().getRequestDispatcher(OTHER_RESOURCE).include(request, response); Each with the same actual behavior. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14308] New: - SSL fails with Netscape 4.77
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=14308. 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=14308 SSL fails with Netscape 4.77 Summary: SSL fails with Netscape 4.77 Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have JDK 1.4.1-b21 and Tomcat 4.1.12-LE-jdk14. I uncommented the SSL Coyote connector section in server.xml and created the keystore and certificate. When I connect with IE 6.0 (6.0.2800.1106.xpsp1.020828-1920 if you're keeping score!), I get javax.net.ssl.SSLPeerUnverifiedException as in bug 13358. But in Netscape 4.77 I get a popup message that says: The security library has encountered an improperly formatted DER-encoded message. and in the Tomcat launch window I have: Nov 6, 2002 6:57:41 PM org.apache.tomcat.util.log.CommonLogHandler log SEVERE: Handshake failed javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake (DashoA6275) at org.apache.tomcat.util.net.JSSESocketFactory.handshake (JSSESocketFact ory.java:290) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java :493) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadP ool.java:533) at java.lang.Thread.run(Thread.java:536) Nov 6, 2002 6:57:41 PM org.apache.tomcat.util.log.CommonLogHandler log SEVERE: Caught exception executing org.apache.tomcat.util.net.TcpWorkerThread@1c 1f5b2, terminating thread java.lang.NullPointerException at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java :512) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadP ool.java:533) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14302] - Jspc can't be used to compile the entire web application
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=14302. 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=14302 Jspc can't be used to compile the entire web application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 18:38 --- The web.xml generation feature will actually disappear (as it is broken). Instead, you'll have to generate the files in the webapp's work directory, and run Jasper normally. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: costin: fix reverted
Costin Manolache wrote: Remy Maucherat wrote: Can you point me to the code doing this extra processing ? I'm a bit confused: - for jsps ( with flush-in-release ) that just can't work, since the flush is already done by the jsp page. - the comment ( or the message ) in forward is probably wrong. - my bigger question is when is the response not a facade ? My understanding is that facades are used all the time, so the second part of the if will never happen That code was already there before the facades. I don't think it is used anymore, but would leave it anyway in 4.1.x (it could be removed in 5). I already reverted the patch in 4.1.x - it's too dangerous for the stable tree. So you are saying that forward() used to do a flush, but it was changed when facades where added to just set the flag - to improve the error handling. Sounds consistent with the behavior we have now. Yes, I think the error handling had problems before. Then I added some logic to the facades (bad) to fix that, and left the old code in the process. Could you add a little comment ( or at least remove the debug message that says 'flushing' ) ? The new behavior ( no real flush ) seems correct. Ok, I will. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14282] - mod_jk/ajp13 returns wrong response after bad chunk-encoding request
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=14282. 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=14282 mod_jk/ajp13 returns wrong response after bad chunk-encoding request --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 18:40 --- Just to clarify the behavior that we are seeing is that the request/response pairs are being mixed up. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime HttpJspBase.java JspRuntimeLibrary.java PageContextImpl.java
kinman 2002/11/06 10:47:15
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/runtime HttpJspBase.java
JspRuntimeLibrary.java PageContextImpl.java
Log:
- Move the code that creates a function for EL from the generated code
to o.a.j.runtime, so that it is secure.
Revision ChangesPath
1.119 +25 -29
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.118
retrieving revision 1.119
diff -u -r1.118 -r1.119
--- Generator.java4 Nov 2002 21:13:39 - 1.118
+++ Generator.java6 Nov 2002 18:47:13 - 1.119
-459,8 +459,10
out.print (servletClassName);
out.print ( extends );
out.println(pageInfo.getExtends());
+/* Supress until we also implement resolveFunction()
out.printil(implements javax.servlet.jsp.el.FunctionMapper, );
- out.printin( org.apache.jasper.runtime.JspSourceDependent);
+*/
+ out.printin(implements org.apache.jasper.runtime.JspSourceDependent);
if (!pageInfo.isThreadSafe()) {
out.println(,);
out.printin( SingleThreadModel);
-578,15 +580,13
}
}
-out.printil(private static java.util.HashMap _jspx_fnmap = null;);
+out.printil(private static
org.apache.jasper.runtime.ProtectedFunctionMapper _jspx_fnmap;);
if( fnPresent ) {
iter = taglibs.keySet().iterator();
out.println();
out.printil(static {);
out.pushIndent();
-out.printil(_jspx_fnmap = new java.util.HashMap(););
-out.printil( try { );
-out.pushIndent();
+ out.printil(_jspx_fnmap =
org.apache.jasper.runtime.ProtectedFunctionMapper.getInstance(););
while( iter.hasNext() ) {
String key = (String)iter.next();
TagLibraryInfo tli = (TagLibraryInfo)taglibs.get( key );
-594,14 +594,13
String fnPrefix = tli.getPrefixString();
out.printil( // Functions for + tli.getShortName() );
for( int i = 0; i fnInfo.length; i++ ) {
-String fnName = fnPrefix + : + fnInfo[i].getName();
-String fnSignature = fnInfo[i].getFunctionSignature();
-out.printin(_jspx_fnmap.put();
-out.print(quote(fnName));
+ out.printin(_jspx_fnmap.mapFunction();
+ out.print(quote(fnPrefix));
out.print(, );
-out.print(fnInfo[i].getFunctionClass() +
-.class.getDeclaredMethod();
-
+ out.print(quote(fnInfo[i].getName()));
+out.print(, );
+out.print(fnInfo[i].getFunctionClass() + .class, );
+String fnSignature = fnInfo[i].getFunctionSignature();
JspUtil.FunctionSignature functionSignature =
new JspUtil.FunctionSignature( fnSignature,
tli.getShortName(), err, ctxt.getClassLoader() );
-620,19 +619,10
} else {
out.print(null);
}
-out.println()););
+out.println(););
}
}
-out.popIndent();
-out.printil( } );
-out.printil( catch( NoSuchMethodException e ) { );
-out.pushIndent();
-out.printil( throw new RuntimeException( \ +
-Invalid function mapping - no such method: \ + +
-e.getMessage()); );
-out.popIndent();
-out.printil( } );
-out.popIndent();
+ out.popIndent();
out.printil(});
out.println();
}
-644,6 +634,7
private void generateFunctionMapper()
throws JasperException
{
+/* XX suppress until EL moves out of JSTL
out.printil( public java.lang.reflect.Method resolveFunction( );
out.printil( String prefix, String localName ) );
out.printil( { );
-653,6 +644,7
out.popIndent();
out.printil( } );
out.println();
+*/
}
-1067,9 +1059,11
pageContext.findAttribute(\ + name + \), \
+ property + \,
+ quote(value.getValue()) + ,
-+ pageContext,
+
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime ProtectedFunctionMapper.java
kinman 2002/11/06 10:48:18
Added: jasper2/src/share/org/apache/jasper/runtime
ProtectedFunctionMapper.java
Log:
Revision ChangesPath
1.1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ProtectedFunctionMapper.java
Index: ProtectedFunctionMapper.java
===
/*
* $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/ProtectedFunctionMapper.java,v
1.1 2002/11/06 18:48:17 kinman Exp $
* $Revision: 1.1 $
* $Date: 2002/11/06 18:48:17 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper.runtime;
import org.apache.jasper.logging.Logger;
import java.util.HashMap;
import java.security.AccessController;
import java.security.PrivilegedAction;
/**
* Maps EL functions to their Java method counterparts. Keeps the
* actual Method objects protected so that JSP pages can't indirectly
* do reflection.
*
* @author Mark Roth
* @author Kin-man Chung
*/
public final class ProtectedFunctionMapper {
/** For tracing of error messages */
private static Logger.Helper loghelper = new Logger.Helper(JASPER_LOG,
ProtectedFunctionMapper);
/**
* Maps prefix:name to java.lang.Method objects. Lazily created.
*/
private HashMap fnmap = new java.util.HashMap();
/**
* Constructor has protected access.
*/
private ProtectedFunctionMapper() {
}
/**
* Generated Servlet and Tag Handler implementations call this
* method to retrieve an instance of the ProtectedFunctionMapper.
* This is necessary since generated code does not have access to
* create instances of classes in this package.
*
* @return A new protected function mapper.
*/
public static ProtectedFunctionMapper getInstance() {
if (System.getSecurityManager() != null) {
return (ProtectedFunctionMapper)AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return new ProtectedFunctionMapper();
}
} );
DO NOT REPLY [Bug 14275] - Problems creating DataSource
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=14275. 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=14275 Problems creating DataSource --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 18:51 --- On further examining the problem, I found the driverClassName is not initialized in method createDataSource() in the class BasicDataSource. I do a JNDI lookup of jdbc\Questions in the context java:comp/env. While the call succeeds, the DriverName is not initialized when the DataSource is returned on the JNDI lookup call. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14275] - Problems creating DataSource
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=14275. 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=14275 Problems creating DataSource --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 18:59 --- No, this should be part of the Context element. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14309] New: - Memory Leak
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=14309. 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=14309 Memory Leak Summary: Memory Leak Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm encountering what looks like a memory leak in tomcat 4.1.12. I do not ecounter this same problem with the same code-line and configuration in tomcat 4.0.6. I running multiple requests against an HttpServlet that accesses an in memory cache of data and writes to a mysql database. As I run multiple requests the memory fills, the application begins to slow, and eventially I get an OutOfMemory error. I've tried getting diagnostics by running the tomcat 4.1.12 server inside JProfiler. The culprit seems to be a build up of byte arrays. Unfortunately, we don't have a machine powerful enough to get a heap profile in a reasonable amount of time so I do not know what object or objects are holding references to these byte arrays. In either server (4.0.6 or 4.1.12) I'm using the CoyoteHttp connector and the MySQL Java Driver. This problem appears to be in catalina core code and not in these modules. Thanks for your time. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
remm2002/11/06 11:26:31 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: - The compile switch should be -compile to be consistent (or we should switch everything to the GNU standard). Revision ChangesPath 1.17 +4 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java Index: JspC.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- JspC.java 21 Oct 2002 18:44:00 - 1.16 +++ JspC.java 6 Nov 2002 19:26:31 - 1.17 -122,7 +122,7 public static final String SWITCH_PACKAGE_NAME = -p; public static final String SWITCH_CLASS_NAME = -c; public static final String SWITCH_FULL_STOP = --; -public static final String SWITCH_COMPILE = --compile; +public static final String SWITCH_COMPILE = -compile; public static final String SWITCH_URI_BASE = -uribase; public static final String SWITCH_URI_ROOT = -uriroot; public static final String SWITCH_FILE_WEBAPP = -webapp; -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14309] - Memory Leak
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=14309. 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=14309 Memory Leak [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 19:31 --- You'll have to give some information about what would be causing this if you want that bug to stay open. I do not experience any memory leak in my setup. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14275] - Problems creating DataSource
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=14275. 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=14275 Problems creating DataSource [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 19:48 --- I am seeing the same problem in bug 14261. Adding the link does not resolve the problem -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14275] - Problems creating DataSource
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=14275. 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=14275 Problems creating DataSource [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 19:53 --- Ah, yes, this is a duplicate. *** This bug has been marked as a duplicate of 14261 *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.
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=14261. 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=14261 JNDI data source not configured correctly. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 19:53 --- *** Bug 14275 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.
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=14261. 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=14261 JNDI data source not configured correctly. --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:16 --- I see no ResourceLink definition for your context. I don't see how this can work. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14302] - Jspc can't be used to compile the entire web application
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=14302. 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=14302 Jspc can't be used to compile the entire web application --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:17 --- I agree with others that commented on the proposal posted on Tomcat-Dev that removing the web.xml generation feature would be a bad idea. Being able to generate a standalone package for all JSP pages plus the needed mappings is a very useful feature, so if it's btroken, please fix it instead of removing it. I may lend a hand if it's a matter of no one having the time, just let me know. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14302] - Jspc can't be used to compile the entire web application
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=14302. 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=14302 Jspc can't be used to compile the entire web application --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:23 --- I do not agree, as the generated code may not compatible between versions of Jasper, or even between minor Tomcat revisions. You *have to* regenerate/recompile the JSPs when deploying a webapp. jspc is too complex, and will be dramatically simplified if the voting on my upcoming proposal goes my way. Otherwise, it will stay in the current situation, where jspc is broken because it is too complex and few people care about testing it. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.
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=14261. 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=14261 JNDI data source not configured correctly. --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:27 --- Created an attachment (id=3761) updated server.xml with resource link -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.
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=14261. 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=14261 JNDI data source not configured correctly. --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:29 --- I just uploaded a new server.xml file that shows my attempt at using a resource link. I have tried several different names in the global resource. It must be finding the basics, as I get a message from the BasicDataSource. The parameters it is sent just appear to be the ones for the resource-ref. Can somebody give me an example of a working data source? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler PageDataImpl.java
luehe 2002/11/06 12:58:10
Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java
Log:
In XML view, always create page directive with 'contentType' and
'pageDirective' attributes, and append it right after the jsp:root
start element, and suppress the 'contentType' and 'pageDirective'
attributes from any subsequent page directive
Revision ChangesPath
1.16 +35 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
Index: PageDataImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- PageDataImpl.java 6 Nov 2002 20:14:19 - 1.15
+++ PageDataImpl.java 6 Nov 2002 20:58:10 - 1.16
-405,8 +405,11
if (attrs != null) {
printAttributes(attrs);
}
- if (body != null || text != null) {
+ if (tag.equals(JSP_ROOT) || body != null || text != null) {
buf.append(\n);
+ if (tag.equals(JSP_ROOT)) {
+ appendPageDirective();
+ }
if (body != null) {
body.visit(this);
} else {
-441,8 +444,15
int len = attrs.getLength();
for (int i=0; ilen; i++) {
String attrName = attrs.getQName(i);
- if (import.equals(attrName)) {
- // Ignore page directive's import attribute for now
+ if (import.equals(attrName) || contentType.equals(attrName)
+ || pageEncoding.equals(attrName)) {
+ /*
+ * Page directive's 'import' attribute is considered
+ * further down, and its 'pageEncoding' and 'contentType'
+ * attributes are ignored, since we've already created
+ * a new page directive containing just these two
+ * attributes
+ */
continue;
}
String value = attrs.getValue(i);
-479,6 +489,7
appendCDATA(text);
buf.append(JSP_TEXT_END);
+ buf.append(\n);
} else {
appendCDATA(text);
}
-537,7 +548,24
* Appends XML prolog with encoding declaration.
*/
private void appendXmlProlog() {
- buf.append(?xml version=\1.0\ encoding=\UTF-8\ ?);
+ buf.append(?xml version=\1.0\ encoding=\UTF-8\ ?\n);
+ }
+
+ /*
+ * Appends a page directive with 'pageEncoding' and 'contentType'
+ * attributes whose values are derived from pageInfo.
+ */
+ private void appendPageDirective() {
+ buf.append().append(JSP_PAGE_DIRECTIVE);
+ buf.append(\n);
+
+ // append jsp:id
+ buf.append( ).append(jsp:id).append(=\);
+ buf.append(jspId++).append(\\n);
+ buf.append( ).append(pageEncoding).append(=\UTF-8\\n);
+ buf.append( ).append(contentType).append(=\);
+ buf.append(pageInfo.getContentType()).append(\\n);
+ buf.append(/\n);
}
}
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14302] - Jspc can't be used to compile the entire web application
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=14302. 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=14302 Jspc can't be used to compile the entire web application --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 21:19 --- Recompiling for a new version of Tomcat is reasonable. But I may also want to compile a JSP app and deploy on a different container. I can do that today (or I could with TC 4.0.4) as long as I include the matching jasper-runtime.jar file. Anyway, if you're going to make a formal proposal about this change, I guess we better discuss it on the list instead of through the bug database ;-) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
lots of tomcat processes (Re: [PATCH][JK] Ajp13Processor connection leak prevention)
On Wed, Nov 06, 2002 at 12:10:09AM -0800, Daniel Rall wrote: Adjusted Ajp13Processor's run() method to protect against unexpected unchecked excpetions, preventing the possibility of a leak in Ajp13Connector's request processor pool. [ patch elided ] Would this cause hanging tomcat instances? I get a multiplying lot of tomcat processes after a while. How many should there be? Just one? i.e., is a 'request processor' a java thread or an OS process? Using apache1.3.27, mod_jk1.2.0, tomcat 4.0.4 (soon to be 4.0.6) on Solaris8. Regards, Matt -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14273] - Unable to invoke a fragment within a tag in a tag file
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=14273. 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=14273 Unable to invoke a fragment within a tag in a tag file [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 22:02 --- Fixed. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14230] - JSP errorPage mechanism is failing in HEAD build of Tomcat 5
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=14230. 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=14230 JSP errorPage mechanism is failing in HEAD build of Tomcat 5 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-06 22:16 --- Reverting costin's flush-in-release patch fixes this problem -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
