DO NOT REPLY [Bug 23745] - jsp.error.unterminated.tag received when doing struts tags - improve error messages for misbuilt tags!
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=23745. 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=23745 jsp.error.unterminated.tag received when doing struts tags - improve error messages for misbuilt tags! [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ModJkMX.java
billbarker2003/10/12 23:34:06
Modified:jk/java/org/apache/jk/common ModJkMX.java
Log:
Slightly improving on sordid hack.
It's still too ugly for words, but at least I know it works with modeler-1.1.
Revision ChangesPath
1.7 +10 -3
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java
Index: ModJkMX.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ModJkMX.java 11 Oct 2003 06:10:00 - 1.6
+++ ModJkMX.java 13 Oct 2003 06:34:06 - 1.7
@@ -173,13 +173,20 @@
// We should keep track of loaded beans and call stop.
// Modeler should do it...
Iterator mbeansIt=mbeans.values().iterator();
+MBeanServer mbserver = Registry.getRegistry().getMBeanServer();
while( mbeansIt.hasNext()) {
MBeanProxy proxy=(MBeanProxy)mbeansIt.next();
Object ooname = proxy.getObjectName();
if( ooname != null ) {
-String soname = ooname.toString();
-ObjectName oname = new ObjectName(soname);
-Registry.getRegistry().getMBeanServer().unregisterMBean(oname);
+ObjectName oname = null;
+if(ooname instanceof ObjectName) {
+oname = (ObjectName)ooname;
+} else if(ooname instanceof String) {
+oname = new ObjectName((String)ooname);
+}
+if( oname != null ) {
+mbserver.unregisterMBean(oname);
+}
}
}
} catch( Throwable t ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23759] New: - allow web.xml security-constraint to restrict by request-origin-host or used-port
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=23759. 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=23759 allow web.xml security-constraint to restrict by request-origin-host or used-port Summary: allow web.xml security-constraint to restrict by request-origin-host or used-port Product: Tomcat 4 Version: 4.1.28 Platform: Other URL: http://www.cafesoft.com/products/cams/tomcat- security.html OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] it would be great to be able to restrict access by port or origin host or to have Deny lists as described in the above URL e.g. to allow a cron-job (struts) action only be triggered from my server's LAN or such that this particular action can only be triggered if the request to do so comes in via a specified non-standard port that is not open on my firewall. P.S.: Is there anywhere a comprehensive description of what can be done with security-constraints? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23759] - allow web.xml security-constraint to restrict by request-origin-host or used-port
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=23759. 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=23759 allow web.xml security-constraint to restrict by request-origin-host or used-port [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 06:56 --- What can be specified in a security-constraint is determined by the JCP, not Tomcat. The place to suggest this is [EMAIL PROTECTED] (where it may or may not be considered for Servlet 2.4). In the meantime, consider using the RemoteAddrValve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC 3.3.2-dev and endorsed lib
In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez a écrit : Remy Maucherat a écrit : Henri Gomez wrote: Henri Gomez a écrit : Note: I really love Xerces' error messages. Great it seems to works with : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; [ !ENTITY % appconf SYSTEM file:../etc/webapp/appconf.xml %appconf; ] web-app display-nameServlet 2.4 Examples/display-name description Servlet 2.4 Examples. /description . So should I assume that the current directory is webapps ? Most stuff during webapp deployment is relative to the host appBase, so I'm not surprised. I don't really know how this particular path is resolved, though. Could it be possible to add an attribute in Context to make Tomcat use the docBase location instead of appBase for a particular context ? I made extensive tests with TC 5.0.12 and my currents applications, where tomcat could live somewhere on the system (following Linux FHS recommandation), and the webapps elsewhere. With such very current settings, I couldn't determine from the webapp area where is the 'current workdir' and my relative links are broken !!! Also it will help ease translation from TC 3.3.x for 5.0.x since the current workdir for TC 3.3.x while parsing web.xml is the WEB-INF where the web.xml is located. Thanks to take a look at this or at least told me if I could works on it to add such feature. No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9362] - compiilation of JSP that includes a non-existant file dies without error message
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=9362. 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=9362 compiilation of JSP that includes a non-existant file dies without error message [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 08:39 --- Testing against Tomcat 3.3.2-dev, this produces the proper error messages for both dynamic compile and JSPC compile. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23762] New: - FAIL - Application at context path / could not be started
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=23762. 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=23762 FAIL - Application at context path / could not be started Summary: FAIL - Application at context path / could not be started Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When trying to start a web application mounted at root context with the HTML manager, I get the following message: FAIL - Application at context path / could not be started Problem 1: This message is not contained in the documentation of the HTML manager. Problem 2: I can't imagine why this bug is happening. Attached to this report, you find the host element of server.xml (some names replaced by xxx) and the Logfile. My web application lives in /var/lib/tomcat4/webapp-xxx/xxx/. Regards, Andreas Schildbach --- Host name=xxx.com appBase=/var/lib/tomcat4/webapp-xxx unpackWARs=false autoDeploy=false liveDeploy=false deployXML=false Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=xxx_access_log. suffix=.txt pattern=common/ Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=xxx_log. suffix=.txt timestamp=true/ Context path= docBase=xxx debug=0/ Context path=/manager privileged=true docBase=/usr/share/tomcat4/server/webapps/manager Realm className=org.apache.catalina.realm.MemoryRealm pathname=/var/lib/tomcat4/webapp-xxx/users.xml/ /Context /Host 2003-10-13 10:17:56 HTMLManager: init 2003-10-13 10:17:56 HTMLManager: init: Associated with Deployer 'xxx.com' 2003-10-13 10:17:56 HTMLManager: init: Global resources are available 2003-10-13 10:17:56 HTMLManager: list: Listing contexts for virtual host 'xxx.com' 2003-10-13 10:18:42 HTMLManager: start: Starting web application at '/' 2003-10-13 10:18:42 StandardHost[xxx.com]: standardHost.start 2003-10-13 10:18:42 StandardContext[]: Resources start failed: java.lang.IllegalArgumentException: Doc base must point to a WAR file at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:180) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3342) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3472) at org.apache.catalina.core.StandardHostDeployer.start(StandardHostDeployer.java:629) at org.apache.catalina.core.StandardHost.start(StandardHost.java:897) at org.apache.catalina.servlets.ManagerServlet.start(ManagerServlet.java:1105) at org.apache.catalina.servlets.HTMLManagerServlet.start(HTMLManagerServlet.java:555) at org.apache.catalina.servlets.HTMLManagerServlet.doGet(HTMLManagerServlet.java:157) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at
DO NOT REPLY [Bug 23763] New: - This bugzilla: create a Documentation or website component
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=23763. 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=23763 This bugzilla: create a Documentation or website component Summary: This bugzilla: create a Documentation or website component Product: Tomcat 4 Version: 4.1.28 Platform: Other URL: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23759 OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] this would be helpful e.g. for the above RFE! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23759] - allow web.xml security-constraint to restrict by request-origin-host or used-port
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=23759. 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=23759 allow web.xml security-constraint to restrict by request-origin-host or used-port [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Component|Catalina|Unknown Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 08:58 --- Thx for the hint, I mailed them a corresponding request.. Since there is no Documentation or website component, I set this to unknown. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23763) My suggestion is to make the answer to this question the next entry into the FAQ http://jakarta.apache.org/tomcat/faq/security.html! Best would be to combine it with a link into Sun's docu regarding this! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2-dev and endorsed lib
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. It's not really necessary for 3.3.x, since the XML parsing requirements for Tomcat are pretty limited (without looking, we are currently shipping with a jaxp1.x version I believe). I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'm +0 as long as the lib/endorsed directory is empty in the default install. Otherwise, I'm -1. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). The Tomcat 3.3 ClassLoaders are all delegating loaders (so it is much simpler than the 4.x/5.x case). If you are using a 1.4.x JVM, Tomcat 3.3 will always grap the XML parser from the System ClassLoader (either the one that ships-with, or the endorsed). Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2-dev and endorsed lib
Bill Barker a écrit : - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. It's not really necessary for 3.3.x, since the XML parsing requirements for Tomcat are pretty limited (without looking, we are currently shipping with a jaxp1.x version I believe). I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'm +0 as long as the lib/endorsed directory is empty in the default install. Otherwise, I'm -1. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). The Tomcat 3.3 ClassLoaders are all delegating loaders (so it is much simpler than the 4.x/5.x case). If you are using a 1.4.x JVM, Tomcat 3.3 will always grap the XML parser from the System ClassLoader (either the one that ships-with, or the endorsed). Even if we set -Djava.endorsed and fill the directory with the jars we want it to use ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2-dev and endorsed lib
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 2:09 AM Subject: Re: TC 3.3.2-dev and endorsed lib Bill Barker a écrit : - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. It's not really necessary for 3.3.x, since the XML parsing requirements for Tomcat are pretty limited (without looking, we are currently shipping with a jaxp1.x version I believe). I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'm +0 as long as the lib/endorsed directory is empty in the default install. Otherwise, I'm -1. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). The Tomcat 3.3 ClassLoaders are all delegating loaders (so it is much simpler than the 4.x/5.x case). If you are using a 1.4.x JVM, Tomcat 3.3 will always grap the XML parser from the System ClassLoader (either the one that ships-with, or the endorsed). Even if we set -Djava.endorsed and fill the directory with the jars we want it to use ? That should work much like it does for 4.1.x/5.0.x (but I haven't tried it :). Once you get out of the WebappClassLoader, the 4.1.x/5.0.x ClassLoaders are delegating CLs. Again, I'm +0 to set the -Djava.endorsed.dir to an empty directory (that the user can copy their favorite xerces version to), and -1 to populate it by default. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2-dev and endorsed lib
Bill Barker a écrit : - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 2:09 AM Subject: Re: TC 3.3.2-dev and endorsed lib Bill Barker a écrit : - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. It's not really necessary for 3.3.x, since the XML parsing requirements for Tomcat are pretty limited (without looking, we are currently shipping with a jaxp1.x version I believe). I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'm +0 as long as the lib/endorsed directory is empty in the default install. Otherwise, I'm -1. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). The Tomcat 3.3 ClassLoaders are all delegating loaders (so it is much simpler than the 4.x/5.x case). If you are using a 1.4.x JVM, Tomcat 3.3 will always grap the XML parser from the System ClassLoader (either the one that ships-with, or the endorsed). Even if we set -Djava.endorsed and fill the directory with the jars we want it to use ? That should work much like it does for 4.1.x/5.0.x (but I haven't tried it :). Once you get out of the WebappClassLoader, the 4.1.x/5.0.x ClassLoaders are delegating CLs. Again, I'm +0 to set the -Djava.endorsed.dir to an empty directory (that the user can copy their favorite xerces version to), and -1 to populate it by default. Ok, I will just create structure but don't populate by default - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat build.xml
hgomez 2003/10/13 02:44:16
Modified:.build.xml
Log:
Create an empty endorsed directory in lib/
Revision ChangesPath
1.198 +5 -1 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.197
retrieving revision 1.198
diff -u -r1.197 -r1.198
--- build.xml 2 Oct 2003 02:50:59 - 1.197
+++ build.xml 13 Oct 2003 09:44:16 - 1.198
@@ -108,7 +108,7 @@
property name=commons-modeler.lib location=${commons-modeler.home} /
property name=commons-modeler.jar
location=${commons-modeler.lib}/commons-modeler.jar /
- property name=jmx.jar location=${jakarta-tomcat-connectors}/lib/mx4j.jar/
+ property name=jmx.jar
location=${jakarta-tomcat-connectors}/lib/mx4j-jmx.jar/
property name=jmxtools.jar
location=${jakarta-tomcat-connectors}/lib/mx4j-tools.jar/
property name=log4j.jar location=${install.dir}/log4j/log4j.jar /
@@ -331,6 +331,7 @@
mkdir dir=${tomcat.build}/lib/apps/
mkdir dir=${tomcat.build}/lib/container/
mkdir dir=${tomcat.build}/lib/common/
+mkdir dir=${tomcat.build}/lib/endorsed/
mkdir dir=${tomcat.build}/logs/
mkdir dir=${tomcat.build}/bin/
mkdir dir=${tomcat.build}/doc/
@@ -375,6 +376,9 @@
copy file =src/build/readme/readme.common
tofile=${tomcat.build}/lib/common/README /
+
+copy file =src/build/readme/readme.endorsed
+ tofile=${tomcat.build}/lib/endorsed/README /
!-- This act as a default, Tomcat3.3 will not load it in
classpath, just a hack to ease the transition
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/build/readme readme.endorsed
hgomez 2003/10/13 02:44:36 Added: src/build/readme readme.endorsed Log: Add comments on endorsed dir Revision ChangesPath 1.1 jakarta-tomcat/src/build/readme/readme.endorsed Index: readme.endorsed === JARs which should be used by JDK 1.4 instead of its own implementation (ie xml parser) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/JmxSupport build.xml
hgomez 2003/10/13 02:45:05
Modified:proposals/JmxSupport build.xml
Log:
Fix mx4j jar name (1.1.1)
Revision ChangesPath
1.2 +1 -1 jakarta-tomcat/proposals/JmxSupport/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/proposals/JmxSupport/build.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- build.xml 30 Sep 2002 02:17:43 - 1.1
+++ build.xml 13 Oct 2003 09:45:05 - 1.2
@@ -18,7 +18,7 @@
property name=commons-logging.jar
location=${tomcat.build}/lib/common/commons-logging.jar /
- property name=jmx.jar location=${jakarta-tomcat-connectors}/lib/mx4j.jar/
+ property name=jmx.jar
location=${jakarta-tomcat-connectors}/lib/mx4j-jmx.jar/
property name=jmxtools.jar
location=${jakarta-tomcat-connectors}/lib/mx4j-tools.jar/
property name=tomcat.classes.dir location=${tomcat.build}/classes/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/JmxSupport/WEB-INF interceptors.xml
hgomez 2003/10/13 02:45:14 Modified:proposals/JmxSupport/WEB-INF interceptors.xml Log: Fix doc Revision ChangesPath 1.2 +3 -1 jakarta-tomcat/proposals/JmxSupport/WEB-INF/interceptors.xml Index: interceptors.xml === RCS file: /home/cvs/jakarta-tomcat/proposals/JmxSupport/WEB-INF/interceptors.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- interceptors.xml 30 Sep 2002 02:17:43 - 1.1 +++ interceptors.xml 13 Oct 2003 09:45:13 - 1.2 @@ -6,7 +6,9 @@ options are : -port : http adaptor will listen to this port +type : HTTP or JRMP adaptor (default http) + +port : http/jrmp adaptor will listen to this port If you're using the MX4J HTTP Adaptor, you could also set host and authentication : - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/shell tomcat.sh tomcat.bat
hgomez 2003/10/13 02:45:41
Modified:src/shell tomcat.sh tomcat.bat
Log:
Add use of endorsed lib in run scripts
Revision ChangesPath
1.38 +14 -11jakarta-tomcat/src/shell/tomcat.sh
Index: tomcat.sh
===
RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.sh,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- tomcat.sh 6 Mar 2003 16:30:45 - 1.37
+++ tomcat.sh 13 Oct 2003 09:45:41 - 1.38
@@ -47,6 +47,9 @@
[ -n $CLASSPATH ] CLASSPATH=`cygpath --path --unix $CLASSPATH`
fi
+# Set the default -Djava.endorsed.dirs argument
+JAVA_ENDORSED_DIRS=$TOMCAT_HOME/lib/endorsed
+
# Read local properties
if [ -f $HOME/.tomcatrc ] ; then
. $HOME/.tomcatrc
@@ -209,7 +212,7 @@
if [ $1 = -noout ] ; then
shift
-$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN start $@
${TOMCAT_HOME}/logs/stdout.log 21
+$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN start $@ ${TOMCAT_HOME}/logs/stdout.log 21
if [ ! -z $TOMCAT_PID ]; then
echo $! $TOMCAT_PID
@@ -219,7 +222,7 @@
echo Using classpath: ${CLASSPATH}
echo Using JAVA_HOME: ${JAVA_HOME}
echo Using TOMCAT_HOME: ${TOMCAT_HOME}
-$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN start $@
+$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN start $@
if [ ! -z $TOMCAT_PID ]; then
echo $! $TOMCAT_PID
@@ -248,7 +251,7 @@
echo Using classpath: ${CLASSPATH}
echo Using JAVA_HOME: ${JAVA_HOME}
echo Using TOMCAT_HOME: ${TOMCAT_HOME}
- $JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN stop $@
+ $JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN stop $@
if [ $1 = -force ] ; then
shift
@@ -260,26 +263,26 @@
shift
# Backward compat
if [ $1 = enableAdmin ] ; then
-$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN enableAdmin
$@
+$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN enableAdmin $@
elif [ $1 = -enableAdmin ] ; then
-$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN enableAdmin
$@
+$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN enableAdmin $@
else
echo Using classpath: ${CLASSPATH}
echo Using JAVA_HOME: ${JAVA_HOME}
echo Using TOMCAT_HOME: ${TOMCAT_HOME}
-$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN start $@
+$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN start $@
fi
elif [ $1 = enableAdmin ] ; then
- $JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN enableAdmin $@
+ $JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN enableAdmin $@
elif [ $1 = estart ] ; then
- $JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN estart $@
+ $JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN estart $@
elif [ $1 = jspc ] ; then
shift
-$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} $MAIN jspc $@
+$JAVACMD $JAVA_OPTS $TOMCAT_OPTS -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS
-Dtomcat.home=${TOMCAT_HOME} $MAIN jspc $@
elif [ $1 = jspcOrig ] ; then
shift
@@ -297,7 +300,7 @@
if [ $oldCP != ]; then
CLASSPATH=${CLASSPATH}:${oldCP}
fi
-(cd $TOMCAT_HOME; $JAVACMD $JSPC_OPTS -Dtomcat.home=${TOMCAT_HOME}
org.apache.jasper.JspC $@ )
+(cd $TOMCAT_HOME; $JAVACMD $JSPC_OPTS
-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -Dtomcat.home=${TOMCAT_HOME}
org.apache.jasper.JspC $@ )
elif [ $1 = env ] ; then
## Call it with source tomcat to set the env for tomcat
1.49 +12 -9 jakarta-tomcat/src/shell/tomcat.bat
Index: tomcat.bat
===
RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.bat,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- tomcat.bat27 Sep 2002 01:47:23 - 1.48
+++ tomcat.bat13 Oct 2003 09:45:41 - 1.49
@@ -68,6 +68,9 @@
goto cleanup
:okTcHome
+rem Set the default -Djava.endorsed.dirs argument
+set JAVA_ENDORSED_DIRS=%TOMCAT_HOME%\lib\endorsed
+
if not %TOMCAT_INSTALL% == goto gotTcInstall
set TOMCAT_INSTALL=.
if exist
DO NOT REPLY [Bug 23764] New: - logout in SSO from sessions in 2 or more webapps not working
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=23764. 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=23764 logout in SSO from sessions in 2 or more webapps not working Summary: logout in SSO from sessions in 2 or more webapps not working Product: Tomcat 5 Version: 5.0.12 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I have SSO enabled, and I log on to my webapp, and also visit a second webapp on my localhost, I can't logout anymore. If I go to the page which has the following JSP: remote user %=request.getRemoteUser() % in session %= session.getId() % % session.invalidate(); % and refresh over and over always showed the following: remote user adam in session EB2543D909D52551EA58C77E963CDD17 remote user adam in session EA33F35CCB3D1205A88226029C65939C remote user adam in session 8814C0365D3F0BDD97B1DE9B7EAECD17 remote user adam in session 1B7F0424190985F24A294EA2344888C5 The only way to logout is to close my browser or delete the JSESSIONIDSSO cookie in mozilla. But logout does work for just one app - if I only visit login to one webapp, when I invalidate the session, I immediately get a login request. NB: The logout functions correctly when all my sessions expire. NB2: When some but not all of my sessions in one SSO time out, I can re-access the timed-out webapps without seeing a login request. Hope that describes it clearly, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23766] New: - cannot configure SSL for form-based authentication
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=23766. 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=23766 cannot configure SSL for form-based authentication Summary: cannot configure SSL for form-based authentication Product: Tomcat 5 Version: 5.0.12 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tried putting the following in $CATALINA_HOME/server/webapps/manager/WEB-INF/web.xml but the SSL config is ignored: security-constraint web-resource-collection web-resource-nameSSL 4 Login/web-resource-name url-pattern/ssllogin.html/url-pattern url-pattern/sslerror.html/url-pattern /web-resource-collection user-data-constraint descriptionSSL required/description transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameBlackSailRealm/realm-name form-login-config form-login-page/ssllogin.html/form-login-page form-error-page/sslerror.html/form-error-page /form-login-config /login-config I have the login error pages in $CATALINA_HOME/server/webapps/manager/ Basically it always stays in non-SSL protocol. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23764] - logout in SSO from sessions in 2 or more webapps not working
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=23764.
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=23764
logout in SSO from sessions in 2 or more webapps not working
--- Additional Comments From [EMAIL PROTECTED] 2003-10-13 11:08 ---
There is a difference in SingleSignOn.java between 4.1 and 5.0. But the diff
doesn't make sense to me: what follows is the diff from 4.1 to 5 for what I
*guess* is the cause:
-// Deregister this single session id, invalidating associated sessions
-deregister(ssoId);
+if ( event.getData() != null
+ logout.equals( event.getData().toString() )) {
+// logout of all applications
+deregister(ssoId);
+} else {
+// invalidate just one session
+deregister(ssoId, session);
+}
Doing a grep for logout - I could not find one - so I have no idea when the
true part of the conditional gets executed. Any ideas?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23767] New: - initial location of manager.xml context file not documented
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=23767. 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=23767 initial location of manager.xml context file not documented Summary: initial location of manager.xml context file not documented Product: Tomcat 5 Version: 5.0.12 Platform: All OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On line 91 in src/jakarta-tomcat-catalina/webapps/docs/manager-howto.xml it should say something about finding the initial effective manager.xml context config file in $CATALINA_HOME/conf/Catalina/localhost/ This manager.xml is installed by the initial tomcat-5.0.12 installation, at least in the linux tarball, and it overrides any manager.xml which I put in appBase, at least for localhost. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23766] - cannot configure SSL for form-based authentication
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=23766. 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=23766 cannot configure SSL for form-based authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 12:19 --- FORM can be implemented as an internal redirection, like welcome files. As a result, it is not subject to constraints. Please do not reopen the report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23767] - initial location of manager.xml context file not documented
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=23767. 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=23767 initial location of manager.xml context file not documented [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 12:20 --- The documentation is accurate. Where did you find you could put XML files in the host appBase exactly ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). I don't care, sorry. The question to ask: is it the right thing to do or not. - Hosts are based on separate directories - Hosts should be independent Based on that, the choice of using appBase is the right one. Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. Webapps, and even more, hosts, should be independent. Anything else seems a hack which may or may not work. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). I don't care, sorry. The question to ask: is it the right thing to do or not. - Hosts are based on separate directories - Hosts should be independent Sorry, but I care about TC 3.2/3.3 users base, since I'm one of them. I've got not less than 50 clients using TC 3.3.1a and they use the described layout. Also sometimes ago we speak about security manager and stuff which shouldn't be get OUTSIDE the web application. When you have web.xml and its external entities in the same war, why couldn't we get them directly ? A webapp in a WAR doesn't have to know about specific appBase, or I missed a whole episode ? Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. Webapps, and even more, hosts, should be independent. Anything else seems a hack which may or may not work. Sure and since a webapp should be independant, the external entities SHOULD be searched by default in the WAR or exploded WAR... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23767] - initial location of manager.xml context file not documented
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=23767. 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=23767 initial location of manager.xml context file not documented --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:12 --- In my first paragraph in the bug description, I stated exactly where I found the instruction on where to place the manager app's context configuration xml file. This is the line (from tomcat 5.0.12): Install the manager.xml context configuration file in the appBase for your Host. Your question where did I find ? therefore indicates that we are either talking about different documentation or interpreting the documentation completely differently. I am not entering bugs in bugzilla for fun or as a means of getting support. I have already raised this issue on the tomcat-user list: http://www.mail-archive.com/[EMAIL PROTECTED]/msg106090.html and was therefore fairly certain that this is an issue. Please would you provide some more indication as to why this is not an issue, or otherwise re-open this. Further explanation will ultimately be of benefit to you as well, since others facing the same situation as myself may well then read it here and learn from it, rather than opening another bug or generating more traffic on the lists. Thanks Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs manager-howto.xml
remm2003/10/13 06:21:20 Modified:webapps/docs manager-howto.xml Log: - Fixed bad location, submitted by Adam Hardy. - Bug 23767. Revision ChangesPath 1.10 +2 -1 jakarta-tomcat-catalina/webapps/docs/manager-howto.xml Index: manager-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/manager-howto.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- manager-howto.xml 20 Sep 2003 07:49:48 - 1.9 +++ manager-howto.xml 13 Oct 2003 13:21:20 - 1.10 @@ -88,7 +88,8 @@ codeContext/code: ul liInstall the codemanager.xml/code context configuration file -in the codeappBase/code for your codeHost/code./li +in the code$CATALINA_HOME/conf/[enginename]/[hostname]/code folder. +/li liConfigure the Manager codeContext/code within the codeHost/code configuration in your Tomcat codeserver.xml/code configuration. Here is an example: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23767] - initial location of manager.xml context file not documented
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=23767. 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=23767 initial location of manager.xml context file not documented [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:24 --- Your sentence was too convoluted for me, so I misunderstood it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23767] - initial location of manager.xml context file not documented
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=23767. 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=23767 initial location of manager.xml context file not documented [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:25 --- Fixed. Thanks for the patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23764] - logout in SSO from sessions in 2 or more webapps not working
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=23764. 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=23764 logout in SSO from sessions in 2 or more webapps not working --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:29 --- This could have been added for more control, so I would leave the feature in and try to understand why. This is from a Patrick and Bob patch, so I don't think we can get an explanation as to why it is the right thing to do from them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23751] - Error with Saving Configuration
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=23751. 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=23751 Error with Saving Configuration --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:39 --- I thought about it, and I think you can only get that if catalina.base is something like ... I'll have to double check, but it would seem best to fix setting the two system properties in Bootstrap (and always replace it with a canonical path). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Remy Maucherat a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Allelouia, we agree ;) The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
CF w3c.org ... relative URIs are relative to the location of the resource within which the entity declaration occurs. http://www.w3.org/TR/REC-xml#sec-external-ent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9340] - Tomcat Service problem
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=9340. 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=9340 Tomcat Service problem --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:54 --- Created an attachment (id=8556) Windows Event Log Entry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: Remy Maucherat a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all TC 3.2/3.3 users since the location was the web.xml (which seems more realist). Let me explain : If you have a large and segmented web application, you won't put all the settings in the same web.xml. So you're using entities in web.xml to load parts of the applications from files present in WEB-INF, whatever webapp location could be. !ENTITY ap_part1 SYSTEM app_part1.xml !ENTITY ap_part2SYSTEM app_part2.xml !ENTITY ap_part3SYSTEM app_part3.xml ap_part1; ap_part2; ap_part3; With a load base relative to app base you break such 'natural' behaviour. Also consider that you could have many webapps, in many differents locations (think ISP/ASP), which didn't have to know the location of the appBase. If you want we could make it Context optional but the choice should be present to allow sites using TC 3.2/3.3 to switch more easily to 5.0... Henri, this issue is only related to loading of ENTITY's from web.xml? Doesn't the XML parser handle resolving those, and can't you use references relative to the directory the web.xml is in? I think I have misunderstood stuff. It is ok to base resolution on the webapp docBase (but not on the server home directory). As Glenn says, it seems more logical to base it on the location of web.xml. Allelouia, we agree ;) The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) +1 ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
The base should be the location of web.xml (la prochaine fois j'envoie un mail en français :---) +1 ;-) Time for a Tomcat Dev French Forum, to fix these language problems ? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9340] - Tomcat Service problem
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=9340. 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=9340 Tomcat Service problem --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:56 --- I am experiencing a similar problem with Tomcat 4.1.27 on Windows 2000 Server running SP3 with hot fix KB823980 and SQL Server 2000 running at 8.000.534 (sp2). I have attached the Windows event log in the comment above. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23764] - logout in SSO from sessions in 2 or more webapps not working
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=23764. 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=23764 logout in SSO from sessions in 2 or more webapps not working --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 13:59 --- Logout has been removed from the Servlet spec (I did remove the method) and probably forgot (wasn't aware of such behavour) that part. I will also take to look. -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23751] - Error with Saving Configuration
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=23751. 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=23751 Error with Saving Configuration --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 16:29 --- Thank you for a reply. I found, when I execute startup.bat direct (ex. double-click), catalina.base will be ... Because of it, FileNotFoundException occured. And The following patched are also solvable. Please confirm, if it is not trouble. Index: startup.bat === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/bin/startup.bat,v retrieving revision 1.4 diff -u -r1.4 startup.bat --- startup.bat 4 Aug 2002 18:19:43 - 1.4 +++ startup.bat 13 Oct 2003 15:10:14 - @@ -10,7 +10,7 @@ if not %CATALINA_HOME% == goto gotHome set CATALINA_HOME=. if exist %CATALINA_HOME%\bin\catalina.bat goto okHome -set CATALINA_HOME=.. +cd .. :gotHome if exist %CATALINA_HOME%\bin\catalina.bat goto okHome echo The CATALINA_HOME environment variable is not defined correctly Index: catalina.bat === RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/bin/catalina.bat,v retrieving revision 1.5 diff -u -r1.5 catalina.bat --- catalina.bat2 Oct 2003 17:07:40 - 1.5 +++ catalina.bat13 Oct 2003 16:22:52 - @@ -42,7 +42,7 @@ if not %CATALINA_HOME% == goto gotHome set CATALINA_HOME=. if exist %CATALINA_HOME%\bin\catalina.bat goto okHome -set CATALINA_HOME=.. +cd .. :gotHome if exist %CATALINA_HOME%\bin\catalina.bat goto okHome echo The CATALINA_HOME environment variable is not defined correctly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Important requirement : Re: [next] What's next ?
Henri Gomez wrote: CF w3c.org ... relative URIs are relative to the location of the resource within which the entity declaration occurs. http://www.w3.org/TR/REC-xml#sec-external-ent As long as Tomcat uses the Digester.parse() entry point that takes an InputSource, and properly specifies the system URL of the web.xml resource, the parser will be able to resolve relative URLs like this correctly. If Tomcat is doing that (it did in 4.1, haven't checked 5.0) and relative resolution doesn't work, then its an XML parser bug. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23766] - cannot configure SSL for form-based authentication
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=23766. 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=23766 cannot configure SSL for form-based authentication --- Additional Comments From [EMAIL PROTECTED] 2003-10-13 17:21 --- Hi Remy, are you saying that as of version 5 tomcat no longer supports the use of SSL to encrypt the login form in form-based authentication? Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
luehe 2003/10/13 14:53:45
Modified:coyote/src/java/org/apache/coyote Response.java
Log:
Fixed Bugtraq 4934442 (Response Content-Type has no charset even
though setCharacterEncoding was called)
This fixes the problem where a response char setting via
response.setCharacterEncoding() or response.setLocale() is not
preserved by a call to response.setContentType() with a content type
that has no charset, ie., response.getContentType(), following this
sequence of calls:
response.setCharacterEncoding(Shift_Jis);
response.setContentType(text/html)
used to return text/html instead of text/html;charset=Shift_Jis,
which violates the servlet spec.
Revision ChangesPath
1.27 +59 -34
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Response.java 2 Sep 2003 21:34:38 - 1.26
+++ Response.java 13 Oct 2003 21:53:45 - 1.27
@@ -64,7 +64,6 @@
import java.util.Locale;
import org.apache.tomcat.util.buf.ByteChunk;
-import org.apache.tomcat.util.http.ContentType;
import org.apache.tomcat.util.http.MimeHeaders;
/**
@@ -87,15 +86,18 @@
}
-// - Instance Variables
-
-
- /**
+// - Class Variables
+
+/**
* Default locale as mandated by the spec.
*/
private static Locale DEFAULT_LOCALE = Locale.getDefault();
-
-
+
+private static final int BEGIN_CHARSET_VALUE = charset=.length();
+
+
+// - Instance Variables
+
/**
* Status code.
*/
@@ -471,44 +473,67 @@
return;
characterEncoding = charset;
-
-String type = this.contentType;
- if (type != null) {
- int start = type.indexOf(charset=);
- if ( start != -1 ) {
- int end = type.indexOf(';', start+8);
- if (end = 0)
- type = type.substring(0,start+8)
- + charset + type.substring(end-1);
- else
- type = type.substring(0,start+8) + charset;
- this.contentType = type;
- } else {
- int end = type.indexOf(';');
- if (end = 0) {
- type = type.substring(0, end) + ;charset= + charset;
- } else {
- type = type + ;charset= + charset;
- }
- }
- setContentType( type );
-}
}
public String getCharacterEncoding() {
return characterEncoding;
}
+/**
+ * Sets the content type.
+ *
+ * @param contentType the content type
+ */
public void setContentType(String contentType) {
-this.contentType = contentType;
-String encoding = ContentType.getCharsetFromContentType(contentType);
-if (encoding != null) {
-characterEncoding = encoding;
+
+if (contentType == null) {
+this.contentType = null;
+return;
}
+
+/*
+ * Remove the charset param (if any) from the Content-Type, and use it
+ * to set the response encoding.
+ * The most recent response encoding setting will be appended to the
+ * response Content-Type (as its charset param) by getContentType();
+ */
+int beginCharsetValue = BEGIN_CHARSET_VALUE;
+int beginCharsetParam = contentType.indexOf(;charset=);
+if (beginCharsetParam == -1) {
+beginCharsetParam = contentType.indexOf(; charset=);
+beginCharsetValue++;
+}
+if (beginCharsetParam == -1) {
+// no charset
+this.contentType = contentType;
+return;
+}
+
+this.contentType = contentType.substring(0, beginCharsetParam);
+String tail = contentType.substring(beginCharsetParam + 1);
+int nextParam = tail.indexOf(';');
+String charsetValue = null;
+if (nextParam != -1) {
+this.contentType += tail.substring(nextParam);
+charsetValue = tail.substring(beginCharsetValue, nextParam);
+} else {
+charsetValue = tail.substring(beginCharsetValue);
+}
+// The charset value may be quoted, but must not contain any quotes.
+charsetValue = charsetValue.replace('', ' ');
+
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
+/*
+ * Remove the charset param (if any) from the Content-Type, and
use it
+ * to set the response encoding.
+ * The most recent response encoding setting will be appended
to the
+ * response Content-Type (as its charset param) by
getContentType();
+ */
+int beginCharsetValue = BEGIN_CHARSET_VALUE;
+int beginCharsetParam = contentType.indexOf(;charset=);
+if (beginCharsetParam == -1) {
+beginCharsetParam = contentType.indexOf(; charset=);
+beginCharsetValue++;
+}
Of course, this doesn't work if I do setContentType(text/html;
charset=utf-8);.
+if (beginCharsetParam == -1) {
+// no charset
+this.contentType = contentType;
+return;
+}
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
luehe 2003/10/13 16:36:23
Modified:coyote/src/java/org/apache/coyote Response.java
Log:
Support separators other than space preceding charset=
Revision ChangesPath
1.28 +13 -9
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java
Index: Response.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Response.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- Response.java 13 Oct 2003 21:53:45 - 1.27
+++ Response.java 13 Oct 2003 23:36:23 - 1.28
@@ -482,6 +482,10 @@
/**
* Sets the content type.
*
+ * This method must preserve any response charset that may already have
+ * been set via a call to response.setContentType(), response.setLocale(),
+ * or response.setCharacterEncoding().
+ *
* @param contentType the content type
*/
public void setContentType(String contentType) {
@@ -497,12 +501,7 @@
* The most recent response encoding setting will be appended to the
* response Content-Type (as its charset param) by getContentType();
*/
-int beginCharsetValue = BEGIN_CHARSET_VALUE;
-int beginCharsetParam = contentType.indexOf(;charset=);
-if (beginCharsetParam == -1) {
-beginCharsetParam = contentType.indexOf(; charset=);
-beginCharsetValue++;
-}
+int beginCharsetParam = contentType.indexOf(charset=);
if (beginCharsetParam == -1) {
// no charset
this.contentType = contentType;
@@ -510,14 +509,19 @@
}
this.contentType = contentType.substring(0, beginCharsetParam);
-String tail = contentType.substring(beginCharsetParam + 1);
+// Trim the semicolon preceding the charset
+int charsetSemi = this.contentType.lastIndexOf(';');
+if (charsetSemi != -1) {
+this.contentType = this.contentType.substring(0, charsetSemi);
+}
+String tail = contentType.substring(beginCharsetParam);
int nextParam = tail.indexOf(';');
String charsetValue = null;
if (nextParam != -1) {
this.contentType += tail.substring(nextParam);
-charsetValue = tail.substring(beginCharsetValue, nextParam);
+charsetValue = tail.substring(BEGIN_CHARSET_VALUE, nextParam);
} else {
-charsetValue = tail.substring(beginCharsetValue);
+charsetValue = tail.substring(BEGIN_CHARSET_VALUE);
}
// The charset value may be quoted, but must not contain any quotes.
charsetValue = charsetValue.replace('', ' ');
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DNS name changes to Machine name with Tomcat 4.1.27 - Reason?
Hi there, We are facing a problem of Tomcat changing the DNS name (xyz.abc.com) to the internal machine name (machine1.Company.com:port). This peculiar behaviour happens only when we do not give index.jsp at the end of the URL. (i.e.) https://xyz.abc.com/context/ - This gets changed to https://machine1.company.com:port/context/index.jsp. But if we give https://xyz.abc.com/context/index.jsp, the referer name remains the same. Our environment is Tomcat 4.1.27 with AJP13 connector to iPlanet web server over SSL. We found that (from the debug files generated on AJP13 connector) the host (and referer) name changes once the authentication is complete. Since the domain name changes to the machine name, one more authentication popup window comes up. Although, it changes the URL with the machine instead of domain, the application works without any issue. But we do not want the user to see the machine name with the port in a site with SSL instead of given domain name. Earlier we had an environment with Tomcat 3.2.4 with AJP13 connector to IPlanet. It was working fine in that environment. When we changed it to Tomcat 4.1.27, we encountered this peculiar issue. We are not sure, if this has some thing to do with Tomcat configuration. We are doubtful, if Tomcat 4.1.27 requires a changed setting at the iPlanet web server. We spent considerable time by changing the different attributes to connector tag in server.xml and we could not derive any solution for this issue. Can anyone help us with this issue? Your timely inputs are highly appreciated. Best regards, Sridhar - Do you Yahoo!? The New Yahoo! Shopping - with improved product search
RE: Problems during 5.0.13 startup
Title: RE: Problems during 5.0.13 startup Enclosed is the server.xml and web.xml files. Let me know if you need anything else. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 12, 2003 3:01 PM To: Tomcat Developers List Subject: Re: Problems during 5.0.13 startup Lenny Karpel wrote: I am testing 5.0.13 .. During startup I always get the following .. Is this something 'new' .. what does it mean ?? That's not very helpful. Can you give details on your context and host ? (docBase, appBase, etc) Remy Nov 10, 2003 5:25:37 PM org.apache.catalina.core.StandardContext start WARNING: Error storing config file java.io.FileNotFoundException: ..\..\conf\Catalina\localhost\ecs.xml (The system cannot find the path specified) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.catalina.core.StandardServer.storeContext(StandardServer.java:866 ) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3925) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardHost.start(StandardHost.java:792) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1125) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:502) at org.apache.catalina.core.StandardService.start(StandardService.java:519) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2343) at org.apache.catalina.startup.Catalina.start(Catalina.java:580) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:394) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
@@ -510,14 +509,19 @@
}
this.contentType = contentType.substring(0, beginCharsetParam);
-String tail = contentType.substring(beginCharsetParam + 1);
+// Trim the semicolon preceding the charset
+int charsetSemi = this.contentType.lastIndexOf(';');
This is still not working for me. Now I can't do stuff like:
setContentType(text/html;charset=utf-8; altcharset=iso-latin-1);
I don't know any current browser that uses this, but it is completely valid
in RFC 2616.
+if (charsetSemi != -1) {
+this.contentType = this.contentType.substring(0,
charsetSemi);
+}
+String tail = contentType.substring(beginCharsetParam);
int nextParam = tail.indexOf(';');
String charsetValue = null;
if (nextParam != -1) {
this.contentType += tail.substring(nextParam);
-charsetValue = tail.substring(beginCharsetValue,
nextParam);
+charsetValue = tail.substring(BEGIN_CHARSET_VALUE,
nextParam);
} else {
-charsetValue = tail.substring(beginCharsetValue);
+charsetValue = tail.substring(BEGIN_CHARSET_VALUE);
}
// The charset value may be quoted, but must not contain any
quotes.
charsetValue = charsetValue.replace('', ' ');
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE][DBCP][Pool] Second set of Release Candidates available for the 1.1 releases of Commons DBCP Pool
There are no significant changes for the commons-pool component. Only the license was updated (apache 1.1 license). The commons-DBCP component had the same license update and also an ant build file correction. Also the following issues were resolved since v1.1RC1: 22776 2003-09-30 NorFIXEDBCP should not be writing messages to stderr or stdout (removed unneeded logging in AbandonedObjectPool) 23491 2003-10-13 CriFIXECan't configure PerUserPoolDataSource for use with tomcat http://jakarta.apache.org/commons/dbcp/apidocs/org/apache/commons/dbcp/datasources/package-summary.html Release Candidates can be downloaded here: http://cvs.apache.org/~dirkv/builds/ The release schedule: * Preparation Period:28 September 2003 - 30 September 2003 * Review Period: 1 October 2003 - 15 October 2003 * Implementation Period: 16 October 2003 - 19 October 2003 * Release Pool/DBCP 1.1: 20 October 2003 Please report any issue to the commons-dev mailing list as soon as possible. Cheers Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
