cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup BootstrapService.java
remm02/02/18 01:00:54 Modified:catalina/src/share/org/apache/catalina/startup BootstrapService.java Log: - Add missing support for the new 'endorsed' directory in the various dist targets. Revision ChangesPath 1.12 +12 -9 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java Index: BootstrapService.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- BootstrapService.java 30 Dec 2001 01:58:20 - 1.11 +++ BootstrapService.java 18 Feb 2002 09:00:54 - 1.12 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v 1.11 2001/12/30 01:58:20 glenn Exp $ - * $Revision: 1.11 $ - * $Date: 2001/12/30 01:58:20 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v 1.12 2002/02/18 09:00:54 remm Exp $ + * $Revision: 1.12 $ + * $Date: 2002/02/18 09:00:54 $ * * * @@ -86,7 +86,7 @@ * * @author Craig R. McClanahan * @author Remy Maucherat - * @version $Revision: 1.11 $ $Date: 2001/12/30 01:58:20 $ + * @version $Revision: 1.12 $ $Date: 2002/02/18 09:00:54 $ */ public final class BootstrapService @@ -137,14 +137,17 @@ File unpacked[] = new File[1]; File packed[] = new File[1]; +File packed2[] = new File[2]; ClassLoaderFactory.setDebug(debug); unpacked[0] = new File(getCatalinaHome(), common + File.separator + classes); -packed[0] = new File(getCatalinaHome(), - common + File.separator + lib); +packed2[0] = new File(getCatalinaHome(), + common + File.separator + endorsed); +packed2[1] = new File(getCatalinaHome(), + common + File.separator + lib); commonLoader = -ClassLoaderFactory.createClassLoader(unpacked, packed, null); +ClassLoaderFactory.createClassLoader(unpacked, packed2, null); unpacked[0] = new File(getCatalinaHome(), server + File.separator + classes); @@ -154,9 +157,9 @@ ClassLoaderFactory.createClassLoader(unpacked, packed, commonLoader); -unpacked[0] = new File(getCatalinaHome(), +unpacked[0] = new File(getCatalinaBase(), shared + File.separator + classes); -packed[0] = new File(getCatalinaHome(), +packed[0] = new File(getCatalinaBase(), shared + File.separator + lib); sharedLoader = ClassLoaderFactory.createClassLoader(unpacked, packed, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 build.xml tomcat.nsi
remm02/02/18 01:01:05
Modified:.build.xml tomcat.nsi
Log:
- Add missing support for the new 'endorsed' directory in the various dist targets.
Revision ChangesPath
1.62 +4 -0 jakarta-tomcat-4.0/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- build.xml 15 Feb 2002 17:50:43 - 1.61
+++ build.xml 18 Feb 2002 09:01:05 - 1.62
@@ -112,6 +112,7 @@
mkdir dir=${tomcat.dist}/bin/
mkdir dir=${tomcat.dist}/common/
mkdir dir=${tomcat.dist}/common/classes/
+mkdir dir=${tomcat.dist}/common/endorsed/
mkdir dir=${tomcat.dist}/common/lib/
mkdir dir=${tomcat.dist}/conf/
mkdir dir=${tomcat.dist}/logs/
@@ -147,6 +148,9 @@
/copy
copy todir=${tomcat.dist}/common/classes
fileset dir=${tomcat.build}/common/classes /
+/copy
+copy todir=${tomcat.dist}/common/endorsed
+ fileset dir=${tomcat.build}/common/endorsed /
/copy
copy todir=${tomcat.dist}/common/lib
fileset dir=${tomcat.build}/common/lib /
1.30 +2 -2 jakarta-tomcat-4.0/tomcat.nsi
Index: tomcat.nsi
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tomcat.nsi,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- tomcat.nsi7 Feb 2002 20:52:06 - 1.29
+++ tomcat.nsi18 Feb 2002 09:01:05 - 1.30
@@ -1,6 +1,6 @@
; Tomcat 4 script for Nullsoft Installer
-; $Id: tomcat.nsi,v 1.29 2002/02/07 20:52:06 remm Exp $
+; $Id: tomcat.nsi,v 1.30 2002/02/18 09:01:05 remm Exp $
Name apache-tomcat-4.1
Caption Apache Tomcat 4.1
@@ -71,7 +71,7 @@
SetOutPath $INSTDIR\bin
File /oname=tomcat.exe bin\tomcat.exe
- ExecWait '$INSTDIR\bin\tomcat.exe -install Apache Tomcat 4.1 $2
-Djava.class.path=$INSTDIR\bin\bootstrap.jar -Dcatalina.home=$INSTDIR -start
org.apache.catalina.startup.BootstrapService -params start -stop
org.apache.catalina.startup.BootstrapService -params stop -out
$INSTDIR\logs\stdout.log -err $INSTDIR\logs\stderr.log'
+ ExecWait '$INSTDIR\bin\tomcat.exe -install Apache Tomcat 4.1 $2
-Djava.class.path=$INSTDIR\bin\bootstrap.jar -Dcatalina.home=$INSTDIR
-Djava.endorsed.dirs=$INSTDIR\common\endorsed -start
org.apache.catalina.startup.BootstrapService -params start -stop
org.apache.catalina.startup.BootstrapService -params stop -out
$INSTDIR\logs\stdout.log -err $INSTDIR\logs\stderr.log'
ClearErrors
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
Remy Maucherat wrote: Hi, There's a hidden component in Tomcat 4 named service (package is org.apache.service), which has almost nothing to do with Tomcat (except it was written by Pier and started its life here). The most current version of it (which is *not* the one used by Tomcat, BTW) resides in the jakarta-tomcat-service repository (which I had completely forgotten until I saw JF recent commits). ;-) - I suddently noted it was not working with win9x and I needed some service on a win98 box - I think the service package would live a happier life in the commons (the base interfaces + the native code); then, we can update the HEAD branch to use the commons package. Note: In the commons, there's already a services component. To avoid creating confusion, I suggest renaming the service component to commons-daemon. Comments ? The idea in jakarta-tomcat-service is to implement JSR96 (http://jcp.org/jsr/detail/96.jsp). jakarta-tomcat-4.1/service is to allow run tomcat on port 80 as a daemon... Porting it to jakarta-tomcat-service could be the other option. Votes ? 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]
Difference between Tomcat-3.2.1 and Tomcat-3.3a
I need to know what is the main difference between Tomcat-3.2.1 and Tomcat-3.3a ?? Because when I try to view my jsp page in chinese characters, using the HTML header, I can view the characters correctly, but because Tomcat-3.3a offers a newer version of JDBC API, as a result i change to Tomcat-3.3a. But now I can't view the information in chinese characters anymore. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Servlet problem
Hi all, I have some problems with Catalina server. Some details : I have a class : FilterLogin extends BaseServlet extends SecureServlet extends javax.servlet.http.HttpServlet (which implements javax.servlet.Servlet). When I try to load the class and login, i get the following exception : A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Class one5.filter.servlet.FilterLogin is not a Servlet at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:743) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:496) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:811) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:890) at java.lang.Thread.run(Thread.java:484) Root Cause: java.lang.ClassCastException: one5.filter.servlet.FilterLogin at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:740) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:496) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:811) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:890) at java.lang.Thread.run(Thread.java:484) Are there any explanations for this ? Thanks a lot. -- * Sincerely Valentin Cozma One5 Development Romania Srl. Programmer Str Intrarea Glucozei No 37-39, sector 2, Bucharest, Romania Phone : +40 (1) 243 05 80 Fax: +40 (1) 243 05 79 Mobile : +40 93 190 126 E-Mail: [EMAIL PROTECTED] Visit us on the Internet: http://www.one5.com/ One5 Corporation - Wireless Infrastructure for 3rd Generation
DO NOT REPLY [Bug 6519] New: - Problem with HTMLManagerServlet when running JDK1.4
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=6519. 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=6519 Problem with HTMLManagerServlet when running JDK1.4 Summary: Problem with HTMLManagerServlet when running JDK1.4 Product: Tomcat 4 Version: 4.0.2 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I installed JDK 1.4 and tried out both versions of tomcat 4.0.2 final - the usual one and the one for jdk1.4 Everything works fine. I can use the Manager webapp in its usual mode, but if I run it using the HTMLManagerServlet then I get the following exception when I try to access the webapp with my browser. Well, this could be a bug within the jdk, since the HTMLManager runs fine on jdk1.3. Nonetheless I wanted to report this behaviour to you. Using CATALINA_BASE: C:\java\tomcat_jdk14 Using CATALINA_HOME: C:\java\tomcat_jdk14 Using CATALINA_TMPDIR: C:\java\tomcat_jdk14\temp Using JAVA_HOME: C:\java\jdk140 Starting service Tomcat-Standalone Apache Tomcat/4.0.2 java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END at java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEnc oder.java:933) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529) at sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.ja va:356) at sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222) at java.io.PrintWriter.close(PrintWriter.java:137) at org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBas e.java:482) at org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpRes ponseBase.java:236) at org.apache.catalina.connector.http.HttpResponseImpl.finishResponse(Ht tpResponseImpl.java:288) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso r.java:1039) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja va:1107) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6201] - ISO-8859-8-i problem. (hebrew)
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=6201. 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=6201 ISO-8859-8-i problem. (hebrew) --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 10:01 --- Created an attachment (id=1196) a file with that was requested , setting content-type to ISO-8859-8-i -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6201] - ISO-8859-8-i problem. (hebrew)
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=6201. 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=6201 ISO-8859-8-i problem. (hebrew) --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 10:04 --- i've seen the java encoding , i couldn't find something i can use, unfortunately i use IE6 , and my DB (not actually mine - my client's ) is working in someother encoding , and the only time i can see DB data in JSP is when using IE specific encoding iso-8859-8-i. best regards. Yehonatan Mozes -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6519] - Problem with HTMLManagerServlet when running JDK1.4
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=6519. 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=6519 Problem with HTMLManagerServlet when running JDK1.4 --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 12:31 --- it seems there is a problem with the request.getWriter() and the request.sendRedirect() method. when accessing the manager via manager/list everything works fine. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6420] - Loadbalancer mod_jk from 4.02 not working with TC 3.3
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=6420. 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=6420 Loadbalancer mod_jk from 4.02 not working with TC 3.3 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 14:19 --- getting the lastest Version ans a fresh recompile fixed the problem. Loadbalancing works great with Tomcat 3.3 Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6525] New: - When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored
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=6525. 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=6525 When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored Summary: When deploying a web-app (as WAR or directory under Web- Apps) complex security-constraint in web.xml is ignored Product: Tomcat 4 Version: 4.0.2 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using following rules to secure a app security-constraint web-resource-collection web-resource-nameSistema Quest - Área Segura/web- resource-name url-pattern/seguro/index.jsp/url-pattern url-pattern/seguro/categoria/*/url-pattern url-pattern/seguro/edicao/*/url-pattern url-pattern/seguro/entrevistado/*/url-pattern url-pattern/seguro/formulario/*/url-pattern url-pattern/seguro/itemFormulario/*/url-pattern url-pattern/seguro/tabela/*/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.CategoriaServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.EdicaoServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.EntrevistadoServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.FormularioServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.FormularioItemServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.ItemFormularioServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.TabelaItemServlet/url-pattern url- pattern/servlet/br.com.econet.forme.servlet.TabelaServlet/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namequestEditor/role-name role-namequestAdministrador/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameSistema Quest - Área Segura/web- resource-name url-pattern/seguro/*/url-pattern url-pattern/servlet/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namequestAdministrador/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint I get following error when conecting with role questEditor: Apache Tomcat/4.0.2 - HTTP Status 403 - Access to the requested resource has been denied type Status report message Access to the requested resource has been denied description Access to the specified resource (Access to the requested resource has been denied) has been forbidden. And see: I have configured an form-error-page for login-config: login-config auth-methodFORM/auth-method realm-nameSistema QUEST/realm-name form-login-config form-login-page/login.jsp/form-login-page form-error-page/loginErro.jsp/form-error-page /form-login-config /login-config The exactly same application described here works fine with HP-AS. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6525] - When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored
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=6525. 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=6525 When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 15:18 --- Created an attachment (id=1198) web.xml used with Catalina and HP-AS. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 5735] - HTTP connector running out ofprocessors under heavy load
On Sun, 17 Feb 2002, Bill Barker wrote: Yeah, well, I can confirm that o.a.c.connector.http.HttpConnector is just a broken as o.a.ajp.tc4.Ajp13Connector. However, the o.a.c.connector.http.HttpProcessor isn't quite as brain-dead as it's ajp13 counterpart (but it still doesn't recycle). The problem is that nothing handles dying threads. You may have better luck with o.a.jk ( aka jk2 ), as it's using the same threading code as in 3.3 and refactored, more environment friendly tc4 facades ( i.e. more recycling ). The code is not yet 'release quality', but with a bit of help it can get there soon and solve more problems. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 17, 2002 9:52 PM Subject: DO NOT REPLY [Bug 5735] - HTTP connector running out of processors under heavy load 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=5735. 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=5735 HTTP connector running out of processors under heavy load [EMAIL PROTECTED] changed: What|Removed |Added -- -- Severity|Major |Blocker Component|HTTP/1.1 Connector |Catalina Priority|Other |High Version|4.0.2 Beta 1|4.0.2 Final --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 05:52 --- Recategorizing bug, and upgrading priority. The 1 request - 1 new processor situation Glenn experienced could indeed be an important clue. -- 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]
DO NOT REPLY [Bug 6525] - When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored
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=6525. 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=6525 When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 17:09 --- Since the link is for /seguro/ and not /seguro/index.jsp, I've added url-pattern/seguro//url-pattern and now it's working. But should not the security be checked against /seguro/index.jsp since this is welcome file for that directory? Is not /seguro/ and /seguro/index.jsp synonims? Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jk2 logging
Hi, A quick proposal ( vote ? ): I would like to start using commons-logging in jk2. Right now it has println() style, but beeing able to benefit from the fine control that log4j ( and other loggers ) provides would help a lot. If nobody oposes, I will check in a current build of commons-logging ( with the option to override it for those who like downloading each individual dependency ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jk2 logging
A quick proposal ( vote ? ): I would like to start using commons-logging in jk2. Right now it has println() style, but beeing able to benefit from the fine control that log4j ( and other loggers ) provides would help a lot. If nobody oposes, I will check in a current build of commons-logging ( with the option to override it for those who like downloading each individual dependency ). +1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6494] - Tomcat 4.0.2 could not start from W2k service after adding webapps conf
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=6494. 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=6494 Tomcat 4.0.2 could not start from W2k service after adding webapps conf --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 18:08 --- Created an attachment (id=1200) This is the log file of today. There is a detail description on the topic website. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6494] - Tomcat 4.0.2 could not start from W2k service after adding webapps conf
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=6494. 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=6494 Tomcat 4.0.2 could not start from W2k service after adding webapps conf --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 18:21 --- Hi, Dear Remy, Thank you very much for your help. I have posted the log file of today. At the beginning of this test, I started up the server mannully by MS-DOS command startup. You can see that it worked correctly. At 2002-02-18 11:36:08 BrowseServlet: init, I shut down the server and then start up the server in the W2K service. It did start up. But I got a exception from the log. And I could NOT log on the web server even the Apache Tomcat 4.0 default directory: http://pc47094.utdallas.edu/ Seems there is a bug on the servlet part. Thanks again. Dayong -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6494] - Tomcat 4.0.2 could not start from W2k service after adding webapps conf
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=6494. 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=6494 Tomcat 4.0.2 could not start from W2k service after adding webapps conf --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 18:32 --- If the following code is deleted from server.xml file, the webserver works correctly. Realm className=org.apache.catalina.realm.JDBCRealm debug=99 digest=MD5 driverName=sun.jdbc.odbc.JdbcOdbcDriver connectionURL=jdbc:odbc:Authentication connectionName=ResearchDB connectionPassword=password userTable=users userNameCol=user_name userCredCol=user_pass userRoleTable=user_roles roleNameCol=role_name / But without Database connection, ResearchDB could not work anymore. Dayong -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
Remy Maucherat wrote: Hi, There's a hidden component in Tomcat 4 named service (package is org.apache.service), which has almost nothing to do with Tomcat (except it was written by Pier and started its life here). The most current version of it (which is *not* the one used by Tomcat, BTW) resides in the jakarta-tomcat-service repository (which I had completely forgotten until I saw JF recent commits). ;-) - I suddently noted it was not working with win9x and I needed some service on a win98 box - I think the service package would live a happier life in the commons (the base interfaces + the native code); then, we can update the HEAD branch to use the commons package. Note: In the commons, there's already a services component. To avoid creating confusion, I suggest renaming the service component to commons-daemon. Comments ? The idea in jakarta-tomcat-service is to implement JSR96 (http://jcp.org/jsr/detail/96.jsp). jakarta-tomcat-4.1/service is to allow run tomcat on port 80 as a daemon... Porting it to jakarta-tomcat-service could be the other option. Well, the Java code looks very similar to me. So the native code could easily be ported to j-t-s. It's just that this code is 100% Tomcat-dependency free. So since it's some generic capability other projects could want, I proposed to move it to the commons, instead of leaving it as a hidden Tomcat subproject. I can state in the commons proposal that it is supposed to implment JSR 96 (which doesn't seem very active to me). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1] Service
Well, the Java code looks very similar to me. So the native code could easily be ported to j-t-s. It's just that this code is 100% Tomcat-dependency free. So since it's some generic capability other projects could want, I proposed to move it to the commons, instead of leaving it as a hidden Tomcat subproject. I can state in the commons proposal that it is supposed to implment JSR 96 (which doesn't seem very active to me). Quick question. Do you know if this java service will allow us to add SIGNAL HANDLERS to Java processes, for example to be able to handle from java a SIGHUP signal sent by a cron task, to rotate the logs for examples ? It will be very very very very usefull in productions environnements -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
Any objection to see JkMount renamed to Jk2Mount in mod_jk2 and in general all Directive subject to collisions with the original mod_jk... The both could be installed at the same time ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
jean-frederic clere [EMAIL PROTECTED] wrote: The idea in jakarta-tomcat-service is to implement JSR96 (http://jcp.org/jsr/detail/96.jsp). jakarta-tomcat-4.1/service is to allow run tomcat on port 80 as a daemon... The Apache Software Foundation is voting NO on the publication of JSR-096, since the spec sucks, and we weren't able to make the spec lead come to an agreement. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
jean-frederic clere [EMAIL PROTECTED] wrote: The idea in jakarta-tomcat-service is to implement JSR96 (http://jcp.org/jsr/detail/96.jsp). jakarta-tomcat-4.1/service is to allow run tomcat on port 80 as a daemon... The Apache Software Foundation is voting NO on the publication of JSR-096, since the spec sucks, and we weren't able to make the spec lead come to an agreement. That makes sense. If the spec sucks, and the lead doesn't want to improve it, there's no reason to support it ;-) And would you support moving that code to the commons ? It has 0 dependencies with TC, plus it would broaden its audience. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
Remy Maucherat [EMAIL PROTECTED] wrote: jean-frederic clere [EMAIL PROTECTED] wrote: The idea in jakarta-tomcat-service is to implement JSR96 (http://jcp.org/jsr/detail/96.jsp). jakarta-tomcat-4.1/service is to allow run tomcat on port 80 as a daemon... The Apache Software Foundation is voting NO on the publication of JSR-096, since the spec sucks, and we weren't able to make the spec lead come to an agreement. That makes sense. If the spec sucks, and the lead doesn't want to improve it, there's no reason to support it ;-) And would you support moving that code to the commons ? It has 0 dependencies with TC, plus it would broaden its audience. Yes... No problems with that... Actually over there it has more visibility to Peter D. and Geir, who were my pals on JSR-096... I wrote a doc on why JSR-096 sucks, along with an alternative API (which is what a bunch of us on JSR-096 wanted but the spec lead didn't want to follow)... Do you want that? It has some more reviews up to date... (BTW, I don't follow this list much ATM - new job outside of the scope of Tomcat - so if you have something urgent just CC me as J.F. does :) Cheeri'os! Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
On Mon, 18 Feb 2002, GOMEZ Henri wrote: Any objection to see JkMount renamed to Jk2Mount in mod_jk2 and in general all Directive subject to collisions with the original mod_jk... I have one :-) If we change JkMount, I would rather change it into nothing ( i.e. get rid of it ). It should be in just for backward compatibility with jk1. I like this aproach to backward compatibility - i.e. including both the old code and the new code, sort of 'perfect' backward compat. Instead of JkMount we should use either Location path=/foo JkWebapp worker ajp13 /Location or jkurimap.properties - which is already used for IIS and has more 'potential' to support dynamic updates to the config ( without apache restart ). This way we'll have a consistent server-independent config ( properties ) and a server-optimized config ( location uses the internal mapper which is more optimized and we avoid duplicating the mapping ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Possible bug in 4.x HttpProcessor server port handling?
We've been debugging a problem in our application related to the port being
sent during a redirect. In our case, both the host and port requested will
be mapped on the way into and out of our network. We obviously need our
redirects to be sent with the correct server and port set, but we were
seeing only the host being sent back correctly in the redirect response.
After some time debugging, it seems that there is a bug in the
parseHeaders() method of org.apache.catalina.connector.http.HttpProcessor.
In that method, the host HTTP header is processed to set the server name
and port. According to the HTTP 1.1 Spec (section 14.23) A host without
any trailing port information implies the default port for the service
request (e.g., 80 for an HTTP URL). The parse headers code does not appear
to set the server port if the : is not found in the header and therefore
the port remains the original port specified on the connector.
It would seem that the current handling of the no-colon case should be
changed to something like this:
if (n 0) {
if (connector.getScheme().equals(http)) {
request.setServerPort(80);
} else if (connector.getScheme().equals(https)) {
request.setServerPort(443);
}
if (proxyName != null)
request.setServerName(proxyName);
else
request.setServerName(value);
} else { ...
After patching the source locally, this solves our proxy redirection
problems. It may be that bugzilla bug #5762 is related to this, although it
is kind of hard to tell.
Is this truly a bug as we believe? If so, can someone actually patch it
into CVS, as I don't have authority for such things.
Thanks,
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
On Mon, 18 Feb 2002, Remy Maucherat wrote: Well, the Java code looks very similar to me. So the native code could easily be ported to j-t-s. It's just that this code is 100% Tomcat-dependency free. So since it's some generic capability other projects could want, I proposed to move it to the commons, instead of leaving it as a hidden Tomcat subproject. +1 :-) If we are doing that, should we also move j-t-c/utils to commons ? My proposal would be to use a different package name, so we can start adding/improving the utils without nasty class compatibility problems for 3.3. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
On Mon, 18 Feb 2002, Remy Maucherat wrote: Well, the Java code looks very similar to me. So the native code could easily be ported to j-t-s. It's just that this code is 100% Tomcat-dependency free. So since it's some generic capability other projects could want, I proposed to move it to the commons, instead of leaving it as a hidden Tomcat subproject. +1 :-) If we are doing that, should we also move j-t-c/utils to commons ? My proposal would be to use a different package name, so we can start adding/improving the utils without nasty class compatibility problems for 3.3. Well, j-t-c/utils is more our core buisness. Since 4.0 or the connectors don't duplicate the code like 3.3 does, I'd say I don't like the idea too much. Or we can put them there, still keep the current ones, and start using the ones from the commons during the next release cycle. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6525] - When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored
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=6525. 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=6525 When deploying a web-app (as WAR or directory under Web-Apps) complex security-constraint in web.xml is ignored [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-02-18 19:49 --- No, the security will be tested for both (at least at the moment). It is not a bug, it's just something caused by how the welcome pages are implemented. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup BootstrapService.java CatalinaService.java
remm02/02/18 11:59:29
Modified:catalina/src/share/org/apache/catalina/startup
BootstrapService.java CatalinaService.java
Log:
- Refactoring of the service features, removing a lot of code duplication in the
process.
Revision ChangesPath
1.13 +31 -110
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java
Index: BootstrapService.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- BootstrapService.java 18 Feb 2002 09:00:54 - 1.12
+++ BootstrapService.java 18 Feb 2002 19:59:28 - 1.13
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
1.12 2002/02/18 09:00:54 remm Exp $
- * $Revision: 1.12 $
- * $Date: 2002/02/18 09:00:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
1.13 2002/02/18 19:59:28 remm Exp $
+ * $Revision: 1.13 $
+ * $Date: 2002/02/18 19:59:28 $
*
*
*
@@ -86,7 +86,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.12 $ $Date: 2002/02/18 09:00:54 $
+ * @version $Revision: 1.13 $ $Date: 2002/02/18 19:59:28 $
*/
public final class BootstrapService
@@ -97,15 +97,15 @@
/**
- * Debugging detail level for processing the startup.
+ * Service object used by main.
*/
-private static int debug = 0;
+private static Service service = null;
/**
- * Catalina instance.
+ * Debugging detail level for processing the startup.
*/
-private static Object catalina = null;
+private static int debug = 0;
/**
@@ -123,7 +123,7 @@
public void load(ServiceController controller, String arguments[])
throws Throwable {
-System.out.println(Create Catalina server);
+log(Create Catalina server);
// Set Catalina path
setCatalinaHome();
@@ -213,12 +213,11 @@
public void start()
throws Throwable {
-// Call the start() method
-if (debug = 1)
-log(Calling startup class start() method);
+log(Starting service);
String methodName = start;
Method method = catalinaService.getClass().getMethod(methodName, null);
method.invoke(catalinaService, null);
+log(Service started);
}
@@ -229,12 +228,11 @@
public void stop()
throws Throwable {
-// Call the stop() method
-if (debug = 1)
-log(Calling startup class stop() method);
+log(Stopping service);
String methodName = stop;
Method method = catalinaService.getClass().getMethod(methodName, null);
method.invoke(catalinaService, null);
+log(Service stopped);
}
@@ -243,7 +241,7 @@
/**
- * The main program for the bootstrap.
+ * Main method, used for testing only.
*
* @param args Command line arguments to be processed
*/
@@ -255,103 +253,26 @@
debug = 1;
}
-try {
-
-if (catalina == null) {
-
-System.out.println(Create Catalina server);
-
-// Construct the class loaders we will need
-ClassLoader commonLoader = null;
-ClassLoader catalinaLoader = null;
-ClassLoader sharedLoader = null;
-try {
-
-File unpacked[] = new File[1];
-File packed[] = new File[1];
-ClassLoaderFactory.setDebug(debug);
-
-unpacked[0] = new File(getCatalinaHome(),
- common + File.separator
- + classes);
-packed[0] = new File(getCatalinaHome(),
- common + File.separator + lib);
-commonLoader =
-ClassLoaderFactory.createClassLoader
-(unpacked, packed, null);
-
-unpacked[0] = new File(getCatalinaHome(),
- server + File.separator
- + classes);
-packed[0] = new File(getCatalinaHome(),
- server + File.separator + lib);
-
Re: [4.1] Service
Remy Maucherat [EMAIL PROTECTED] wrote: jean-frederic clere [EMAIL PROTECTED] wrote: The idea in jakarta-tomcat-service is to implement JSR96 (http://jcp.org/jsr/detail/96.jsp). jakarta-tomcat-4.1/service is to allow run tomcat on port 80 as a daemon... The Apache Software Foundation is voting NO on the publication of JSR-096, since the spec sucks, and we weren't able to make the spec lead come to an agreement. That makes sense. If the spec sucks, and the lead doesn't want to improve it, there's no reason to support it ;-) And would you support moving that code to the commons ? It has 0 dependencies with TC, plus it would broaden its audience. Yes... No problems with that... Actually over there it has more visibility to Peter D. and Geir, who were my pals on JSR-096... I wrote a doc on why JSR-096 sucks, along with an alternative API (which is what a bunch of us on JSR-096 wanted but the spec lead didn't want to follow)... Do you want that? It has some more reviews up to date... (BTW, I don't follow this list much ATM - new job outside of the scope of Tomcat - so if you have something urgent just CC me as J.F. does :) Ok, done. BTW, as I mentioned, there's already a 'services' component in commons. Are you ok with renaming the spec from service - daemon ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
On Mon, 18 Feb 2002, Remy Maucherat wrote: Well, j-t-c/utils is more our core buisness. Since 4.0 or the connectors don't duplicate the code like 3.3 does, I'd say I don't like the idea too much. Or we can put them there, still keep the current ones, and start using the ones from the commons during the next release cycle. Sounds like a better and safer idea :-) The problem is that I would like to make some changes to some utils, like remove the util.Log deps, do some improvements ( a much cleaner Notes for example ), etc. I don't want to destabilize the current code - but to gradually start using the new stuff when ready. So keeping the current 'frozen' version ( and keeping it in sync with 3.3 - which is also frozen as API, but does get fixes too ) is the perfect for me. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Upload file fails in IIS + Tomcat ...
Hi, I am using Oreilly's MultipartRequest class to upload files. I am using IIS + Tomcat configuration. If the file size is more than the limit I specify in the MultipartRequest object, Browser (IE 5.0, IE 4.0 says abnormally terminated by server) shows Error Page can not be displayed. If I try the same with Apache+Tomcat, it work fine ( Shows proper error on the browser that the file exceeding the limit). I am using Tomcat 4.0.2 with IIS 4.0 on Windows NT 4.0. Thanks, Kalyan. _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
altering the session cookie's path (Tomcat 4.0x)
Hi, I wanted to alter Tomcat's default behavior for setting the JSESSIONID cookie. Tomcat normally sets the path of this cookie to be equivalent of the webcontext if any, otherwise it sets it to /. Since I'll need to proxy request with Apache (with altering the URL's first part containing the web context) this kind of session cookie won't work. BTW I'll use each application with a different virtual host, so no conflict may arise from using the same path for all session cookies coming from my server. So I've downloaded the source distribution of Tomcat 4.0-dev (it was a nightly build of 15th of february). I changed the code and successfully created a binary distribution of Catalina with ant dist and ant deploy-catalina. I've run the application but was shocked to see that Catalina still sets the path to the webcontext... I've checked the source code and found only this class where the session cookie is manipulated: o.a.c.connector.HttpResponseBase (lines 642 sqq). Now I'm a bit puzzled about this... Does some of you see where I made a mistake? Thanks, Jnos -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP setup non-GUI
I am casting a wide net for help here. I recently started playing around with jsp and got stumped with this example here: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/JSPIntro2.html for my own sad reasons i can't get X-server to work on my server so I am trying to find the suitable command-line version to deploying war files and getting them to work without the GUI menus. The link above was a good example but doe not help at all for command line. I see other things like packeger command but the examples are not helpful. Can anyone plz check out the link above on setting up this jsp WAR file and deploying it but by just using the command line instead Please email me back at this email Thanks = -Fabian Raygosa That's very funny Scotty, now beam down my clothes! _ /|\ \|/ /|\ /_|_\ __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6531] New: - Request Dispatcher forward to j_security_check 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=6531. 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=6531 Request Dispatcher forward to j_security_check not working Summary: Request Dispatcher forward to j_security_check not working Product: Tomcat 4 Version: Nightly Build Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm trying to use the following concept to encrypt my password before authenticating (b/c password in db in encrypted). http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22257.html snip String req = j_security_check?j_username= + form.getUsername() + j_password= + StringUtil.encodeString(form.getPassword()); RequestDispatcher rd = request.getRequestDispatcher(req); rd.forward(request, response); /snip In Tomcat 4.0.1, 4.0.2 and the nightly build, this results in the following error: Apache Tomcat/4.0.1 - HTTP Status 404 - /j_security_check type Status report message /j_security_check description The requested resource (/j_security_check) is not available. This code works GREAT in Tomcat 3.2.4. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6531] - Request Dispatcher forward to j_security_check 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=6531. 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=6531 Request Dispatcher forward to j_security_check not working [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 02:24 --- Applications that try to reference the j_security_check URL by any means are guaranteed to be non-portable, because the spec only defines this URL as being significant when the *container* sends back the form login page. In fact, that is the way that Tomcat 4 implements it, so trying to use a request dispatcher to forward control to this page is not going to work, because the URL doesn't exist at that point in time (hence the 404 error). An alternative approach would be to subclass one of the existing Realm implementations and make it do the encoding for you before calling the real authenticate() method in its superclass. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6519] - Problem with HTMLManagerServlet when running JDK1.4
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=6519. 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=6519 Problem with HTMLManagerServlet when running JDK1.4 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 02:42 --- This works for me, using the final release version of JDK 1.4. Could you confirm this is the version you were using? Is there any chance that you have characters in your context paths that will not encode correctly in the ISO-8859-1 character encoding? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5735] - HTTP connector running out of processors under heavy load
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=5735. 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=5735 HTTP connector running out of processors under heavy load --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 04:42 --- I think we are getting close to identifying how this bug behaves. Everytime you get the following Exception: java.io.IOException: Broken pipe at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:96) at org.apache.ajp.Ajp13.send(Ajp13.java:525) at org.apache.ajp.RequestHandler.finish(RequestHandler.java:496) at org.apache.ajp.Ajp13.finish(Ajp13.java:395) at org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:192) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:453) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:540) at java.lang.Thread.run(Thread.java:484) Ajp13Connection spawns a new Ajp13Processor, if you have reached maxProccessors, a connection is rejected. In a long test run I am doing I see this maybe once an hour. A bunch of the above exceptions, with an identical number of attempts to spawn a new Ajp13Processor. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1] Service
On Mon, 18 Feb 2002, Remy Maucherat wrote: Well, j-t-c/utils is more our core buisness. Since 4.0 or the connectors don't duplicate the code like 3.3 does, I'd say I don't like the idea too much. Or we can put them there, still keep the current ones, and start using the ones from the commons during the next release cycle. Sounds like a better and safer idea :-) +1 then. The problem is that I would like to make some changes to some utils, like remove the util.Log deps, do some improvements ( a much cleaner Notes for example ), etc. I don't want to destabilize the current code - but to gradually start using the new stuff when ready. So keeping the current 'frozen' version ( and keeping it in sync with 3.3 - which is also frozen as API, but does get fixes too ) is the perfect for me. Yes, it's the most reasonable. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Daemon] New commons component
Hi, I've added a new component to the commons subproject (in the sandbox), which is designed to allow Java programs to run as native operating system daemons (services under Windows NT). Because of its nature, this component contains a significant amount of native code. This component API and Unix code was developed by Pier Fumagalli as part of the Tomcat 4 project, but is fully generic and not tied in any way to Tomcat, so other server side applications may find it useful. The NT service code and related utilities were written by Jean-Frederic Clere. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5735] - HTTP connector running out of processors under heavy load
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=5735. 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=5735 HTTP connector running out of processors under heavy load --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 06:21 --- Interesting, but looking at the code, I don't see any problem it would cause (the exception gets caught right away, and the processor should get recycled normally; I don't see any side effect or problems it would cause). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: altering the session cookie's path (Tomcat 4.0x): RESOLVED
Hi, after some time I've found that the session cookie is set in the AJP connector, namely in org.apache.ajp.tomcat4.AJP13Response (method sendHeaders()). Actually to my surprise o.a.c.connector.HttpResponseBase#sendHeaders() is called only when the first resource is asked for (that's what I saw), it's not called thereafter any more. Now everything is working like charm. I have a few questions re this solution: 1. since it's my modification of the tomcat code, naturally it will not be present in any forthcoming tomcat versions - so I'll have to patch each tomcat version before use (something I always tried to avoid) 2. where and how can I initiate that this modification (or a similar one) be applied to the official tomcat source? 3. although my solution is merely an ad hoc one, I can think of a more robust solution to the problem: this behavior of tomcat (what path it generates in the session cookie) should be governed by some configuration properties and not be hardwired in code (the current official code is not flexible enough, since it always sets the path to be equivalent with the application context if any). Cheers, Jnos |-Original Message- |From: Jarecsni Jnos [mailto:[EMAIL PROTECTED]] |Sent: Saturday, February 16, 2002 8:01 PM |To: Tomcat Developers List |Subject: altering the session cookie's path (Tomcat 4.0x) | | |Hi, | |I wanted to alter Tomcat's default behavior for setting the JSESSIONID |cookie. Tomcat normally sets the path of this cookie to be |equivalent of the |webcontext if any, otherwise it sets it to /. [...] | |I've run the application but was shocked to see that Catalina |still sets the |path to the webcontext... I've checked the source code and found only this |class where the session cookie is manipulated: |o.a.c.connector.HttpResponseBase (lines 642 sqq). | |Now I'm a bit puzzled about this... Does some of you see where I made a |mistake? | -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2 logging
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 18, 2002 10:00 AM Subject: Jk2 logging Hi, A quick proposal ( vote ? ): I would like to start using commons-logging in jk2. Right now it has println() style, but beeing able to benefit from the fine control that log4j ( and other loggers ) provides would help a lot. If nobody oposes, I will check in a current build of commons-logging ( with the option to override it for those who like downloading each individual dependency ). +1 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]
Re: Difference between Tomcat-3.2.1 and Tomcat-3.3a
This is better handled at [EMAIL PROTECTED] . The simple answer is that 3.3a (and even more so 3.3.1-B1), should be better able to handle chinese (or other than iso-latin-1) character sets than 3.2.x. Of course, you must specify the charset in the ContentType attribute to the @page directive on your JSP page. If you still have a problem, please post a bug report to http://nagoya.apache.org/bugzilla. - Original Message - From: Jasmine Wong [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Monday, February 18, 2002 1:46 AM Subject: Difference between Tomcat-3.2.1 and Tomcat-3.3a I need to know what is the main difference between Tomcat-3.2.1 and Tomcat-3.3a ?? Because when I try to view my jsp page in chinese characters, using the HTML header, I can view the characters correctly, but because Tomcat-3.3a offers a newer version of JDBC API, as a result i change to Tomcat-3.3a. But now I can't view the information in chinese characters anymore. -- 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: [Daemon] New commons component
Remy, This is great news! I scanned through the Unix code and noticed that it uses the chmod'ing executables with setuid bits instead of performing a JNI call to the setuid() and seteuid() C functions before and after binding of a ServerSocket (i.e. the place you should need root access if you are binding to ports 1 through 1024). This type of approach eliminates the need for a controller and slave process. If there is interest out there, I can work up a proposal for implementing this type of setuid functionality. I has been a year or two since I did my last JNI coding, but I should be able to dig up some setuid code that I have done in the past. Thanks, Patrick Remy Maucherat wrote: Hi, I've added a new component to the commons subproject (in the sandbox), which is designed to allow Java programs to run as native operating system daemons (services under Windows NT). Because of its nature, this component contains a significant amount of native code. This component API and Unix code was developed by Pier Fumagalli as part of the Tomcat 4 project, but is fully generic and not tied in any way to Tomcat, so other server side applications may find it useful. The NT service code and related utilities were written by Jean-Frederic Clere. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Daemon] New commons component
Patrick Luby wrote: Remy, This is great news! I scanned through the Unix code and noticed that it uses the chmod'ing executables with setuid bits instead of performing a JNI call to the setuid() and seteuid() C functions before and after binding of a ServerSocket (i.e. the place you should need root access if you are binding to ports 1 through 1024). This type of approach eliminates the need for a controller and slave process. If there is interest out there, I can work up a proposal for implementing this type of setuid functionality. I has been a year or two since I did my last JNI coding, but I should be able to dig up some setuid code that I have done in the past. There is interest out there! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2 logging
[EMAIL PROTECTED] wrote: Hi, A quick proposal ( vote ? ): I would like to start using commons-logging in jk2. Right now it has println() style, but beeing able to benefit from the fine control that log4j ( and other loggers ) provides would help a lot. If nobody oposes, I will check in a current build of commons-logging ( with the option to override it for those who like downloading each individual dependency ). +1 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 6519] - Problem with HTMLManagerServlet when running JDK1.4
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=6519. 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=6519 Problem with HTMLManagerServlet when running JDK1.4 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-02-19 08:11 --- As far as I am concerned, it is a JDK bug (and I suppose it only happens on Windows). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
