Re: [4.1.17] [VOTE] Stability rating
As a user, that use tomcat 4.1.17 since it came outi say stable. [X] STABLE Reason why: 1. We need a new official stable release, latest is 4.1.12 ! 2. Tomcat processes since i install it, over 20 requests 3. all my private patches work with him - static encoding of jsp texts, like resin - AllowLinking restricting to docbase, webapp base - removed synchronized taglib pool access 4. bugs discovered in past release are corrected, main reason for a new official release. cu Torsten Fohrer On Sunday 15 December 2002 16:36, you wrote: ballot [ ] Alpha [ ] Beta [ ] Stable (General Availability) Reason (optional): /ballot Thanks for voting and for testing 4.1.17 Alpha! Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
hgomez 2002/12/16 00:54:56
Modified:jk/native/apache-1.3 mod_jk.c
Log:
Fix ifdef/idef
Revision ChangesPath
1.33 +4 -4 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- mod_jk.c 11 Dec 2002 10:40:38 - 1.32
+++ mod_jk.c 16 Dec 2002 08:54:55 - 1.33
@@ -735,7 +735,7 @@
/* we need an absolut path */
conf-worker_file = ap_server_root_relative(cmd-pool,worker_file);
-#idef CHROOTED_APACHE
+#ifdef CHROOTED_APACHE
ap_server_strip_chroot(conf-worker_file,0);
#endif
@@ -768,7 +768,7 @@
/* we need an absolut path */
conf-log_file = ap_server_root_relative(cmd-pool,log_file);
-#idef CHROOTED_APACHE
+#ifdef CHROOTED_APACHE
ap_server_strip_chroot(conf-log_file,0);
#endif
@@ -1752,7 +1752,7 @@
/* Open up log file */
if(conf-log_file conf-log_level = 0) {
if(!jk_open_file_logger((conf-log), conf-log_file, conf-log_level)) {
-#idef CHROOTED_APACHE
+#ifdef CHROOTED_APACHE
conf-log = main_log;
#else
conf-log = NULL;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.in
hgomez 2002/12/16 00:56:15
Modified:jk/native/apache-1.3 Makefile.in
Log:
Correct makefile.
Revision ChangesPath
1.9 +1 -0 jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.in,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Makefile.in 11 Dec 2002 10:38:51 - 1.8
+++ Makefile.in 16 Dec 2002 08:56:15 - 1.9
@@ -22,6 +22,7 @@
APACHE_FILES = Makefile.tmpl Makefile.libdir libjk.module
+JK=../common/
JK_INCL=-DUSE_APACHE_MD5 -I ${top_srcdir}/common
JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources ProxyDirContext.java
remm2002/12/16 01:04:22
Modified:catalina/src/share/org/apache/naming/resources
ProxyDirContext.java
Log:
- Should fix cache invalidation when creating subcontexts and
modify atributes.
- Fix WebDAV (bug 15378).
Revision ChangesPath
1.4 +26 -8
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java
Index: ProxyDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ProxyDirContext.java 10 Oct 2002 07:41:27 - 1.3
+++ ProxyDirContext.java 16 Dec 2002 09:04:22 - 1.4
@@ -594,7 +594,9 @@
*/
public Context createSubcontext(Name name)
throws NamingException {
-return dirContext.createSubcontext(parseName(name));
+Context context = dirContext.createSubcontext(parseName(name));
+cacheUnload(name.toString());
+return context;
}
@@ -610,7 +612,9 @@
*/
public Context createSubcontext(String name)
throws NamingException {
-return dirContext.createSubcontext(parseName(name));
+Context context = dirContext.createSubcontext(parseName(name));
+cacheUnload(name.toString());
+return context;
}
@@ -905,6 +909,7 @@
public void modifyAttributes(Name name, int mod_op, Attributes attrs)
throws NamingException {
dirContext.modifyAttributes(parseName(name), mod_op, attrs);
+cacheUnload(name.toString());
}
@@ -923,6 +928,7 @@
public void modifyAttributes(String name, int mod_op, Attributes attrs)
throws NamingException {
dirContext.modifyAttributes(parseName(name), mod_op, attrs);
+cacheUnload(name);
}
@@ -943,6 +949,7 @@
public void modifyAttributes(Name name, ModificationItem[] mods)
throws NamingException {
dirContext.modifyAttributes(parseName(name), mods);
+cacheUnload(name.toString());
}
@@ -960,6 +967,7 @@
public void modifyAttributes(String name, ModificationItem[] mods)
throws NamingException {
dirContext.modifyAttributes(parseName(name), mods);
+cacheUnload(name);
}
@@ -981,6 +989,7 @@
public void bind(Name name, Object obj, Attributes attrs)
throws NamingException {
dirContext.bind(parseName(name), obj, attrs);
+cacheUnload(name.toString());
}
@@ -998,6 +1007,7 @@
public void bind(String name, Object obj, Attributes attrs)
throws NamingException {
dirContext.bind(parseName(name), obj, attrs);
+cacheUnload(name);
}
@@ -1022,6 +1032,7 @@
public void rebind(Name name, Object obj, Attributes attrs)
throws NamingException {
dirContext.rebind(parseName(name), obj, attrs);
+cacheUnload(name.toString());
}
@@ -1039,6 +1050,7 @@
public void rebind(String name, Object obj, Attributes attrs)
throws NamingException {
dirContext.rebind(parseName(name), obj, attrs);
+cacheUnload(name);
}
@@ -1061,7 +1073,10 @@
*/
public DirContext createSubcontext(Name name, Attributes attrs)
throws NamingException {
-return dirContext.createSubcontext(parseName(name), attrs);
+DirContext context =
+dirContext.createSubcontext(parseName(name), attrs);
+cacheUnload(name.toString());
+return context;
}
@@ -1078,7 +1093,10 @@
*/
public DirContext createSubcontext(String name, Attributes attrs)
throws NamingException {
-return dirContext.createSubcontext(parseName(name), attrs);
+DirContext context =
+dirContext.createSubcontext(parseName(name), attrs);
+cacheUnload(name);
+return context;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] mod_jk - chroot and user issues
Kurt Miller wrote: Ok, it's in jk CVS and you'll just have to add -DCHROOTED_APACHE to check it. Thanks to give some feedback. Thank you for commiting the patches. :-) I tested them and noted one problem with apache-1.3/Makefile.in. It includes ../common/list.mk which requires the JK=../common line to be there. Fixed thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves PersistentValve.java
jfclere 2002/12/16 01:20:10 Modified:catalina/src/share/org/apache/catalina/valves PersistentValve.java Log: Invoke the next valve instead invoking the context... Revision ChangesPath 1.2 +5 -6 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/PersistentValve.java Index: PersistentValve.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/PersistentValve.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PersistentValve.java 9 Dec 2002 15:57:43 - 1.1 +++ PersistentValve.java 16 Dec 2002 09:20:10 - 1.2 @@ -203,9 +203,8 @@ } log(sessionId: + sessionId); -// Ask this Context to process this request -context.invoke(request, response); -// ? valveContext.invokeNext(request, response); +// Ask the next valve to process the request. +valveContext.invokeNext(request, response); // Read the sessionid after the response. // HttpSession hsess = hreq.getSession(false); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk to be tagged tomorrow
If nobody object, I'll tag JK 1.2.2 later todaty since it fix a major problem with content-type and it works now with mod_deflate in Apache 2.0. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache+Tomcat+modjk with ~/public_html
tomcat-dev is for development/bugfixing kind of issues. For help on configuration, please use the tomcat user list. Martin -Original Message- From: Kevin Conaway [mailto:[EMAIL PROTECTED]] Sent: 15 December 2002 17:33 To: [EMAIL PROTECTED] Subject: Apache+Tomcat+modjk with ~/public_html Is it possible to setup Apache/Tomcat/mod_jk to let users have servlets in the ~/public_html directory? I have tomcat setup so that if you call http://localhost:8080/~user it works, but it doesnt work through the main Apache server and mod_jk. Any thoughts? Kevin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Session de-serialization problem (with patch)
Hi,
during work on session serialization my colleagues run into
a problem with the startup order of the session manager vs
listeners/filters.
During startup the session manager is started before the
listeners and filters. This implies that objects that
depend on parts of the application can not be properly
deserialized. (Apparently, a re-write to remove such
dependencies is not feasible in our case.)
Further this behaviour is inconsistent with the reload
behaviour, which was previously changed due to
http://issues.apache.org/bugzilla/show_bug.cgi?id=3733.
We have patched this behaviour (see attachment) to start
listeners/filters immediately _befor_ the session manager.
This patch solves our problem and does not seem to cause any
new issues with our application. However, due to the
triviality of the patch, we have not made a thorough
examination of the workings of o.a.c.core.StandardContext.
Also, the patch is focused on one specific issue. It does
not (unless by coincidence) ensure consistency in the
reload/start behaviours.
The patch is against 4.1.16, since 4.1.17 was released after
the patch was written.
Sincerely,
Michael Eriksson
--- StandardContext.java2002-12-16 11:31:45.0 +0100
+++
+jakarta-tomcat-4.1.16-src/catalina/src/share/org/apache/catalina/core/StandardContext.java
+ 2002-12-16 11:33:47.0 +0100
@@ -3566,15 +3566,7 @@
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(START_EVENT, null);
-// Configure and call application event listeners and filters
-if (!listenerStart())
-ok = false;
-if (ok) {
-if (!filterStart())
-ok = false;
-}
-
-if (ok (manager != null) (manager instanceof Lifecycle))
+if ((manager != null) (manager instanceof Lifecycle))
((Lifecycle) manager).start();
} finally {
@@ -3601,6 +3593,16 @@
postWelcomeFiles();
}
+// Configure and call application event listeners and filters
+if (ok) {
+if (!listenerStart())
+ok = false;
+}
+if (ok) {
+if (!filterStart())
+ok = false;
+}
+
// Load and initialize all load on startup servlets
if (ok)
loadOnStartup(findChildren());
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15391] New: - Jasper generates a translation error if the body of jsp:params is supplied though jsp:body
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=15391. 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=15391 Jasper generates a translation error if the body of jsp:params is supplied though jsp:body Summary: Jasper generates a translation error if the body of jsp:params is supplied though jsp:body Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Given the following segment - jsp:plugin code=foo.class codebase=/ jsp:params jsp:body jsp:param name=param1 value=param2 / /jsp:body /jsp:params /jsp:plugin -- A translation error is incorrectly generated with the following message. Expected param tag with name and value attributes Section 5.11 of the 2.0 PFD states: It is also legal to use the jsp:body standard action to supply bodies to standard actions, for *any* standard action that accepts a body. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15392] New: - web.xml
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=15392. 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=15392 web.xml Summary: web.xml Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] web.xml is too difficult to set. Originally I used tomcat 3.x. I don't need to set any web.xml. I only need to copy *.class. In tomcat 4.x, without specifying web.xml the servlets are not guaranteed portable. I tried hard to set web.xml but still failed to execute the servlet. Finally I have no choice but to use tomcat 3.3, which I don't need to set web.xml. If you want developers to continue using tomcat, don't make deployment such difficult. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_trend.pl
glenn 2002/12/16 05:55:46
Modified:jk/tools/reports tomcat_trend.pl
Log:
Update script to support changed logging of aborted requests
Revision ChangesPath
1.2 +4 -4 jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl
Index: tomcat_trend.pl
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- tomcat_trend.pl 1 Nov 2002 17:41:04 - 1.1
+++ tomcat_trend.pl 16 Dec 2002 13:55:46 - 1.2
@@ -231,7 +231,7 @@
if( $line =~ /jk_tcp_socket_recvfull failed/ ) {
$Global{tomcat_full}++;
$Interval{tomcat_full}++;
-} elsif( $line =~ /ajp_process_callback - write failed/ ) {
+} elsif( $line =~ /(ajp_process_callback - write failed|ERROR sending
data to client. Connection aborted or network problems)/ ) {
$Global{client_gone}++;
$Interval{client_gone}++;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk to be tagged tomorrow
Henri Gomez wrote: If nobody object, I'll tag JK 1.2.2 later todaty since it fix a major problem with content-type and it works now with mod_deflate in Apache 2.0. I noticed that there is no release notes or changes file either in CVS or in the distributions. Could this please be added. It would sure make things easier for those upgrading to quickly identify what changes have been made or what bugs have been fixed. Thanks, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Applets in SHARED folder
Hallo there, According the 'Tomcat docuentation' http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/deployment.html, classes shared accross two different web applications are stored in %CATALINA_BASE%\shared folder. These classes are accessible from my application. But when I referred to the applets stored in this folder from my JSPs, the browser showed 'class not found' error. I've used the attribute CODEBASE=. in the APPLET tag. Instead, what should it be? Many thanks in anticipation.
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources ProxyDirContext.java
remm2002/12/16 06:19:07
Modified:catalina/src/share/org/apache/naming/resources
ProxyDirContext.java
Log:
- Remove useless toString.
Revision ChangesPath
1.5 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java
Index: ProxyDirContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ProxyDirContext.java 16 Dec 2002 09:04:22 - 1.4
+++ ProxyDirContext.java 16 Dec 2002 14:19:07 - 1.5
@@ -613,7 +613,7 @@
public Context createSubcontext(String name)
throws NamingException {
Context context = dirContext.createSubcontext(parseName(name));
-cacheUnload(name.toString());
+cacheUnload(name);
return context;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Applets in %CATALINA_BASE%\SHARED folder is Unaccessable
Hallo there, According the 'Tomcat docuentation' http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/deployment.html, classes shared accross two different web applications are stored in %CATALINA_BASE%\shared folder. These classes are accessible from my application. But when I referred to the applets stored in this folder from my JSPs, the browser showed 'class not found' error. I've used the attribute CODEBASE=. in the APPLET tag. Instead, what should it be? Many thanks in anticipation.
Re: Building Tomcat5 (JavaServices)
Radim Kubacki wrote: Hello, I am trying to build Tomcat-5 but during execution of 'ant download' it fails to get JavaService from http://www.alexandriasc.com/software/JavaService/JavaService-bin-1.2.0.zip. The site seems to be down. Indeed. Maybe it's time to try to switch to Mladen's code. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15400] New: - doTrace implementation cannot handle multiple header names
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=15400. 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=15400 doTrace implementation cannot handle multiple header names Summary: doTrace implementation cannot handle multiple header names Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When sending a request with multiple defined headers like: Some-Header: first Some-Header: second Some-Header: third, fourth Only the first header line is echoed back in the response. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2002/12/16 06:41:39
Modified:.build.xml
Log:
- Remove JavaService from the download target.
Revision ChangesPath
1.60 +2 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- build.xml 5 Dec 2002 12:01:32 - 1.59
+++ build.xml 16 Dec 2002 14:41:39 - 1.60
@@ -864,11 +864,13 @@
param name=destfile value=${commons-modeler.jar}/
/antcall
+!--
antcall target=downloadzip
param name=sourcefile value=${javaservice.loc}/
param name=destfile value=${javaservice.exe}/
param name=destdir value=${javaservice.home}/
/antcall
+--
antcall target=downloadgz
param name=sourcefile value=${jmx.loc}/
param name=destfile value=${jmx.jar}/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Building Tomcat5 (JavaServices)
Try the latest built code from http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5. I am using it successfully. -Original Message- From: Radim Kubacki [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 2:24 PM To: [EMAIL PROTECTED] Subject: Building Tomcat5 (JavaServices) Hello, I am trying to build Tomcat-5 but during execution of 'ant download' it fails to get JavaService from http://www.alexandriasc.com/software/JavaService/JavaService-bin-1.2.0.zip. The site seems to be down. Any help? Radim
Re: mod_jk to be tagged tomorrow
Glenn Nielsen wrote: Henri Gomez wrote: If nobody object, I'll tag JK 1.2.2 later todaty since it fix a major problem with content-type and it works now with mod_deflate in Apache 2.0. I noticed that there is no release notes or changes file either in CVS or in the distributions. Could this please be added. It would sure make things easier for those upgrading to quickly identify what changes have been made or what bugs have been fixed. There is a CHANGES.txt : JAKARTA TOMCAT CONNECTORS (JK) CHANGELOG: -*-text-*- Last modified at [$Date: 2002/12/09 13:28:55 $] Changes with JK 1.2.2: * jk set correctly the content-type in Apache 2.0, making it ready to works with mod_deflate and AddOutputFilterByType [hgomez] * jk will check result of get_endpoint and handle a failure. This call can fail if the allocation for the endpoint fails because of low memory conditions causing a dereference of NULL when we try and access the endpoint [mmanders] Changes with JK 1.2.1: * Don't send initial chunk for chunked encoding, fix #14282 [costin] * Add perl scripts for analyzing mod_jk logs and generating graphs/reports [glenn] * Make JK honor the CanonicalHost directive. [hgomez] * Log cleanup [costin] * Fix typos in jk xdocs/docs [hgomez] * Add JkRequestLogFormat to Apache 2.0 [hgomez] * Final patches to make JK iSeries compliant [hgomez] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
hgomez 2002/12/16 06:50:50 Modified:jk/native CHANGES.txt Log: Update Changelog ;-) Revision ChangesPath 1.6 +4 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- CHANGES.txt 9 Dec 2002 13:28:55 - 1.5 +++ CHANGES.txt 16 Dec 2002 14:50:50 - 1.6 @@ -2,6 +2,9 @@ Last modified at [$Date$] Changes with JK 1.2.2: +* tomcat_trend.pl updated script to support changed logging of + aborted requests + [glenn] * jk set correctly the content-type in Apache 2.0, making it ready to works with mod_deflate and AddOutputFilterByType [hgomez] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL][TOMCAT5] plugins directory
Costin Manolache wrote: There are several things we discussed last week, and few seem to have enough consensus. This is an initial proposal - I expect it to change quite a bit. I think it's very important and will affect almost everyone - so please send at least a numeric vote, and if possible comments or sugestions. If we do agree - we'll need to also do the work, so please indicate if you are willing to write at least some of the code :-) I will have time to work on the code :-) We seem to agree on having a more modular tomcat, where different components can be added ( by a script, manually, etc ) or removed easily. The mechanisms of adding/removing components is a separate issue that can be decided in a separate thread. My initial proposal is: 1. Add a new plugins/ directory. All tomcat components will eventually be migrated from server/lib and common/lib into one of the plugins subdirectories. ( it can be called modules/ or something else ). +1. For security reason, we should have a way to protect the module (using Remy's catalina.property mechanism). We should have trusted components as well as untrusted. What about Xerces? It's a kind of pluging but it is also and endorsed lib. We need to keep the endorsed folder/mechanism 2. The profile will consist of a list of plugins that are enabled. This can be configured using an XML file or using an API ( details of this are a separate item ). Tomcat will _not_ load all plugins automatically ( like in webapps/ or tomcat33 modules ), you'll have to explicitely add each of them. 3. The format of a plugin. We should support at least .war ( tomcat already have all the code ). I don't see a need for a format that is very different, but we (may) need to add an additional XML file. We should also be able to support a .jar format ( maybe with an additional .xml descriptor in META-INF ) as well as .xml descriptors in the plugin directory. I recommend keeping war file for web applications, and use jar as the standard module/component. In module implements a common interface for identifying themself, I recommend we don't add another xml file but use introspection to discover the module functionalities etc. 4. Each plugin will define one or several MBeans. Regular JMX API will be used to add/remove plugins, and the normal JMX notifications will be used to detect and plug the plugins into the server. It should be possible for an application embeding tomcat to add MBeans from any other locations. +1. We will have to document that parts to avoid confusion. 5. The XML should be similar with the MLET format ( with some extensions if we need to ). I don't see any need for something more complicated or different. 6. Each classloader in tomcat will be ( or have ) a MBean. Different plugins can define new classloaders ( by using an mbean declaration ) or add jars to existing classloaders ( in particular the server, common and individual webapp loaders ). We should define a contract between Tomcat and the plugins which force the plugin-defined classloader to be secure (at least do the package protection check). Maybe plugin-defined classloader should extend some catalina classes in order to fullfill the contract. If a component doesn't have an MBean, we should have a mechanism to generate, using introspection, that MBean. We doesn't need that soon, but we you keep the idea in mind... 7. Tomcat startup will be modified to start with only JMX and whatever minimal code we need to load plugins. The common and server loaders will be defined by the plugins. All classloader configuration will be consolidated. The ant startup will also be changed to use the same xml format ( mbean, etc ). 8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. Questions: Are we considering a Valve as a module/component? And it is not clear in your proposal if we are keeping the server.xml file. I recommend we keep it just to avoid confusion (IMBW...we should have a pool to determine if users like server.xml :-) ). -- Jeanfrancois Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15403] New: - Embedded Tomcat can't compile JSP .java file due to extra /
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=15403. 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=15403 Embedded Tomcat can't compile JSP .java file due to extra / Summary: Embedded Tomcat can't compile JSP .java file due to extra / Product: Tomcat 4 Version: 4.1.16 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I started with the source code that appeared in the OnJava article http://www.onjava.com/pub/a/onjava/2002/04/03/tomcat.html. I am trying to serve a webapp that works fine when I run Tomcat standalone. When I start the embedded Tomcat, it serves HTML pages just fine. When trying to serve JSPs however, the servlet code is generated, but the compile fails (log at the end of this message, my changes to the source follow that). I suspect that it fails because Ant can't resolve any java files in the work directory, since the compile fails with: Error compiling file: C:\Program Files\Apache Group\Tomcat 4.1\work\_\localhost\texas\/index_jsp.java The log shows: Creating engine Creating host 'localhost' with appBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps' Creating context '' with docBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps/ROOT' Creating context '/examples' with docBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps/examples/jsp' Creating context '/tomcat-docs' with docBase 'C:/Program Files/Apache Group/Tomcat 4.1/webapps/tomcat-docs' Adding engine (org.apache.catalina.core.StandardEngine/1.0) Creating connector for address='ALL' port='80' secure='false' Adding connector (org.apache.coyote.tomcat4.CoyoteConnector2/1.0) Starting embedded server Apache Tomcat/4.1.12 StandardContext[]: Starting StandardContext[]: Processing start(), current available=false StandardContext[]: Configuring default Resources StandardContext[]: Configuring non-privileged default Loader StandardContext[]: Configuring default Manager StandardContext[]: Processing standard container startup WebappLoader[]: Deploying class repositories to work directory C:\Program Files\Apache Group\Tomcat 4.1\work\_\localhost\_ ContextConfig[]: ContextConfig: Processing START StandardContext[]: Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' StandardContext[]: Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' ContextConfig[]: Accumulating TLD resource paths ContextConfig[]: Scanning taglib elements in web.xml ContextConfig[]: Scanning TLDs in /WEB-INF subdirectory ContextConfig[]: Scanning JARs in /WEB-INF/lib subdirectory ContextConfig[]: Added certificates - request attribute Valve ContextConfig[]: Pipline Configuration: ContextConfig[]: org.apache.catalina.valves.CertificatesValve/1.0 ContextConfig[]: org.apache.catalina.core.StandardContextValve/1.0 ContextConfig[]: == NamingContextListener[/null/localhost]: Creating JNDI naming context NamingContextListener[/null/localhost]: Resource parameters for UserTransaction = null StandardManager[]: Seeding random number generator class java.security.SecureRandom StandardManager[]: Seeding of random number generator has been completed StandardContext[]: Posting standard context attributes StandardContext[]: Configuring application event listeners StandardContext[]: Sending application start events StandardContext[]: Starting filters StandardWrapper[:default]: Loading container servlet default StandardWrapper[:invoker]: Loading container servlet invoker StandardContext[]: Starting completed 0 [main] INFO http11.Http11Protocol - Initializing Coyote HTTP/1.1 on port 80 61 [main] INFO http11.Http11Protocol - Starting Coyote HTTP/1.1 on port 80 StandardHost[localhost]: Installing web application at context path /texas from URL file://C:/Program Files/Apache Group/Tomcat 4.1/webapps/texas WebappLoader[/texas]: Deploying class repositories to work directory C:\Program Files\Apache Group\Tomcat 4.1\work\_\localhost\texas WebappLoader[/texas]: Deploy class files /WEB-INF/classes to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\classes WebappLoader[/texas]: Deploy JAR /WEB-INF/lib/dom4j.jar to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\lib\dom4j.jar WebappLoader[/texas]: Deploy JAR /WEB-INF/lib/filetags.jar to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\lib\filetags.jar WebappLoader[/texas]: Deploy JAR /WEB-INF/lib/xtags.jar to C:\Program Files\Apache Group\Tomcat 4.1\webapps\texas\WEB-INF\lib\xtags.jar ContextConfig[/texas]: Added
DO NOT REPLY [Bug 15404] New: - No error condition raised if mandatory TLD elements jsp-version and tlib-version are not present in the TLD
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=15404. 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=15404 No error condition raised if mandatory TLD elements jsp-version and tlib-version are not present in the TLD Summary: No error condition raised if mandatory TLD elements jsp-version and tlib-version are not present in the TLD Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to the PFD specification, the TLD elements jsp-version and tlib-version are supposed to be mandatory, however, Jasper doesn't raise an error condition if it encounters a TLD with these elements missing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15364] - The jsp:body action doesn't work as expected when used with the jsp:fallback action.
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=15364. 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=15364 The jsp:body action doesn't work as expected when used with the jsp:fallback action. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java Node.java Parser.java
luehe 2002/12/16 08:13:28
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Node.java Parser.java
Log:
Fixed 15364: The jsp:body action doesn't work as expected when used with the
jsp:fallback action.
Revision ChangesPath
1.142 +5 -12
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.141
retrieving revision 1.142
diff -u -r1.141 -r1.142
--- Generator.java12 Dec 2002 23:31:51 - 1.141
+++ Generator.java16 Dec 2002 16:13:28 - 1.142
@@ -1458,15 +1458,8 @@
* Fallback
*/
if (n.getBody() != null) {
- n.getBody().visit(new Node.Visitor() {
- public void visit(Node.FallBackAction n) {
- n.setBeginJavaLine(out.getJavaLine());
- out.printil(out.write( +
- quote(new String(n.getText())) + ););
- out.printil(out.write(\\\n\););
- n.setEndJavaLine(out.getJavaLine());
- }
- });
+ visitBody(n);
+ out.printil(out.write(\\\n\););
}
out.printil(out.write( + quote(/NOEMBED/EMBED) + ););
1.49 +5 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- Node.java 13 Dec 2002 18:06:08 - 1.48
+++ Node.java 16 Dec 2002 16:13:28 - 1.49
@@ -682,8 +682,8 @@
*/
public static class FallBackAction extends Node {
- public FallBackAction(Mark start, String text, Node parent) {
- super(text, start, parent);
+ public FallBackAction(Mark start, Node parent) {
+ super(start, parent);
}
public void accept(Visitor v) throws JasperException {
1.47 +7 -20
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- Parser.java 13 Dec 2002 15:44:39 - 1.46
+++ Parser.java 16 Dec 2002 16:13:28 - 1.47
@@ -1090,23 +1090,10 @@
*)
*/
private void parseFallBack(Node parent) throws JasperException {
-if( reader.matches( / ) ) {
-// No elements, don't create node.
-}
-else if( reader.matches( ) ) {
-Mark bodyStart = reader.mark();
-Mark bodyEnd = reader.skipUntilETag(jsp:fallback);
-if (bodyEnd == null) {
-err.jspError(start, jsp.error.unterminated,
-lt;jsp:fallback);
-}
-new Node.FallBackAction(start, reader.getText(bodyStart, bodyEnd),
- parent);
-}
-else {
-err.jspError( reader.mark(), jsp.error.unterminated,
-lt;jsp:fallback );
-}
+ Mark bodyStart = reader.mark();
+ Node fallBackNode = new Node.FallBackAction(start, parent);
+ parseOptionalBody(fallBackNode, jsp:fallback,
+ JAVAX_BODY_CONTENT_TEMPLATE_TEXT);
}
/*
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15403] - Embedded Tomcat can't compile JSP .java file due to extra /
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=15403. 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=15403 Embedded Tomcat can't compile JSP .java file due to extra / [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Version|4.1.16 |4.1.17 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15405] New: - 4.1.12 won't run on NT
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=15405. 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=15405 4.1.12 won't run on NT Summary: 4.1.12 won't run on NT Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I installed 4.1.12 on NT4, SP5. The installation ran smoothly. On Start Tomcat, the start window came up normally, followed by a rapid scrolling of verbiage, too fast to read. When I tried to test this first with http://localhost:8080. The index.html was will not run on either Netscape or IE. Also, a test program math.jsp would not run. I loaded v 4.0.6 and it runs normally. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL][TOMCAT5] plugins directory
Costin Manolache wrote: There are several things we discussed last week, and few seem to have enough consensus. This is an initial proposal - I expect it to change quite a bit. I think it's very important and will affect almost everyone - so please send at least a numeric vote, and if possible comments or sugestions. If we do agree - we'll need to also do the work, so please indicate if you are willing to write at least some of the code :-) We seem to agree on having a more modular tomcat, where different components can be added ( by a script, manually, etc ) or removed easily. The mechanisms of adding/removing components is a separate issue that can be decided in a separate thread. My initial proposal is: 1. Add a new plugins/ directory. All tomcat components will eventually be migrated from server/lib and common/lib into one of the plugins subdirectories. ( it can be called modules/ or something else ). 2. The profile will consist of a list of plugins that are enabled. This can be configured using an XML file or using an API ( details of this are a separate item ). Tomcat will _not_ load all plugins automatically ( like in webapps/ or tomcat33 modules ), you'll have to explicitely add each of them. 3. The format of a plugin. We should support at least .war ( tomcat already have all the code ). I don't see a need for a format that is very different, but we (may) need to add an additional XML file. We should also be able to support a .jar format ( maybe with an additional .xml descriptor in META-INF ) as well as .xml descriptors in the plugin directory. 4. Each plugin will define one or several MBeans. Regular JMX API will be used to add/remove plugins, and the normal JMX notifications will be used to detect and plug the plugins into the server. It should be possible for an application embeding tomcat to add MBeans from any other locations. 5. The XML should be similar with the MLET format ( with some extensions if we need to ). I don't see any need for something more complicated or different. 6. Each classloader in tomcat will be ( or have ) a MBean. Different plugins can define new classloaders ( by using an mbean declaration ) or add jars to existing classloaders ( in particular the server, common and individual webapp loaders ). 7. Tomcat startup will be modified to start with only JMX and whatever minimal code we need to load plugins. The common and server loaders will be defined by the plugins. All classloader configuration will be consolidated. The ant startup will also be changed to use the same xml format ( mbean, etc ). 8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. A big +1 (even if I may have very little time to help the next months) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15405] - 4.1.12 won't run on NT
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=15405. 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=15405 4.1.12 won't run on NT [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-16 17:23 --- This is not a bug. There are many users that have installed Tomcat 4.1.12 under NT (including me) and everything works fine. I recommend you clean up your directory installation and try again. In order to see what contains the stack trace, you should starts Tomcat using a command line shell (dos in your case): ex: c:\program files\tomcat4.1.12\bin\catalina.bat run Your error will be displayed. If you don't know how to resolve the problem, ask the question on [EMAIL PROTECTED] -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15392] - web.xml
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=15392. 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=15392 web.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-16 17:27 --- The way web.xml is not defined by the Tomcat dev group, but by the Servlet JCP group (see http://jcp.org/aboutJava/communityprocess/first/jsr154/). If you have comments/recommendation on how to simplify web.xml, post them to: [EMAIL PROTECTED] To have help on how to define your web.xml, post to [EMAIL PROTECTED] -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15374] - Getting class cast exception
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=15374. 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=15374 Getting class cast exception [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-16 17:33 --- Like you said The same application, is running on a diff pc. can anybody help me out in this, this is not a bug and you should not open bug for question. Please post your questions on [EMAIL PROTECTED] From: root cause java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance seems the machine that is falling is using an XML parser that is not compliant with JAXP 1.1. Please verify your XML parser. -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15391] - Jasper generates a translation error if the body of jsp:params is supplied though jsp:body
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=15391. 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=15391 Jasper generates a translation error if the body of jsp:params is supplied though jsp:body [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Parser.java Validator.java
luehe 2002/12/16 09:34:32
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
Validator.java
Log:
Fixed 15391: Jasper generates a translation error if the body of jsp:params is
supplied though jsp:body
Revision ChangesPath
1.48 +6 -16
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- Parser.java 16 Dec 2002 16:13:28 - 1.47
+++ Parser.java 16 Dec 2002 17:34:32 - 1.48
@@ -1068,18 +1068,9 @@
*| ( '' S? Param* '/jsp:params' )
*/
private void parseJspParams(Node parent) throws JasperException {
-if( reader.matches( / ) ) {
-// No elements, don't create node.
-}
-else if( reader.matches( ) ) {
-reader.skipSpaces();
-Node jspParamsNode = new Node.ParamsAction(start, parent);
-parseBody(jspParamsNode, jsp:params, JAVAX_BODY_CONTENT_PARAM );
-}
-else {
-err.jspError(reader.mark(), jsp.error.unterminated,
-lt;jsp:params );
-}
+ Node jspParamsNode = new Node.ParamsAction(start, parent);
+ parseOptionalBody(jspParamsNode, jsp:params,
+ JAVAX_BODY_CONTENT_PARAM );
}
/*
@@ -1090,7 +1081,6 @@
*)
*/
private void parseFallBack(Node parent) throws JasperException {
- Mark bodyStart = reader.mark();
Node fallBackNode = new Node.FallBackAction(start, parent);
parseOptionalBody(fallBackNode, jsp:fallback,
JAVAX_BODY_CONTENT_TEMPLATE_TEXT);
1.62 +3 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
Index: Validator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- Validator.java13 Dec 2002 18:06:08 - 1.61
+++ Validator.java16 Dec 2002 17:34:32 - 1.62
@@ -492,13 +492,6 @@
if (subElems == null) {
err.jspError(n, jsp.error.params.emptyBody);
}
- for (int i=0; isubElems.size(); i++) {
- Node subElem = subElems.getNode(i);
- if (!(subElem instanceof Node.ParamAction)) {
- err.jspError(n, jsp.error.params.illegalChild);
-}
-}
-
visitBody(n);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs ssl-howto.xml
jfclere 2002/12/16 09:39:36 Modified:webapps/tomcat-docs ssl-howto.xml Log: Add the format of the different certificates. Revision ChangesPath 1.12 +4 -3 jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml Index: ssl-howto.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- ssl-howto.xml 8 Feb 2002 17:51:05 - 1.11 +++ ssl-howto.xml 16 Dec 2002 17:39:35 - 1.12 @@ -384,8 +384,9 @@ -keystore lt;your_keystore_filenamegt;/source /li /ul -pNow you have a file called codecertreq.csr/code that you can submit to the Certificate Authority (look at the -documenation of the Certificate Authority website on how to do this). In return you get a Certificate./p +pNow you have a file called codecertreq.csr/code. The file is encoded in PEM format. +You can submit it to the Certificate Authority (look at the +documentation of the Certificate Authority website on how to do this). In return you get a Certificate./p /subsection subsection name=Importing the Certificate @@ -403,7 +404,7 @@ sourcekeytool -import -alias root -keystore lt;your_keystore_filenamegt; \ -trustcacerts -file lt;filename_of_the_chain_certificategt;/source /li -liAnd finally import your new Certificate +liAnd finally import your new Certificate (It must be in X509 format): sourcekeytool -import -alias tomcat -keystore lt;your_keystore_filenamegt; \ -trustcacerts -file lt;your_certificate_filenamegt;/source /li -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Thread priority
Hi,
I was wondering about how expensive the Thread.setPriority method is,
and to which extent it does what it advetises.
The point would be to assign the minimum priority to background
reloading threads, as well as set the priority of the thread accepting
on the server socket to the maximum while is it accepting, and then
switch back to normal priority once the accept is done.
That would prevent the only thread accepting on the server socket from
being starved by the OS scheduler.
Here's a patch for the PoolTcpEndpoint:
diff -r1.8 PoolTcpEndpoint.java
496a497
Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
500c501,503
}
---
} finally {
Thread.currentThread().setPriority(Thread.NORM_PRIORITY);
}
I have no idea if this produces useful results. This adds no additional
overhead on Windows according to OptimizeIt (which might hint that it
doesn't do anything on that platform). Maybe it would be a good ideato
test this on different platforms (and hammer the server to see how it
compares to an unpatched server).
According to Doug Lea's book, this may heuristically do something
intelligent depending on the VM implementation. (great :) )
Comments ?
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL][TOMCAT5] plugins directory
Jeanfrancois Arcand wrote: Costin Manolache wrote: There are several things we discussed last week, and few seem to have enough consensus. This is an initial proposal - I expect it to change quite a bit. I think it's very important and will affect almost everyone - so please send at least a numeric vote, and if possible comments or sugestions. If we do agree - we'll need to also do the work, so please indicate if you are willing to write at least some of the code :-) I will have time to work on the code :-) We seem to agree on having a more modular tomcat, where different components can be added ( by a script, manually, etc ) or removed easily. The mechanisms of adding/removing components is a separate issue that can be decided in a separate thread. My initial proposal is: 1. Add a new plugins/ directory. All tomcat components will eventually be migrated from server/lib and common/lib into one of the plugins subdirectories. ( it can be called modules/ or something else ). +1. For security reason, we should have a way to protect the module (using Remy's catalina.property mechanism). We should have trusted components as well as untrusted. I imagine the catalina.properties would disappear (at least, the classloader related sections). What about Xerces? It's a kind of pluging but it is also and endorsed lib. We need to keep the endorsed folder/mechanism Due to the way the JVM works (the problems we're running into with the XML parser prove that the Sun's bundle everything policy is broken), I'm afraid we indeed do. 2. The profile will consist of a list of plugins that are enabled. This can be configured using an XML file or using an API ( details of this are a separate item ). Tomcat will _not_ load all plugins automatically ( like in webapps/ or tomcat33 modules ), you'll have to explicitely add each of them. 3. The format of a plugin. We should support at least .war ( tomcat already have all the code ). I don't see a need for a format that is very different, but we (may) need to add an additional XML file. We should also be able to support a .jar format ( maybe with an additional .xml descriptor in META-INF ) as well as .xml descriptors in the plugin directory. I recommend keeping war file for web applications, and use jar as the standard module/component. In module implements a common interface for identifying themself, I recommend we don't add another xml file but use introspection to discover the module functionalities etc. I personally have plans to try to add plugins such as an EAR deployer, and plugins to wrap existing J2EE providers to go along with it (such as one for OpenEJB). 7. Tomcat startup will be modified to start with only JMX and whatever minimal code we need to load plugins. The common and server loaders will be defined by the plugins. All classloader configuration will be consolidated. The ant startup will also be changed to use the same xml format ( mbean, etc ). 8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. Questions: Are we considering a Valve as a module/component? And it is not clear in your proposal if we are keeping the server.xml file. I recommend we keep it just to avoid confusion (IMBW...we should have a pool to determine if users like server.xml :-) ). I think the answer is yes. Costin is proposing to develop a new loader underneath Catalina. server.xml and Valves are Catalina components, so it is untouched. I had a long running plan to stop using the digester and rely on a JNDI layer to access the Catalina configuration. I don't know if I'll have time to do it, though (I prefer focusing on the new mapper for now, since the mapper currently used by Tomcat 5 is really bad). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] [VOTE] Stability rating
Remy Maucherat wrote: ballot [ ] Alpha [ ] Beta [X] Stable (General Availability) Reason (optional): /ballot In case people missed my request for vote, here's my ballot. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15406] New: - error-page responses are sent with wrong status code!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406. 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=15406 error-page responses are sent with wrong status code! Summary: error-page responses are sent with wrong status code! Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I recently had occasion to use the error-page facility of web.xml with tomcat 4.x for the first time. To my surprise, tomcat sends a 200 status code with the content, regardless of what the original error code is! As far as I can tell, this is totally incorrect behavior. I regard it as a major bug because it's essentially censoring the http conversation between client and webapp, and makes it impossible for search engines, et. al., to distinguish between good and bad urls. I have verified this behavior in jakarta-tomcat-4.0.6 and 4.1.12 in standalone mode. I have not tested it with any of the connectors. I am happy to help contribute a patch if the developers agree this is a bug but have not the time to fix it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15410] New: - if the jsp:attribute action is used out of the spec'd context, a misleading error message is generated.
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=15410. 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=15410 if the jsp:attribute action is used out of the spec'd context, a misleading error message is generated. Summary: if the jsp:attribute action is used out of the spec'd context, a misleading error message is generated. Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following message is generated when using jsp:attribute in a context other than nesting within a standard or custom action: - The action is not a recognizable standard action. This error is misleading as jsp:attribute is a standard action...just the usage context is incorrect. Would like to request that Jasper be enhanced to have a more meaningful error message. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java
luehe 2002/12/16 11:43:54
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
Log:
Fixed 15404: No error condition raised if mandatory TLD elements
jsp-version and tlib-version are not present in the TLD
Revision ChangesPath
1.72 +2 -1
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.71
retrieving revision 1.72
diff -u -r1.71 -r1.72
--- messages.properties 13 Dec 2002 16:27:43 - 1.71
+++ messages.properties 16 Dec 2002 19:43:53 - 1.72
@@ -280,6 +280,7 @@
jsp.error.tld.fn.invalid.signature.parenexpected=Invalid syntax for function
signature in TLD. Parenthesis '(' expected. Tag Library: {0}, Function: {1}.
jsp.error.dynamic.attributes.not.implemented=The {0} tag declares that it accepts
dynamic attributes but does not implement the required interface
jsp.error.nomatching.fragment=Cannot find an attribute directive (with name={0} and
fragment=true) prior to the fragment directive.
+jsp.error.tld.mandatory.element.missing=Mandatory TLD element missing: {0}
jsp.error.attribute.noequal=equal symbol expected
jsp.error.attribute.noquote=quote symbol expected
jsp.error.attribute.unterminated=attribute for {0} is not properly terminated
1.29 +22 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- TagLibraryInfoImpl.java 12 Dec 2002 17:44:38 - 1.28
+++ TagLibraryInfoImpl.java 16 Dec 2002 19:43:53 - 1.29
@@ -244,7 +244,9 @@
Vector tagVector = new Vector();
Vector tagFileVector = new Vector();
Hashtable functionTable = new Hashtable();
-
+ boolean tlibVersionSeen = false;
+ boolean jspVersionSeen = false;
+
// Create an iterator over the child elements of our taglib element
ParserUtils pu = new ParserUtils();
TreeNode tld = pu.parseXMLDocument(uri, in);
@@ -256,13 +258,15 @@
TreeNode element = (TreeNode) list.next();
String tname = element.getName();
-if (tlibversion.equals(tname) || // JSP 1.1
-tlib-version.equals(tname)) // JSP 1.2
+if (tlibversion.equals(tname)// JSP 1.1
+ || tlib-version.equals(tname)) { // JSP 1.2
this.tlibversion = element.getBody();
-else if (jspversion.equals(tname) ||
- jsp-version.equals(tname))
+ tlibVersionSeen = true;
+} else if (jspversion.equals(tname)
+ || jsp-version.equals(tname)) {
this.jspversion = element.getBody();
-else if (shortname.equals(tname) ||
+ jspVersionSeen = true;
+} else if (shortname.equals(tname) ||
short-name.equals(tname))
this.shortname = element.getBody();
else if (uri.equals(tname))
@@ -301,6 +305,15 @@
}
}
+
+ if (!tlibVersionSeen) {
+ err.jspError(jsp.error.tld.mandatory.element.missing,
+ tlib-version);
+ }
+ if (!jspVersionSeen) {
+ err.jspError(jsp.error.tld.mandatory.element.missing,
+ jsp-version);
+ }
this.tags = new TagInfo[tagVector.size()];
tagVector.copyInto (this.tags);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15411] New: - A translation error does not occur if jsp:attribute is used to provide an attribute value for an XML element that should be conisdered template text.
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=15411. 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=15411 A translation error does not occur if jsp:attribute is used to provide an attribute value for an XML element that should be conisdered template text. Summary: A translation error does not occur if jsp:attribute is used to provide an attribute value for an XML element that should be conisdered template text. Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] JSP.5.10 - jsp:attribute - states: The action must only appear as a subelement of a standard or custom action. An attempt to use it otherwise must result in a translation error. The spec then gives an example For example, it cannot be used to specify the value of an attribute for XML elements that are template text. Given the following: --- ?xml version=1.0? root child jsp:attribute xmlns:jsp=http://java.sun.com/JSP/Page; name=myAttrName myAttrValue /jsp:attribute /child /root --- A translation-time error is not generated. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] [VOTE] Stability rating
ballot [ ] Alpha [ ] Beta [X] Stable (General Availability) -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] [VOTE] Stability rating
Remy Maucherat wrote: ballot [ ] Alpha [ ] Beta [X] Stable (General Availability) Amy Reason (optional): /ballot Thanks for voting and for testing 4.1.17 Alpha! Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java
luehe 2002/12/16 12:39:17
Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
Log:
Fixed 15404: No error condition raised if mandatory TLD elements
jsp-version and tlib-version are not present in the TLD
Revision ChangesPath
1.73 +2 -2
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.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- messages.properties 16 Dec 2002 19:43:53 - 1.72
+++ messages.properties 16 Dec 2002 20:39:17 - 1.73
@@ -278,9 +278,9 @@
jsp.error.tld.fn.invalid.signature.classnotfound=Invalid syntax for function
signature in TLD. Class not found: ${0}. Tag Library: {1}, Function: {2}.
jsp.error.tld.fn.invalid.signature.commaexpected=Invalid syntax for function
signature in TLD. Comma ',' expected. Tag Library: {0}, Function: {1}.
jsp.error.tld.fn.invalid.signature.parenexpected=Invalid syntax for function
signature in TLD. Parenthesis '(' expected. Tag Library: {0}, Function: {1}.
+jsp.error.tld.mandatory.element.missing=Mandatory TLD element missing or empty: {0}
jsp.error.dynamic.attributes.not.implemented=The {0} tag declares that it accepts
dynamic attributes but does not implement the required interface
jsp.error.nomatching.fragment=Cannot find an attribute directive (with name={0} and
fragment=true) prior to the fragment directive.
-jsp.error.tld.mandatory.element.missing=Mandatory TLD element missing: {0}
jsp.error.attribute.noequal=equal symbol expected
jsp.error.attribute.noquote=quote symbol expected
jsp.error.attribute.unterminated=attribute for {0} is not properly terminated
1.30 +5 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- TagLibraryInfoImpl.java 16 Dec 2002 19:43:53 - 1.29
+++ TagLibraryInfoImpl.java 16 Dec 2002 20:39:17 - 1.30
@@ -244,8 +244,6 @@
Vector tagVector = new Vector();
Vector tagFileVector = new Vector();
Hashtable functionTable = new Hashtable();
- boolean tlibVersionSeen = false;
- boolean jspVersionSeen = false;
// Create an iterator over the child elements of our taglib element
ParserUtils pu = new ParserUtils();
@@ -261,11 +259,9 @@
if (tlibversion.equals(tname)// JSP 1.1
|| tlib-version.equals(tname)) { // JSP 1.2
this.tlibversion = element.getBody();
- tlibVersionSeen = true;
} else if (jspversion.equals(tname)
|| jsp-version.equals(tname)) {
this.jspversion = element.getBody();
- jspVersionSeen = true;
} else if (shortname.equals(tname) ||
short-name.equals(tname))
this.shortname = element.getBody();
@@ -306,11 +302,11 @@
}
- if (!tlibVersionSeen) {
+ if (tlibversion == null) {
err.jspError(jsp.error.tld.mandatory.element.missing,
tlib-version);
}
- if (!jspVersionSeen) {
+ if (jspversion == null) {
err.jspError(jsp.error.tld.mandatory.element.missing,
jsp-version);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15417] New: - jsp_precompile seems like a possible DOS vulnerability
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=15417. 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=15417 jsp_precompile seems like a possible DOS vulnerability Summary: jsp_precompile seems like a possible DOS vulnerability Product: Tomcat 4 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I havn't actually had a problem with it yet, but it seems like anyone who figures out that a site is using a heavyweight jsp page, could mount a substantial CPU utilization DOS by sending lots of jsp_precompile requests. It seems that there should be a way to turn it of on production servers. Discussion on IRC seems to indicate that there is currently no way to turn it off. (One of the individuals claimed that he was reading the source and couldn't find any facility for disabling it). An alternate/additional idea to jsp_precompile is to replace this feature with one that allows the server configuration to specify a port number to open in parallel to the main port, but force a recompile for every access on that port. (and then send back the newly compiled page to the developer, unlike jsp_precompile) This could easily be controled at the firewall level by blocking access to that port, and disabled (never enbabled?) for a production server. The need for such a feature comes up when (for example) one goes from working on a HEAD revision to working on a branch where the file mod times can get older. You don't want to see the version left over from the newer HEAD when you attempt to view your work in the branch. In this case you actually want to recompile when the file got older, making an always recompile interface useful. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL][TOMCAT5] plugins directory
There are several things we discussed last week, and few seem to have enough consensus. This is an initial proposal - I expect it to change quite a bit. I think it's very important and will affect almost everyone - so please send at least a numeric vote, and if possible comments or sugestions. If we do agree - we'll need to also do the work, so please indicate if you are willing to write at least some of the code :-) I will have time to work on the code :-) We seem to agree on having a more modular tomcat, where different components can be added ( by a script, manually, etc ) or removed easily. The mechanisms of adding/removing components is a separate issue that can be decided in a separate thread. My initial proposal is: 1. Add a new plugins/ directory. All tomcat components will eventually be migrated from server/lib and common/lib into one of the plugins subdirectories. ( it can be called modules/ or something else ). +1. For security reason, we should have a way to protect the module (using Remy's catalina.property mechanism). We should have trusted components as well as untrusted. What about Xerces? It's a kind of pluging but it is also and endorsed lib. We need to keep the endorsed folder/mechanism 2. The profile will consist of a list of plugins that are enabled. This can be configured using an XML file or using an API ( details of this are a separate item ). Tomcat will _not_ load all plugins automatically ( like in webapps/ or tomcat33 modules ), you'll have to explicitely add each of them. 3. The format of a plugin. We should support at least .war ( tomcat already have all the code ). I don't see a need for a format that is very different, but we (may) need to add an additional XML file. We should also be able to support a .jar format ( maybe with an additional .xml descriptor in META-INF ) as well as .xml descriptors in the plugin directory. I recommend keeping war file for web applications, and use jar as the standard module/component. In module implements a common interface for identifying themself, I recommend we don't add another xml file but use introspection to discover the module functionalities etc. 4. Each plugin will define one or several MBeans. Regular JMX API will be used to add/remove plugins, and the normal JMX notifications will be used to detect and plug the plugins into the server. It should be possible for an application embeding tomcat to add MBeans from any other locations. +1. We will have to document that parts to avoid confusion. 5. The XML should be similar with the MLET format ( with some extensions if we need to ). I don't see any need for something more complicated or different. 6. Each classloader in tomcat will be ( or have ) a MBean. Different plugins can define new classloaders ( by using an mbean declaration ) or add jars to existing classloaders ( in particular the server, common and individual webapp loaders ). We should define a contract between Tomcat and the plugins which force the plugin-defined classloader to be secure (at least do the package protection check). Maybe plugin-defined classloader should extend some catalina classes in order to fullfill the contract. If a component doesn't have an MBean, we should have a mechanism to generate, using introspection, that MBean. We doesn't need that soon, but we you keep the idea in mind... 7. Tomcat startup will be modified to start with only JMX and whatever minimal code we need to load plugins. The common and server loaders will be defined by the plugins. All classloader configuration will be consolidated. The ant startup will also be changed to use the same xml format ( mbean, etc ). 8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. Questions: Are we considering a Valve as a module/component? And it is not clear in your proposal if we are keeping the server.xml file. I recommend we keep it just to avoid confusion (IMBW...we should have a pool to determine if users like server.xml :-) ). -- Jeanfrancois Costin +1 Amy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TldLocationsCache.java
luehe 2002/12/16 13:23:25
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch TldLocationsCache.java
Log:
Fixed 14200: TLDs under WEB-INF are not scanned for URI mappings
Revision ChangesPath
No revision
No revision
1.4.2.1 +101 -73
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java
Index: TldLocationsCache.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TldLocationsCache.java,v
retrieving revision 1.4
retrieving revision 1.4.2.1
diff -u -r1.4 -r1.4.2.1
--- TldLocationsCache.java20 Jun 2002 23:00:43 - 1.4
+++ TldLocationsCache.java16 Dec 2002 21:23:25 - 1.4.2.1
@@ -107,6 +107,7 @@
* the TLD of this tag library.
*
* @author Pierre Delisle
+ * @author Jan Luehe
*/
public class TldLocationsCache {
@@ -118,45 +119,56 @@
public static final int ROOT_REL_URI = 1;
public static final int NOROOT_REL_URI = 2;
-static private final String WEB_XML = /WEB-INF/web.xml;
+private static final String WEB_XML = /WEB-INF/web.xml;
/**
- * The mapping of the 'global' tag library URI to the location
- * (resource path) of the TLD associated with that tag library.
- * The location is returned as a String array:
+ * The mapping of the 'global' tag library URI to the location (resource
+ * path) of the TLD associated with that tag library. The location is
+ * returned as a String array:
*[0] The location
- *[1] If the location is a jar file, this is the location
- *of the tld.
+ *[1] If the location is a jar file, this is the location of the tld.
*/
-private Hashtable mappings = new Hashtable();
+private Hashtable mappings;
-private Hashtable tlds = new Hashtable();
+private Hashtable tlds;
+
+private boolean initialized;
+private ServletContext ctxt;
-private boolean initialized=false;
-ServletContext ctxt;
//*
// Constructor and Initilizations
+/**
+ * Constructor.
+ *
+ * @param ctxt the servlet context of the web application in which Jasper
+ * is running
+ */
public TldLocationsCache(ServletContext ctxt) {
-this.ctxt=ctxt;
+this.ctxt = ctxt;
+mappings = new Hashtable();
+tlds = new Hashtable();
+initialized = false;
}
private void init() {
if( initialized ) return;
try {
-processWebDotXml(ctxt);
-processJars(ctxt);
-initialized=true;
+processWebDotXml();
+processJars();
+ processTldsInFileSystem();
+initialized = true;
} catch (JasperException ex) {
Constants.message(jsp.error.internal.tldinit,
new Object[] { ex.getMessage() },
Logger.ERROR);
}
}
-
-private void processWebDotXml(ServletContext ctxt)
-throws JasperException
-{
+
+/*
+ * Populates taglib map described in web.xml.
+ */
+private void processWebDotXml() throws JasperException {
// Acquire an input stream to the web application deployment descriptor
InputStream is = ctxt.getResourceAsStream(WEB_XML);
@@ -168,11 +180,8 @@
}
// Parse the web application deployment descriptor
-ClassLoader cl =
-// (ClassLoader) ctxt.getAttribute(Constants.SERVLET_CLASS_LOADER);
-this.getClass().getClassLoader();
-ParserUtils pu = ParserUtils.createParserUtils(cl);
-TreeNode webtld = pu.parseXMLDocument(WEB_XML, is);
+TreeNode webtld = new ParserUtils().parseXMLDocument(WEB_XML, is);
+
Iterator taglibs = webtld.findChildren(taglib);
while (taglibs.hasNext()) {
@@ -196,44 +205,38 @@
if (tagLoc.endsWith(.jar))
tagLoc2 = META-INF/taglib.tld;
mappings.put(tagUri, new String[] {tagLoc, tagLoc2});
-
}
-
}
/**
- * Process all the jar files contained in this web application
+ * Processes any JAR files contained in this web application's
* WEB-INF/lib directory.
*/
-private void processJars(ServletContext ctxt)
-throws JasperException
-{
-
+private void processJars() throws JasperException {
Set libSet = ctxt.getResourcePaths(/WEB-INF/lib);
if (libSet != null) {
DO NOT REPLY [Bug 14200] - TLDs under WEB-INF are not scanned for URI mappings
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=14200. 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=14200 TLDs under WEB-INF are not scanned for URI mappings [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15417] - jsp_precompile seems like a possible DOS vulnerability
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=15417. 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=15417 jsp_precompile seems like a possible DOS vulnerability --- Additional Comments From [EMAIL PROTECTED] 2002-12-16 21:54 --- Jason Brittain helped me find this missing feature ([EMAIL PROTECTED]) and wishes some credit in the matter. Credit is definately due, as he explained jsp_precompile to me :) (I had been entirely confused by it's name, jsp_compile would have made a lot more sense to me) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15417] - jsp_precompile seems like a possible DOS vulnerability
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=15417. 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=15417 jsp_precompile seems like a possible DOS vulnerability --- Additional Comments From [EMAIL PROTECTED] 2002-12-16 21:56 --- (he is also the one who was reading the source code) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15410] - if the jsp:attribute action is used out of the spec'd context, a misleading error message is generated.
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=15410. 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=15410 if the jsp:attribute action is used out of the spec'd context, a misleading error message is generated. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
luehe 2002/12/16 14:21:17
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
Fixed 15410: if the jsp:attribute action is used out of the spec'd context, a
misleading error message is generated.
Revision ChangesPath
1.49 +5 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- Parser.java 16 Dec 2002 17:34:32 - 1.48
+++ Parser.java 16 Dec 2002 22:21:15 - 1.49
@@ -1173,6 +1173,8 @@
parsePlugin(parent);
} else if (reader.matches(element)) {
parseElement(parent);
+ } else if (reader.matches(attribute)) {
+ err.jspError(start, jsp.error.attribute.invalidUse);
} else if (reader.matches(fallback)) {
err.jspError(start, jsp.error.fallback.invalidUse);
} else if (reader.matches(params)) {
1.74 +2 -1
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.73
retrieving revision 1.74
diff -u -r1.73 -r1.74
--- messages.properties 16 Dec 2002 20:39:17 - 1.73
+++ messages.properties 16 Dec 2002 22:21:16 - 1.74
@@ -106,6 +106,7 @@
jsp.error.param.invalidUse=The jsp:param action must not be used outside the
jsp:include, jsp:forward, or jsp:params elements
jsp.error.params.invalidUse=jsp:params must be a direct child of jsp:plugin
jsp.error.fallback.invalidUse=jsp:fallback must be a direct child of jsp:plugin
+jsp.error.attribute.invalidUse=jsp:attribute must be a sublement of a standard or
custom action
jsp.error.closeindividualparam=param tag needs to be closed with \/\
jsp.error.closeparams=param tag needs to be closed with /params
jsp.error.params.emptyBody=jsp:params must contain at least one nested jsp:param
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15417] - jsp_precompile seems like a possible DOS vulnerability
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=15417. 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=15417 jsp_precompile seems like a possible DOS vulnerability [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-16 22:33 --- A request to a page with jsp_precompile option is just like the request without the option, except that the request is not delivered, i.e. http://foo.bar.jsp?pre_compile is not more expensive that http://foo.bar.jsp. The compilation is done only once, and if the JSP page has been compiled, the compilation won't happen. Therefore I fail to see how this can be used as a DOS attack. A production application should precompile all JSP pages, and that will reduce jsp_precompile to a nop. A more useful server option is probably one that tells it that the JSP pages in an application have been precompiled, and that it should not have to check for the time stamps for the pages and their servlet files. This might improve the performance of the pages somewhat. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Parser.java
luehe 2002/12/16 15:02:39
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
Log:
updated productions of jsp:params and jsp:fallback so that they accept jsp:body
Revision ChangesPath
1.50 +25 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- Parser.java 16 Dec 2002 22:21:15 - 1.49
+++ Parser.java 16 Dec 2002 23:02:39 - 1.50
@@ -1064,8 +1064,15 @@
}
/*
- * Params ::= '/'
- *| ( '' S? Param* '/jsp:params' )
+ * Params ::= `' S?
+ * ( ( `jsp:body'
+ *( ( S? Param+ S? `/jsp:body' )
+ * | TRANSLATION_ERROR
+ *)
+ * )
+ *| Param+
+ * )
+ * '/jsp:params'
*/
private void parseJspParams(Node parent) throws JasperException {
Node jspParamsNode = new Node.ParamsAction(start, parent);
@@ -1075,10 +1082,19 @@
/*
* Fallback ::= '/'
- * | ( ''
- * ( Char* - ( Char* '/jsp:fallback' ) )
- * '/jsp:fallback'
- *)
+ * | ( `' S? `jsp:body'
+ * ( ( S?
+ * ( Char* - ( Char* `/jsp:body' ) )
+ * `/jsp:body' S?
+ * )
+ * | TRANSLATION_ERROR
+ * )
+ * `/jsp:fallback'
+ * )
+ * | ( ''
+ * ( Char* - ( Char* '/jsp:fallback' ) )
+ * '/jsp:fallback'
+ * )
*/
private void parseFallBack(Node parent) throws JasperException {
Node fallBackNode = new Node.FallBackAction(start, parent);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Thread priority
Remy Maucherat wrote: I was wondering about how expensive the Thread.setPriority method is, and to which extent it does what it advetises. I don't think it's expensive at all. And it certainly has an effect. The point would be to assign the minimum priority to background reloading threads, as well as set the priority of the thread accepting on the server socket to the maximum while is it accepting, and then switch back to normal priority once the accept is done. You should save the priority and switch back to it. You can't assume that your initial priority is NORM_PRIORITY. I assume--since you're asking this and you know TC--that TC doesn't have it's own internal thread scheduler. Else you'd have to consider the interaction with that algorithm, too. That would prevent the only thread accepting on the server socket from being starved by the OS scheduler. One of the unequivocally good uses for setting priority. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2002/12/16 15:38:00
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Turn off XML escape for EL.
Revision ChangesPath
1.143 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -r1.142 -r1.143
--- Generator.java16 Dec 2002 16:13:28 - 1.142
+++ Generator.java16 Dec 2002 23:37:59 - 1.143
@@ -843,7 +843,7 @@
out.write(
+ JspUtil.interpreterCall(this.isTagFile,
${ + new String(n.getText()) + }, String.class,
- null, _jspx_fnmap, true )
+ null, _jspx_fnmap, false )
+ ););
} else {
out.printil(out.write( +
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15337] - ArrayIndexOutOfBoundException thrown when bad JSP provided to Jasper parser
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=15337. 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=15337 ArrayIndexOutOfBoundException thrown when bad JSP provided to Jasper parser [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Thread priority
Remy Maucherat wrote: Hi, I was wondering about how expensive the Thread.setPriority method is, and to which extent it does what it advetises. Remy, Thread.setPriority will (in a native threading implementation, rather than something like the old green-threads JVM) be a system call, so it's not free - but it's not a particularly expensive syscall. Expense is probably similar to the various socket calls like setTimeout(), etc. So it's cheap enough to do once or twice per connection. The extent to which it has an effect is very much platform (and probably JVM) dependent. It's also dependent on the permissions a user has - on many (all?) unix systems, only root may set a process or thread to higher than normal priority (unless the JVM itself is doing some scheduling, which I doubt is the case with modern native-threading JVMs). I suspect that this will mean that your suggested use of these calls will either fail, or have no effect (the latter being more likely) on most common JVM implementations. It's still worth setting the background reloader thread(s) to low priority, though. In short - this shouldn't hurt in any noticable way, but it's pretty unlikely to make any noticable difference in performance. Mike Smith -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk and load balancer - bug?
here is a scenario hardware stack LoadBalancer(port80) - Apache/mod_jk 2.0.43(port81) - Tomcat 4.1.12(port8080/8009) 1. The load balancer receives a request for http://server/somecontext/ 2. The load balancer forwards this to apache. Apache detects /somecontext/ and makes a request to Tomcat 3. Tomcat gets the request GET /somecontext/ and looks up welcome files 4. Tomcat finds index.jsp as a welcome file 5. Tomcat constructs a redirect using the absolute URL it got from Apache and here is the problem, in step 5 tomcat constructs an absolute URL, and uses the port number from Apache which was 81. hence the redirect will go to port 81. the response back to the server is Location:http://server:81/somecontext/index.jsp --which is wrong, the request came in on port 80 when it would have been better if the response was the relative URL. Is this a bug, or could we add a feature to be able to configure the Coyote connector to generate absolute or relative urls on sendRedirect Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk and load balancer - bug?
I should also note that this scenario works fine if you remove Apache from the stack. so when the load balancer forwards to port 8080, the location uses port 80 to return with. so maybe this is mod_jk that should list the port as 80? Filip here is a scenario hardware stack LoadBalancer(port80) - Apache/mod_jk 2.0.43(port81) - Tomcat 4.1.12(port8080/8009) 1. The load balancer receives a request for http://server/somecontext/ 2. The load balancer forwards this to apache. Apache detects /somecontext/ and makes a request to Tomcat 3. Tomcat gets the request GET /somecontext/ and looks up welcome files 4. Tomcat finds index.jsp as a welcome file 5. Tomcat constructs a redirect using the absolute URL it got from Apache and here is the problem, in step 5 tomcat constructs an absolute URL, and uses the port number from Apache which was 81. hence the redirect will go to port 81. the response back to the server is Location:http://server:81/somecontext/index.jsp --which is wrong, the request came in on port 80 when it would have been better if the response was the relative URL. Is this a bug, or could we add a feature to be able to configure the Coyote connector to generate absolute or relative urls on sendRedirect Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk and load balancer - bug?
What if: 1. load balancer receives a request for http://server/ 2. does httpd return http://server:81/ in Location? (I don't think so) And also what if 1. load balancer receives a request for http://server/somecontext/index.jsp? Punky Filip Hanik wrote: I should also note that this scenario works fine if you remove Apache from the stack. so when the load balancer forwards to port 8080, the location uses port 80 to return with. so maybe this is mod_jk that should list the port as 80? Filip here is a scenario hardware stack LoadBalancer(port80) - Apache/mod_jk 2.0.43(port81) - Tomcat 4.1.12(port8080/8009) 1. The load balancer receives a request for http://server/somecontext/ 2. The load balancer forwards this to apache. Apache detects /somecontext/ and makes a request to Tomcat 3. Tomcat gets the request GET /somecontext/ and looks up welcome files 4. Tomcat finds index.jsp as a welcome file 5. Tomcat constructs a redirect using the absolute URL it got from Apache and here is the problem, in step 5 tomcat constructs an absolute URL, and uses the port number from Apache which was 81. hence the redirect will go to port 81. the response back to the server is Location:http://server:81/somecontext/index.jsp --which is wrong, the request came in on port 80 when it would have been better if the response was the relative URL. Is this a bug, or could we add a feature to be able to configure the Coyote connector to generate absolute or relative urls on sendRedirect Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk and load balancer - bug?
Punky wrote: What if: 1. load balancer receives a request for http://server/ 2. does httpd return http://server:81/ in Location? (I don't think so) 1. In this case the request never gets forwarded to tomcat, hence Apache sends the redirect or forward, not Tomcat. So that case does not apply to tomcat at all. And also what if 1. load balancer receives a request for http://server/somecontext/index.jsp? this works, because there is no redirect sent at all from Tomcat, because you listed a file/page that exists. the problem only occurs when tomcat redirects a request to a page in the welcome file list, and sends it through apache back. Filip ~ Namaste - I bow to the divine in you ~ Filip Hanik Software Architect www.filip.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL][TOMCAT5] plugins directory
Sorry for the late reply, I had no mail for few days. Jeanfrancois Arcand wrote: 1. Add a new plugins/ directory. All tomcat components will eventually be migrated from server/lib and common/lib into one of the plugins subdirectories. ( it can be called modules/ or something else ). +1. For security reason, we should have a way to protect the module (using Remy's catalina.property mechanism). We should have trusted components as well as untrusted. I agree. Plugins should replace .jar files that are placed into server/lib and common/lib - and the same mechansims would apply. Each plugin should be able to define what goes into server/lib loader, what goes into common/lib loader, eventually and additional class loader to keep it's implementation isolated. And also set options on the class loaders - the module initialization ( in the mbean register callback ) can call tomcat APIs and set whatever it needs, register for hooks, etc ( similar with apache2 modules init() ). What about Xerces? It's a kind of pluging but it is also and endorsed lib. We need to keep the endorsed folder/mechanism I think this is a special case, and we'll have to keep it separated. Note that xerces itself is not a problem - the jaxp. classes are the ones needing endorsed. We could leave xerces as a module and have only xmlParserApis special. 3. The format of a plugin. We should support at least .war ( tomcat already have all the code ). I don't see a need for a format that is very different, but we (may) need to add an additional XML file. We should also be able to support a .jar format ( maybe with an additional .xml descriptor in META-INF ) as well as .xml descriptors in the plugin directory. I recommend keeping war file for web applications, and use jar as the standard module/component. In module implements a common interface for identifying themself, I recommend we don't add another xml file but use introspection to discover the module functionalities etc. By using WAR I meant reusing the current infrastructure and possibly the layout.( for example reloading plugins may be very interesting :-). The standard manifest and the META-INF/services should be enough to identify the services - but we will need mbeans.xml ( for modeler ) and probably an mlet-style config to define the classloaders or options. I agree we shouldn't add ( if possible ) any new xml dtd, there are more then enough already :-) I think the existing ( standard or already used ) mlet, mbeans.xml, services provide all the meta info we need. 6. Each classloader in tomcat will be ( or have ) a MBean. Different plugins can define new classloaders ( by using an mbean declaration ) or add jars to existing classloaders ( in particular the server, common and individual webapp loaders ). We should define a contract between Tomcat and the plugins which force the plugin-defined classloader to be secure (at least do the package protection check). Maybe plugin-defined classloader should extend some catalina classes in order to fullfill the contract. By defining the classloader - I meant more declarative definition. The plugin can instantiate a tomcat mbean for the loader ( we should have an mbean associated with the tomcat loader anyway ), or just use the classpath in the mlet. If the plugin decides to create its own loader - he probably knows what it's doing, but I hope that won't happen too often. If a component doesn't have an MBean, we should have a mechanism to generate, using introspection, that MBean. We doesn't need that soon, but we you keep the idea in mind... We already have that. Modeler. Works very nice :-) 8. Tomcat should work with no config file - using only JMX API calls to load it and configure a set of plugins ( profile ), using whatever class loader and layout the embeding application ( ant, etc ) wants. Questions: Are we considering a Valve as a module/component? And it is not clear in your proposal if we are keeping the server.xml file. I recommend we keep it just to avoid confusion (IMBW...we should have a pool to determine if users like server.xml :-) ). My proposal has nothing to do with server.xml or Valves or any other hook mechanism. It's about layout ( plugins/ or modules/ ) and how the modules are registered in tomcat ( using Mbean registration and nothing else ). How the modules are deployed ( using a dowload target or a full distribution and a command to remove some or anything else ) is also a separate issue. In general - I think server.xml should work ( backward compat at least), but we should also work on a different config file that is more friendly to editing and JMX config. I preffer using mlet-like style - it is very simple, standard ( or slightly extended :-), easy to generate. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.17] [VOTE] Stability rating
Remy Maucherat wrote: ballot [ ] Alpha [ ] Beta [X] Stable (General Availability) Reason (optional): /ballot Thanks for voting and for testing 4.1.17 Alpha! Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15417] - Add port for forced compilation of pages
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=15417. 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=15417 Add port for forced compilation of pages [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | Summary|jsp_precompile seems like a |Add port for forced |possible DOS vulnerability |compilation of pages --- Additional Comments From [EMAIL PROTECTED] 2002-12-17 07:09 --- Ok but my requested enhancement still stands even if there is no DOS attack. I did further direct testing of various timestamps/request combinations, and I had begun to suspect that it was in fact as you described. However as noted here, and in the end comment of bug 14165 version control systems can provide updated versions of files with older time stamps. It seems unreasonable that developers should have to maually (or with a script) touch JSP pages just to view a coherent set of pages when moving between branches, or from Trunk to Branch. I am reopening with a new summary title because I am requesting a feature that allows forced recompilation of pages for every load, preferably simply by accessing them on a second port. This is my rational for this suggestion stated another way: As a developer I am quite willing to wait compilation time to see a page I am testing correctly. Waiting for compilation is something we all acknowledge as being part of the business. My suggetion provides a developer oriented interface. A developer generally doesn't care how fast the page loads (within reason). If it isn't loading the code he just wrote, or just checked out of the repository, it is worse than useless, it is confusing. One of the worst maifestations of this is that a Developer checks out the branch B, edits foo.jsp and fixes a typo in bar.jsp. Then the next week the developer needs to make changes to Branch A, which contains an older older version of bar.jsp than B. The developer is editing barhelp.html in branch A and wants to make links and add text relating to bar.jsp. The problem is that since tomcat has cached bar.jsp when the developer was working on B (last week) when he looks at bar.jsp in his browser he gets the Branch B version of it even though he hasn't worked on branch B for a week. So basing his changes on what he sees in his browser, the developer edits barhelp.html, commits his changes, and as far as he can see all the links work and all the wigits he mentions are there. Of course when it gets moved to a new (read production) server, the cached pages have all been carefully cleared as part of a release procedure or are empty because it is a fresh install, suddenly barhelp.html turns out to have broken links to sections of bar.jsp that don't exist in the A version and talk about wigits that only exist in the B version. An extreme example, perhaps, but the point is it is really quite confusing to delete your entire directory, checkout a whole different branch, (perhaps even restart tomcat for good measure), and find yourself looking at a mix of pages from two different branches. The newest version of each file among all branches you have ever worked on is what you see when you browse around a devlopment server, unless you regularly delete the contents of the work directory or give up on having sensible modification dates and write a file touching script. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
spec conform role mapping?
Some days ago I'd asked the dev community about the role mapping behaviour of TC4.1.16 which is IMO not conform to the spec. Look at http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg37814.html (sorry for referencing, but it's all described in that message, so I won't do it again) I got only one response which wasn't really helpful in my eyes. Ok, it's not an big issue like minimal JSR 154 only distribution ;-) and this item is only a minimal part of JSR 154 but I'm sure the tomcat-dev is the right place to ask again for it before rashly put it on bugzilla. May be I'm stupid, but I think the fact is worth to reissue the question: Is the role mapping for 100 percent conform to the spec? Thomas -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
