DO NOT REPLY [Bug 22737] New: - LogConfigurationException when using Tomcat 4.1.27 SSL, common/log
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=22737. 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=22737 LogConfigurationException when using Tomcat 4.1.27 SSL, common/log Summary: LogConfigurationException when using Tomcat 4.1.27 SSL, common/log Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Similar if not the same as Bug 22701 Similar to http://www.mail-archive.com/tomcat- [EMAIL PROTECTED]/msg101022.html NON-SSL works fine, http I have not found a workaround for this problem. When I use https://, tomcat crashes at ramdom times, there are no patterns to the problem. Do I need to set a paramenter in the config file to get SSL to work without that LogConfigurationException. Should I use a different version of Tomcat? Aug 26, 2003 3:41:08 PM org.apache.coyote.http11.Http11Protocol$Http11Connection Handler processConnection SEVERE: Error reading request, ignored org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging .LogConfigurationException: org.apache.commons.logging.LogConfigurationException : Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactory Impl.java:532) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactory Impl.java:272) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactory Impl.java:246) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395) at org.apache.tomcat.util.net.jsse.JSSESupport.init(JSSESupport.java:8 7) at org.apache.tomcat.util.net.jsse.JSSE14Support.init(JSSE14Support.ja va:99) at org.apache.tomcat.util.net.jsse.JSSE14Factory.getSSLSupport(JSSE14Fac tory.java:84) at org.apache.tomcat.util.net.jsse.JSSEImplementation.getSSLSupport(JSSE Implementation.java:118) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ssConnection(Http11Protocol.java:385) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java :565) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.comm ons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk 14Logger does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogF actoryImpl.java:416) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactory Impl.java:525) ... 11 more Caused by: org.apache.commons.logging.LogConfigurationException: Class org.apach e.commons.logging.impl.Jdk14Logger does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogF actoryImpl.java:412) ... 12 more Config file: !-- Example Server Configuration File -- !-- Note that component elements are nested corresponding to their parent-child relationships with each other -- !-- A Server is a singleton element that represents the entire JVM, which may contain one or more Service instances. The Server listens for a shutdown command on the indicated port. Note: A Server is not itself a Container, so you may not define subcomponents such as Valves or Loggers at this level. -- Server port=8005 shutdown=SHUTDOWN debug=0 !-- Uncomment these entries to enable JMX MBeans support -- Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ !-- Global JNDI resources -- GlobalNamingResources !-- Test entry for demonstration purposes -- Environment name=simpleValue type=java.lang.Integer value=30/ !-- Editable user database that can also be used by UserDatabaseRealm to authenticate users -- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved /Resource ResourceParams name=UserDatabase parameter namefactory/name valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value /parameter parameter namepathname/name valueconf/tomcat-users.xml/value /parameter /ResourceParams /GlobalNamingResources !-- A Service is a collection of one
DO NOT REPLY [Bug 12218] - GetAttribute returns Null
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=12218. 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=12218 GetAttribute returns Null [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-26 19:05 --- I have checked this with the HEAD of 4.1 and 5.0 and both work using the following code snippet in the jsp page. %@ page import=java.security.cert.* % % X509Certificate[] certChain; X509Certificate clientCert; java.security.Principal userDN; certChain = (X509Certificate[])request.getAttribute (javax.servlet.request.X509Certificate); clientCert = certChain[0]; userDN = clientCert.getSubjectDN(); out.println(PSubject distinguished name is: + userDN + /P); out.println(pgetRemoteUser() returns: + request.getRemoteUser() + /P); % Your suspicion that your custom SSL factory might be the root cause would appear to be correct. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk2 locks up under load
This is a little tricky to reproduce but... Apache 2.0.45 Tomcat 4.1.24 (or .27 for that matter) mod_jk2 2.0.2 everything built and running on Solaris 2.8 Connect all machines using a 100 Mbit switch or something fast. Create two instances of tomcat with Coyote AJP 13 connectors where enableLookups is false and connectionTimeout is 0. Use jvmRoutes of portal1 and portal2. Under the webapps/ROOT directory create a set of files of various sizes like: SIZE (BYTES) FILE NAME - 128 128.txt 256 256.txt 512 512.txt 1024 1024.txt 2048 2048.txt 4096 4096.txt Set up your Apache with a basic httpd.conf and workers.properties like those included. Use the load generating script and Java app like that included with a command line like ./test.sh 40 200 http://myserver:myport To create 40 threads each creating 200 requests for a paricular file from the given URL. You may choose to monitor the server-status apache page (mod_status) and look for frozen 'W' slots. The test script may sometimes run to completion without problems but more often than not it fails to complete and locks up. At some point the tomcat(s) become saturated and run out of threads (message sent to log for tomcat): [java] SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status75 75 Accompanying this the mod_jk2 in the Apache starts to block on reading headers from AJP13 responses (the send of the request works, the read for the header of the response blocks indefinitely). mod_jk does not exhibit this behavior. Setting connectionTimeout on the Coyote endpoint prevents the lockup but there is definitely inconsistent performance as the connections timeout. stuff.tar.gz stuff.tar.gz Description: stuff.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] jakarta-servletapi-5: schema updates
Hi, The attached file is to fix the bug in the Servlet 2.4 deployment descriptor schema file. jsr154/share/dtd/web-app_2_4.xsd The name in xsd:key,xsd:keyref, and xsd:unique must be unique within the j2ee namespace. Thank you, Yutaka Yoshida Sun Microsystems Index: jsr154/src/share/dtd/web-app_2_4.xsd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/src/share/dtd/web-app_2_4.xsd,v retrieving revision 1.11 diff -u -r1.11 web-app_2_4.xsd --- jsr154/src/share/dtd/web-app_2_4.xsd16 May 2003 23:20:18 - 1.11 +++ jsr154/src/share/dtd/web-app_2_4.xsd26 Aug 2003 20:53:03 - @@ -126,7 +126,7 @@ /xsd:documentation /xsd:annotation -xsd:unique name=servlet-name-uniqueness +xsd:unique name=web-app-servlet-name-uniqueness xsd:annotation xsd:documentation @@ -139,7 +139,7 @@ xsd:fieldxpath=j2ee:servlet-name/ /xsd:unique -xsd:unique name=filter-name-uniqueness +xsd:unique name=web-app-filter-name-uniqueness xsd:annotation xsd:documentation @@ -152,7 +152,7 @@ xsd:fieldxpath=j2ee:filter-name/ /xsd:unique -xsd:unique name=ejb-local-ref-name-uniqueness +xsd:unique name=web-app-ejb-local-ref-name-uniqueness xsd:annotation xsd:documentation @@ -170,7 +170,7 @@ xsd:fieldxpath=j2ee:ejb-ref-name/ /xsd:unique -xsd:unique name=ejb-ref-name-uniqueness +xsd:unique name=web-app-ejb-ref-name-uniqueness xsd:annotation xsd:documentation @@ -188,7 +188,7 @@ xsd:fieldxpath=j2ee:ejb-ref-name/ /xsd:unique -xsd:unique name=resource-env-ref-uniqueness +xsd:unique name=web-app-resource-env-ref-uniqueness xsd:annotation xsd:documentation @@ -204,7 +204,7 @@ xsd:fieldxpath=j2ee:resource-env-ref-name/ /xsd:unique -xsd:unique name=message-destination-ref-uniqueness +xsd:unique name=web-app-message-destination-ref-uniqueness xsd:annotation xsd:documentation @@ -220,7 +220,7 @@ xsd:fieldxpath=j2ee:message-destination-ref-name/ /xsd:unique -xsd:unique name=res-ref-name-uniqueness +xsd:unique name=web-app-res-ref-name-uniqueness xsd:annotation xsd:documentation @@ -235,7 +235,7 @@ xsd:fieldxpath=j2ee:res-ref-name/ /xsd:unique -xsd:unique name=env-entry-name-uniqueness +xsd:unique name=web-app-env-entry-name-uniqueness xsd:annotation xsd:documentation @@ -251,7 +251,7 @@ xsd:fieldxpath=j2ee:env-entry-name/ /xsd:unique -xsd:key name=role-name-key +xsd:key name=web-app-role-name-key xsd:annotation xsd:documentation @@ -264,8 +264,8 @@ xsd:fieldxpath=j2ee:role-name/ /xsd:key -xsd:keyref name=role-name-references - refer=j2ee:role-name-key +xsd:keyref name=web-app-role-name-references + refer=j2ee:web-app-role-name-key xsd:annotation xsd:documentation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22388] - TC 5.0.7 Startup Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22388. 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=22388 TC 5.0.7 Startup Exception --- Additional Comments From [EMAIL PROTECTED] 2003-08-26 23:11 --- If tomcat ships with broken code .. are you saying that is not a tomcat issue ? All I am asking is when will it be fixed ? I dont think that is asking too much. Why such a 'short' answer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Remy - 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]
[Fwd: Re: [VOTE] 5.0.9 stability rating]
resend again. my email's been getting lost for some reason. Original Message Subject: Re: [VOTE] 5.0.9 stability rating Date: Tue, 26 Aug 2003 16:11:35 -0700 From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Remy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
servlets...
To: Developer Support I'm not exactly sure, but I'm bascally trying to compile a servlet and I'm constantly receive an error. I've never encounted this problem before when compiling servlets, but maybe you can help: test.java:2: package import javax.servlet.http.*; Following this error, I receive several occurences of: Test01Servlet.java:8: cannot resolve symbol symbol : class HttpServletRequest location: class TestingServlet public void doGet(HttpServletRequest request, Does the problem lie in how I have my variable set. My platform is Win2K. Any help would be greatly appreciated. Thanks. - Dwayne __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspConfig.java
kinman 2003/08/26 17:47:19
Modified:jasper2/src/share/org/apache/jasper JspC.java
jasper2/src/share/org/apache/jasper/compiler JspConfig.java
Log:
- When precompiling with JSPC, files that mathch the url-pattern specified
in jsp-config should be included for compilation.
Revision ChangesPath
1.58 +12 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- JspC.java 12 Aug 2003 19:40:17 - 1.57
+++ JspC.java 27 Aug 2003 00:47:19 - 1.58
@@ -776,7 +776,7 @@
* Locate all jsp files in the webapp. Used if no explicit
* jsps are specified.
*/
-public void scanFiles( File base ) {
+public void scanFiles( File base ) throws JasperException {
Stack dirs = new Stack();
dirs.push(base);
if (extensions == null) {
@@ -798,12 +798,14 @@
dirs.push(f2.getPath());
//System.out.println(++ + f2.getPath());
} else {
+String path = f2.getPath();
+String uri = path.substring(uriRoot.length());
ext = files[i].substring(files[i].lastIndexOf('.')
+ 1);
-if (extensions.contains(ext)) {
+if (extensions.contains(ext) ||
+jspConfig.isJspPage(uri)) {
//System.out.println(s + ? + files[i]);
-pages.addElement(s + File.separatorChar
- + files[i]);
+pages.addElement(path);
} else {
//System.out.println(not done: + ext);
}
@@ -831,6 +833,9 @@
locateUriRoot( firstJspF );
}
+ if( context==null )
+ initServletContext();
+
// No explicit page, we'll process all .jsp in the webapp
if (pages.size() == 0) {
scanFiles( new File( uriRoot ));
@@ -845,9 +850,6 @@
throw new JasperException(
Localizer.getMessage(jsp.error.jspc.uriroot_not_dir));
}
-
- if( context==null )
- initServletContext();
initWebXml();
1.12 +61 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java
Index: JspConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JspConfig.java31 Jul 2003 18:51:16 - 1.11
+++ JspConfig.java27 Aug 2003 00:47:19 - 1.12
@@ -208,12 +208,7 @@
}
}
-/**
- * Find a property that best matches the supplied resource.
- * @param uri the resource supplied.
- * @return a JspProperty if a match is found, null otherwise
- */
-public JspProperty findJspProperty(String uri) throws JasperException {
+private void init() throws JasperException {
if (!initialized) {
processWebDotXml(ctxt);
@@ -223,6 +218,16 @@
null, null, null);
initialized = true;
}
+}
+
+/**
+ * Find a property that best matches the supplied resource.
+ * @param uri the resource supplied.
+ * @return a JspProperty indicating the best match, or some default.
+ */
+public JspProperty findJspProperty(String uri) throws JasperException {
+
+ init();
// JSP Configuration settings do not apply to tag files
if (jspProperties == null || uri.endsWith(.tag)
@@ -362,6 +367,53 @@
return new JspProperty(isXml, isELIgnored, isScriptingInvalid,
pageEncoding, includePreludes, includeCodas);
+}
+
+/**
+ * To find out if an uri matches an url pattern in jsp config. If so,
+ * then the uri is a JSP page. This is used primarily for jspc.
+ */
+public boolean isJspPage(String uri) throws JasperException {
+
+init();
+if (jspProperties == null) {
+return false;
+}
+
+String uriPath = null;
+int index = uri.lastIndexOf('/');
+if (index =0 ) {
+uriPath = uri.substring(0, index+1);
+}
+
DO NOT REPLY [Bug 22734] New: - Error combining jsp:forward and response.encodeURL()
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=22734. 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=22734 Error combining jsp:forward and response.encodeURL() Summary: Error combining jsp:forward and response.encodeURL() Product: Tomcat 4 Version: 4.1.27 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In my web application I have index.jsp forwarding to a struts action using the following: [EMAIL PROTECTED] contentType=text/html% %String forwardTo = response.encodeURL(/home.do);% jsp:forward name=%=forwardTo%/ When a client first visits the site they get a 404 error stating resource not found indicating that 'home.do;jsessionid=yadda yadda' could not be located. If the user hits reload, the page displays appropriately. I found a post on comp.lang.java.programmer from an Emery Z. Balint Jr., dated 8/10/03, complaining of a similar problem. In an email exchange he said he was able to fix the problem by shutting off URL rewriting - a problem if the client is a browser with cookies disabled. It appears that both of our situations are similar. Here is a synopsis of the hypothesis I developed in an our email exchange: I removed the call to response.encodeURL() and the problem went away. Interestingly enough, I use encodeURL exclusively elsewhere in my application. I do not encounter the same problem except in this instance where encodeURL is combined with a forward. I anticipate that this is a result of the sequence of events that the servlet container goes through in establishing a session. Perhaps a session is not fully registered until the completion of the first request-response cycle. This would mean that the forward is trying to access a session object whose existence is not yet known to the rest of the servlet container. The forward fails, but at the close of the transaction the session is fully created/registered/recognized, so the reload works. And his response: Very interesting, you could be correct as to what is happening. Same for me as well, no where else did the error occur, except for that first time. Mr. Balint and I are both using J2SE 1.4.1_02 and Tomcat 4.1.27. I do not know whether he is using Struts as well, though this seems immaterial. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21795] - j_security_check isn't fed through filters
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=21795. 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=21795 j_security_check isn't fed through filters --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 00:52 --- I received a clarification from Yutaka Yoshida (lead for the 2.4 spec) with this clarification: In regards to this issue, servlet EG had a consensus that Filter must not be applied for j_security_check. We believe the application component should not be involved in the container-managed security. Although we understand why people are using filter to manipulate the authentication mechanism, it doesn't solve all issues related to the security and must be addressed in a larger scope of the portable authentication mechanism, which I expect to have in the next version of the specification. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP address Assignment problem
Thank you for your help, I think this is a bug in TOMCAT running on Windows 2000 and XP. The same config works fine on NT. I have even setup Tomcat to run on 127.0.0.1:80 (loopback) and IIS to run on the real network address 192.168.1.100:80 on the same machine and it works just fine. Any help is much appreciated. From: Reshat Sabiq [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Sun, 24 Aug 2003 19:31:01 -0500 J Raf wrote: The machine is configured with different IP addresses. IIS was running on a differnt IP address then Tomcat. Both Tomcat on IIS were running on port 80. Using the IIS adminnstration module you can specify which IP address IiS should run on. Thank you for your help. From: Reshat Sabiq [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Sat, 23 Aug 2003 13:16:31 -0500 Ayoub Raffoul wrote: Hello, I'm running Apache Tomcat ver. 4.1 on a Windows 2000 server. The machine has multipe IP addresses. I have configured Apache Tomcat in server.xml to run on a specific IP address port 80 as follows (fake IP address): Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true address=205.200.21.30/ I also need to run IIS on the same machine though on a different IP IE: 205.200.21.31 and port 80. Each time I try to launch IIS I get an error message saying port is in use. If I shut down Tomcat then the port get released and I'm able to launch Tomcat. It seems that Tomcat is reserving all ports # 80 for all IP addresses on this machine. This configuration was working correctly in an older version of Tomcat. Even though Tomcat seems to be reserving all port 80 for all IP addresses it is only responding to 205.200.21.30. Vice Versa is also a problem. If I shut down Tomcat and start IIS on 205.200.21.31:80, Tomcat will no longer launch on 205.200.21.30:80. It will report that the port is in use. Has anybody encountered a similar issue? Your help is highly appreciated. Thank you ___ A port denotes an application, so i'm suprised you were previously able to have 2 applications on the same machine on the same port. In other words, the OS needs be aware and support different-IP-same-port distinction. I don't know if Win or others do that. -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s OK, i remember reading somewhere that Win can be configured for 2 IPs. I think it may be a problem with the networking setup on that machine. My guess is that the machine's OS (TCP/IP stack in particular) isn't aware that you intend to use 2 IPs, and probably needs to be set up accordingly using some applet. Sorry, not really much help... -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22734] - Error combining jsp:forward and response.encodeURL()
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=22734. 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=22734 Error combining jsp:forward and response.encodeURL() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 01:29 --- The argument to jsp:forward (and jsp:include) should not be encoded. encodeURL is for use with sendRedirect or for anchor tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: servlets...
Need Servlet.jar in %TOMCAT_HOME%/lib/common -Martin - Original Message - From: Dwayne Oxford [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 1:32 PM Subject: servlets... To: Developer Support I'm not exactly sure, but I'm bascally trying to compile a servlet and I'm constantly receive an error. I've never encounted this problem before when compiling servlets, but maybe you can help: test.java:2: package import javax.servlet.http.*; Following this error, I receive several occurences of: Test01Servlet.java:8: cannot resolve symbol symbol : class HttpServletRequest location: class TestingServlet public void doGet(HttpServletRequest request, Does the problem lie in how I have my variable set. My platform is Win2K. Any help would be greatly appreciated. Thanks. - Dwayne __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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: IP address Assignment problem
server.xml: port=80 What is your port spec in server.xml? -Martin - Original Message - From: J Raf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 6:16 PM Subject: Re: IP address Assignment problem Thank you for your help, I think this is a bug in TOMCAT running on Windows 2000 and XP. The same config works fine on NT. I have even setup Tomcat to run on 127.0.0.1:80 (loopback) and IIS to run on the real network address 192.168.1.100:80 on the same machine and it works just fine. Any help is much appreciated. From: Reshat Sabiq [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Sun, 24 Aug 2003 19:31:01 -0500 J Raf wrote: The machine is configured with different IP addresses. IIS was running on a differnt IP address then Tomcat. Both Tomcat on IIS were running on port 80. Using the IIS adminnstration module you can specify which IP address IiS should run on. Thank you for your help. From: Reshat Sabiq [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Sat, 23 Aug 2003 13:16:31 -0500 Ayoub Raffoul wrote: Hello, I'm running Apache Tomcat ver. 4.1 on a Windows 2000 server. The machine has multipe IP addresses. I have configured Apache Tomcat in server.xml to run on a specific IP address port 80 as follows (fake IP address): Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true address=205.200.21.30/ I also need to run IIS on the same machine though on a different IP IE: 205.200.21.31 and port 80. Each time I try to launch IIS I get an error message saying port is in use. If I shut down Tomcat then the port get released and I'm able to launch Tomcat. It seems that Tomcat is reserving all ports # 80 for all IP addresses on this machine. This configuration was working correctly in an older version of Tomcat. Even though Tomcat seems to be reserving all port 80 for all IP addresses it is only responding to 205.200.21.30. Vice Versa is also a problem. If I shut down Tomcat and start IIS on 205.200.21.31:80, Tomcat will no longer launch on 205.200.21.30:80. It will report that the port is in use. Has anybody encountered a similar issue? Your help is highly appreciated. Thank you ___ A port denotes an application, so i'm suprised you were previously able to have 2 applications on the same machine on the same port. In other words, the OS needs be aware and support different-IP-same-port distinction. I don't know if Win or others do that. -- Sincerely, Reshat. - -- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s OK, i remember reading somewhere that Win can be configured for 2 IPs. I think it may be a problem with the networking setup on that machine. My guess is that the machine's OS (TCP/IP stack in particular) isn't aware that you intend to use 2 IPs, and probably needs to be set up accordingly using some applet. Sorry, not really much help... -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - 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: Re: [VOTE] 5.0.9 stability rating]
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 5:15 PM Subject: [Fwd: Re: [VOTE] 5.0.9 stability rating] resend again. my email's been getting lost for some reason. Well, at least SOBIG is only around for another two weeks :). Original Message Subject: Re: [VOTE] 5.0.9 stability rating Date: Tue, 26 Aug 2003 16:11:35 -0700 From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? I believe that it is simply not implemented yet. Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Remy - 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] - 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]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSESupport.java
billbarker2003/08/26 19:28:14
Modified:util/java/org/apache/tomcat/util/net/jsse JSSESupport.java
Log:
Fix typo.
Revision ChangesPath
1.7 +1 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Index: JSSESupport.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JSSESupport.java 15 May 2003 18:35:26 - 1.6
+++ JSSESupport.java 27 Aug 2003 02:28:14 - 1.7
@@ -84,7 +84,7 @@
*/
class JSSESupport implements SSLSupport {
-private org.apache.commons.logging.Log log =
+private static org.apache.commons.logging.Log log =
org.apache.commons.logging.LogFactory.getLog(JSSESupport.class);
protected SSLSocket ssl;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSESupport.java
billbarker2003/08/26 19:29:06
Modified:util/java/org/apache/tomcat/util/net/jsse Tag: coyote_10
JSSESupport.java
Log:
Port patch.
Revision ChangesPath
No revision
No revision
1.3.2.3 +1 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Index: JSSESupport.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESupport.java,v
retrieving revision 1.3.2.2
retrieving revision 1.3.2.3
diff -u -r1.3.2.2 -r1.3.2.3
--- JSSESupport.java 21 Aug 2003 05:14:39 - 1.3.2.2
+++ JSSESupport.java 27 Aug 2003 02:29:06 - 1.3.2.3
@@ -84,7 +84,7 @@
*/
class JSSESupport implements SSLSupport {
-private org.apache.commons.logging.Log log =
+private static org.apache.commons.logging.Log log =
org.apache.commons.logging.LogFactory.getLog(JSSESupport.class);
protected SSLSocket ssl;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Remy - 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]
problem with start/stop of CoyoteConnector
Overview: CoytoteConnector.start()/stop() are misbehaving on tomcat-4.1.27
a) the org.apache.coyote.http11.Http11Protocol handler will _not_
start() successfully after I've stop()ped it.
b) the org.apache.jk.server.JkCoyoteHandler handler will start() after
a stop() but after a number of stop()/start() cycles, it fails to
start successfully.
In both cases, the connector thinks the handler isAvailable(), but
there is simply no service being offered on the specified port. nada.
Is this a known issue with the connector/handler interaction? A quick
perusal of the source did not lead me to a quick answer, and I won't
have any real time to dig into the problem until after the project
is complete (a couple of months away), so I'm asking y'all.
Details:
I've got apache/mod_jk setup to loadbalance with a pool of tomcats as
shown below.
(Round Robin DNS)
___
A1 A2A3
/--\---/--\--/--\ -- mod_jk lb worker balancing/session affinity
T1P | T2P |T3P | -- primary Tomcat Services
| | |
T1ST2S T3S -- secondary tomcat Services
On each of the T.P (primary) tomcats, I have a Valve that verifies a
connection to an external data source (proprietary CMS thingie), and when
it fails, it does a CoyoteConnector.stop() for the Jk handler, sends a
redirect back thru the DNS layer, so it will get another tomcat that has
a valid connection to the external data source.
All of this appeared to work as intended, so I wrote a quickie JSP to
let the client to restart the downed connectors which were stop()ped
due to the external data source becoming unavailable. At this point I
noticed that issuing a stop()/start() sequence to the http11 connector
caused the http11 connector to not _really_ restart (and listen for
connections). Having seen this issue is only allowed the Jk connector
to be managed via this JSP. After a handful of stop()/start() cycles
on the Jk handler, I noticed that the Jk connector wasn't really listening
for connections while the CoyoteConnector thought is was available.
In addition to this, the misbehaving handlers are not properly
reinitialized (to listen for conns) even when reloading the context
via the /manager/ interface.
Can anyone offer any possible solution to this? It is _not_ critical,
as the client can easily restart the tomcats one at a time if this
situation arises in production. I'm mostly wanting to see this bug
squashed :-)
FWIW, I've attached the JSP that handles the restarting of downed
services.
cheers.
b
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
%@ page import=
org.apache.catalina.*,
org.apache.catalina.core.*,
org.apache.coyote.tomcat4.CoyoteConnector
%
%
StandardServer server = (StandardServer)ServerFactory.getServer();
Service[] services = server.findServices();
%
html
head
link rel=stylesheet type=text/css href=style/admin.css /
/head
body
table class=datatable
tr
td class=datatable-header
Service
/td
td class=datatable-header
Handler
/td
td class=datatable-header
Port
/td
td class=datatable-header
Start
/td
td class=datatable-header
Stop
/td
td class=datatable-header
Restart
/td
/td
%
for( int i = 0; i services.length; ++i ){
StandardService service = (StandardService)services[i];
//try {
// service.stop();
// service.start();
//}
//catch( Exception ex ){
//
//}
Connector[] connectors = service.findConnectors();
for( int j = 0; j connectors.length; ++j ){
try {
Connector connector_c = connectors[j];
CoyoteConnector connector = (CoyoteConnector)connector_c;
if(
org.apache.jk.server.JkCoyoteHandler.equals(connector.getProtocolHandlerClassName())
){
if( request.getParameter(cmd) != null ){
if( service.toString().equals(request.getParameter(service))
connector.toString().equals(request.getParameter(connector))
){
if( start.equals(request.getParameter(cmd)) ){
if( ! connector.isAvailable() ){
try{
connector.start();
}
catch( Exception ex ){
ex.printStackTrace();
}
}
}
else if( stop.equals(request.getParameter(cmd)) ){
if( connector.isAvailable() ){
connector.stop();
}
}
else if( restart.equals(request.getParameter(cmd)) ){
if( connector.isAvailable() ){
try {
connector.stop();
}
catch( Exception ex ){
ex.printStackTrace();
DO NOT REPLY [Bug 22588] - large file uploads fail with server not found error
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=22588. 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=22588 large file uploads fail with server not found error --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 06:58 --- Socketclose delay did not work, but the CoyoteConnector2 does. Perhaps there is some HTTP protocol logging I can turn on? I thought that this was a relatively simply matter of making sure that the input buffer was flushed before sending data back down the pipe. I could understand it if that was declared to be an illegal thing to do, but then I'd expect Tomcat to throw some kind of exception to tell me that I was doing something stupid :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 12:11 PM Subject: Re: [VOTE] 5.0.9 stability rating Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Yeah, I know that this is a six-hour-stale message ;-). The Connector has become somewhat of a special case, so it probably merits getting it's own intelligent MBean. There are properties that make sense on one Connector (e.g. maxKeepAliveRequest on HTTP/1.1, but not on AJP), and default values that are wildly different (e.g. connectionTimeout, which should be enabled to a short value on HTTP/1.1, and disabled on AJP). I attempted to implement this in the Connector class, but as Remy pointed out, it's not practical given the need to access attributes in the critical path. So, the Connectors need a custom MBean to allow JMX to be able to configure them correctly. If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. Remy - 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] 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: [VOTE] 5.0.9 stability rating
btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Remy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Eric Carmichael
Remy Maucherat a écrit : I'd like to nominate Eric Carmichael as a committer on the Tomcat project. Eric has been steadily supplying quality patches to the new Jasper which will implement the JSP 2.0 specification, and has helped fix outstanding bug reports. He plans to continue contributing in the future. He has my +1. +1, welcome on board Better now than never ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j-t-c] Thread problem in jk_uri_worker_map.c
Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10912] - org.apache.catalina.INVOKER.process.queue_server is currently unavailable
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=10912. 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=10912 org.apache.catalina.INVOKER.process.queue_server is currently unavailable [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 10:44 --- I have the same problem. To reproduce it I have compiled the HelloWorld example which is part of tomcat. After this I will receive an error, in the log file there is a line WebappClassLoader: Resource '/WEB-INF/classes/HelloWorldExample.class' was modified; Date is now: Wed Aug 27 13:31:04 CEST 2003 Was: Thu Jul 31 19:29:54 CEST 2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP address Assignment problem
I have set server.xml to point to port 80 as follows: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true address=205.200.21.30/ IIS is running on a different IP address. The same configuration works well on Windows NT. However it does not work on XP or Windows 2000. Thanks From: Martin Gainty [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Tue, 26 Aug 2003 21:37:05 -0700 server.xml: port=80 What is your port spec in server.xml? -Martin - Original Message - From: J Raf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 6:16 PM Subject: Re: IP address Assignment problem Thank you for your help, I think this is a bug in TOMCAT running on Windows 2000 and XP. The same config works fine on NT. I have even setup Tomcat to run on 127.0.0.1:80 (loopback) and IIS to run on the real network address 192.168.1.100:80 on the same machine and it works just fine. Any help is much appreciated. From: Reshat Sabiq [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Sun, 24 Aug 2003 19:31:01 -0500 J Raf wrote: The machine is configured with different IP addresses. IIS was running on a differnt IP address then Tomcat. Both Tomcat on IIS were running on port 80. Using the IIS adminnstration module you can specify which IP address IiS should run on. Thank you for your help. From: Reshat Sabiq [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: IP address Assignment problem Date: Sat, 23 Aug 2003 13:16:31 -0500 Ayoub Raffoul wrote: Hello, I'm running Apache Tomcat ver. 4.1 on a Windows 2000 server. The machine has multipe IP addresses. I have configured Apache Tomcat in server.xml to run on a specific IP address port 80 as follows (fake IP address): Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 useURIValidationHack=false disableUploadTimeout=true address=205.200.21.30/ I also need to run IIS on the same machine though on a different IP IE: 205.200.21.31 and port 80. Each time I try to launch IIS I get an error message saying port is in use. If I shut down Tomcat then the port get released and I'm able to launch Tomcat. It seems that Tomcat is reserving all ports # 80 for all IP addresses on this machine. This configuration was working correctly in an older version of Tomcat. Even though Tomcat seems to be reserving all port 80 for all IP addresses it is only responding to 205.200.21.30. Vice Versa is also a problem. If I shut down Tomcat and start IIS on 205.200.21.31:80, Tomcat will no longer launch on 205.200.21.30:80. It will report that the port is in use. Has anybody encountered a similar issue? Your help is highly appreciated. Thank you ___ A port denotes an application, so i'm suprised you were previously able to have 2 applications on the same machine on the same port. In other words, the OS needs be aware and support different-IP-same-port distinction. I don't know if Win or others do that. -- Sincerely, Reshat. - -- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s OK, i remember reading somewhere that Win can be configured for 2 IPs. I think it may be a problem with the networking setup on that machine. My guess is that the machine's OS (TCP/IP stack in particular) isn't aware that you intend to use 2 IPs, and probably needs to be set up accordingly using some applet. Sorry, not really much help... -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. smime.p7s _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [j-t-c] Thread problem in jk_uri_worker_map.c
Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug with IIS/JK2... isapi_redirector2.dll is not up-to-date !!!!
Did you configure according to http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/jk2/insta llhowto.html Including setting up APR? -Martin - Original Message - From: Samuel Arnod-Prin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 5:45 AM Subject: Bug with IIS/JK2... isapi_redirector2.dll is not up-to-date Hello, I've discovered a bug using JK2 with IIS5 and I've heard of this bug on older messages of the list... The isapi_redirector2.dll available on jakarta.apache.org is older than the patch that correct it... Where could I download the latest version ??? Or could someone send it to me ?? I have no environment to build it from source ;o( Remember : this bug corrupts file that are uploaded from forms... a few bytes are corrupted and the result is that the whole file is corrupted ;o( thank you for helpin, I can't find anything using google, you are my latest help :o) - 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]
DO NOT REPLY [Bug 12218] - GetAttribute returns Null
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=12218. 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=12218 GetAttribute returns Null [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 15:38 --- Well Guys the solution was that i used to create in my manual SocketFactory the socket which is socket but not JSSE socket. That's why one of valaves of tomcat which is responsible for putting this argument (it uses instsneof) was not recognizing the socket as SSL socket. The solution is to provide your own valve to init this argument. Goog Luck! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22755] New: - say which variable is at fault! (Cannot compare null variable to value true)
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=22755. 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=22755 say which variable is at fault! (Cannot compare null variable to value true) Summary: say which variable is at fault! (Cannot compare null variable to value true) Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am getting javax.servlet.ServletException: Cannot compare null variable to value true at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:533) ... Jasper certainly knows with variable is null === it would be very helpful for the user to know which one! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: - Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 12:11 PM Subject: Re: [VOTE] 5.0.9 stability rating Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Yeah, I know that this is a six-hour-stale message ;-). The Connector has become somewhat of a special case, so it probably merits getting it's own intelligent MBean. There are properties that make sense on one Connector (e.g. maxKeepAliveRequest on HTTP/1.1, but not on AJP), and default values that are wildly different (e.g. connectionTimeout, which should be enabled to a short value on HTTP/1.1, and disabled on AJP). I attempted to implement this in the Connector class, but as Remy pointed out, it's not practical given the need to access attributes in the critical path. So, the Connectors need a custom MBean to allow JMX to be able to configure them correctly. I think only a subset of the attributes are needed in the critical path. IMO we should handle them as special cases (ie, cache them as local fields) and reapply your patch (it looked like a really good idea before I did some profiling). If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hate to be a pain...
Martin Algesten wrote: ...but why does http://jakarta.apache.org/tomcat/ say 5.0.9 Alpha while the download page says 5.0.9 Beta... Didn't all agree on beta in the end? Stuff is happening on the server behind the scenes, so I think the content got rolled back (or I simly forgot to update from the CVS, but I doubt that). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22754] New: - Tomcat connectors page is missing
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=22754. 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=22754 Tomcat connectors page is missing Summary: Tomcat connectors page is missing Product: Tomcat 5 Version: 5.0.0 Platform: All URL: http://jakarta.apache.org/builds/jakarta-tomcat- connectors/jk2/doc/jk/iishowto.html OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The Tomcat connectors page is missing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users ListUsersAction.java
amyroh 2003/08/27 11:38:46 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users ListUsersAction.java Log: Fix to return null when an error response is sent- patch submitted by Jeff Tulley [EMAIL PROTECTED] Revision ChangesPath 1.2 +5 -4 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListUsersAction.java Index: ListUsersAction.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListUsersAction.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ListUsersAction.java 18 Jul 2002 16:48:22 - 1.1 +++ ListUsersAction.java 27 Aug 2003 18:38:46 - 1.2 @@ -164,6 +164,7 @@ (HttpServletResponse.SC_INTERNAL_SERVER_ERROR, resources.getMessage (locale, users.error.attribute.get, users)); +return null; } // Stash the results in request scope - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users ListGroupsAction.java ListRolesAction.java
amyroh 2003/08/27 11:38:58 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users ListGroupsAction.java ListRolesAction.java Log: Fix to return null when an error response is sent- patch submitted by Jeff Tulley [EMAIL PROTECTED] Revision ChangesPath 1.2 +5 -4 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListGroupsAction.java Index: ListGroupsAction.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListGroupsAction.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ListGroupsAction.java 18 Jul 2002 16:48:22 - 1.1 +++ ListGroupsAction.java 27 Aug 2003 18:38:58 - 1.2 @@ -164,6 +164,7 @@ (HttpServletResponse.SC_INTERNAL_SERVER_ERROR, resources.getMessage (locale, users.error.attribute.get, groups)); +return null; } // Stash the results in request scope 1.2 +5 -4 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListRolesAction.java Index: ListRolesAction.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/users/ListRolesAction.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ListRolesAction.java 18 Jul 2002 16:48:22 - 1.1 +++ ListRolesAction.java 27 Aug 2003 18:38:58 - 1.2 @@ -164,6 +164,7 @@ (HttpServletResponse.SC_INTERNAL_SERVER_ERROR, resources.getMessage (locale, users.error.attribute.get, roles)); +return null; } // Stash the results in request scope - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11047] - getRealPath is broken since Tomcat 4.0.4, worked in Tomcat 4.0.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=11047. 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=11047 getRealPath is broken since Tomcat 4.0.4, worked in Tomcat 4.0.3 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 18:36 --- I have tested this with the latest release. Upgrading to 4.1.27 should resolve the issue. If you still experience problems, please re-open and I will investigate further. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22770] New: - Logger element within Context element in Context.xml file not getting recognized by Tomcat
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=22770. 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=22770 Logger element within Context element in Context.xml file not getting recognized by Tomcat Summary: Logger element within Context element in Context.xml file not getting recognized by Tomcat Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Greetings: I am able to successfully deploy an application which is not in the standard webapps directory by using a context.xml file within the WEB-INF directory of the application. I attempt to create a log file for the application but log file does not get created in the logs directory or any other directory. Context cachingAllowed=true docBase=c:wwwsites/eNotifyWeb path=/eNotifyWeb Logger className=org.apache.catalina.logger.FileLogger directory=logs debug=0 prefix=localhost_enotify_log. suffix=.txt timestamp=true verbosity=1/ /Context it appears that the only way a Logger element gets recognized and works is when the Context element is written within the server.xml file. The administration control panel does not recognize the Logger element when generated in this way. I think it should get recoginized within the context.xml file as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12938] - servlets do not register PUT request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12938. 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=12938 servlets do not register PUT request [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 20:54 --- I have successfully tested this using the heads of tomcat 4.1 and 5.0. If, after upgrading to the latest version, you still experience this problem please reopen this bug report and I will be happy to investigate further. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Bill Barker wrote: If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. Cool. So I looked at your reverted patch. I think it makes sense to put similar implemntation into ConnectorMBean class then. Would you like to do it or do you want me to use your patch and apply it? Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Patch] Edit field maxlength in admin app's login.jsp
The admin application needlessly sets the maximum size of the username and password fields to 16 characters. It is VERY easy to run into a problem with some Realm types (like JNDI, if you are using fully-qualified LDAP names). I know a password of 16 characters is a bit pathological, but the limit is arbitrary and needless. I have attached a simple patch to this to just get rid of the maximums. I have seen two or three emails complaining about this and ran into this myself today. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/login.jsp,v retrieving revision 1.7 diff -u -r1.7 login.jsp --- login.jsp 15 Jan 2003 22:25:17 - 1.7 +++ login.jsp 27 Aug 2003 21:08:24 - @@ -51,7 +51,7 @@ font color=#FFlabel for=usernamebean:message key=prompt.username//label/font /th td align=left -input type=text name=j_username size=16 maxlength=16 id=username/ +input type=text name=j_username size=16 id=username/ /td /tr p @@ -60,7 +60,7 @@ font color=#FFlabel for=passwordbean:message key=prompt.password//label/font /th td align=left -input type=password name=j_password size=16 maxlength=16 id=password/ +input type=password name=j_password size=16 id=password/ /td /tr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22695] New: - TX 5.0.9 Exception During Startup
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=22695. 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=22695 TX 5.0.9 Exception During Startup Summary: TX 5.0.9 Exception During Startup Product: Tomcat 5 Version: 5.0.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Aug 25, 2003 9:25:15 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Aug 25, 2003 9:25:16 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1515 ms Aug 25, 2003 9:25:16 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Aug 25, 2003 9:25:16 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.0.9 Aug 25, 2003 9:25:18 AM org.apache.catalina.session.StandardManager start SEVERE: Exception loading sessions from persistent storage java.lang.IllegalStateException: getAttribute: Session already invalidated at org.apache.catalina.session.StandardSession.getAttribute (StandardSession.java:982) at org.apache.catalina.session.StandardSession.activate (StandardSession.java:756) at org.apache.catalina.session.StandardManager.doLoad (StandardManager.java:453) at org.apache.catalina.session.StandardManager.load (StandardManager.java:377) at org.apache.catalina.session.StandardManager.start (StandardManager.java:691) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4029) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1127) at org.apache.catalina.core.StandardHost.start(StandardHost.java:792) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1127) 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:2311) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) 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]
DO NOT REPLY [Bug 12501] - Custom loaderClass=... ignored in Loader.../Loader
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=12501. 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=12501 Custom loaderClass=... ignored in Loader.../Loader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 21:34 --- *** This bug has been marked as a duplicate of 5446 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5446] - Can't change webapp class loader (bug #5391 revisited :)
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=5446. 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=5446 Can't change webapp class loader (bug #5391 revisited :) [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 21:34 --- *** Bug 12501 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MEI Whitelist Dequarantine Notice
This message has been dequarantined. Although the system only presents the first 55 lines here, the original message was sent to paul intact. From [EMAIL PROTECTED] Wed Aug 27 17:39:19 2003 Return-Path: [EMAIL PROTECTED] Received: from apache.org (daedalus.apache.org [208.185.179.12]) by mei.net (8.12.9/8.12.9) with SMTP id h7RLdIHL012871 for [EMAIL PROTECTED]; Wed, 27 Aug 2003 17:39:19 -0400 Received: (qmail 13893 invoked by uid 500); 27 Aug 2003 21:13:24 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org Reply-To: Tomcat Developers List [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 13329 invoked from network); 27 Aug 2003 21:13:13 - Received: from unknown (HELO prv-mail20.provo.novell.com) (137.65.81.122) by daedalus.apache.org with SMTP; 27 Aug 2003 21:13:13 - Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Aug 2003 15:13:16 -0600 Message-Id: [EMAIL PROTECTED] X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 27 Aug 2003 15:13:07 -0600 From: Jeff Tulley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Patch] Edit field maxlength in admin app's login.jsp Mime-Version: 1.0 Content-Type: multipart/mixed; boundary==__PartF7A988F3.0__= X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N BCT-delivery-for: paul MEI-wl-code: MEI0128841062020359b1bcCKd7kF6nm5U0kIfHig --=__PartF7A988F3.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline The admin application needlessly sets the maximum size of the username and password fields to 16 characters. It is VERY easy to run into a problem with some Realm types (like JNDI, if you are using fully-qualified LDAP names). I know a password of 16 characters is a bit pathological, but the limit is arbitrary and needless. I have attached a simple patch to this to just get rid of the maximums. I have seen two or three emails complaining about this and ran into this myself today. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com --=__PartF7A988F3.0__= - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14944] - conflict with NAV2003
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=14944. 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=14944 conflict with NAV2003 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 22:17 --- I have tested this with the 4.1.27 binary and Norton Anti-virus 2003. I installed tomcat as a service, created a separate startup account for tomcat and NAV. After a reboot tomcat and NAV auto-protect were both working as normal. If you are still having problems runing this as a service, I would suspect the 'other problems' you referred to may be the source. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14192] - setclasspath.bat does not set classpath correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14192. 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=14192 setclasspath.bat does not set classpath correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-08-27 22:50 --- Bazza comments are correct. This bug is invalid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
