RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0
Good news :) Some updates in documentation (workers.properties need updates) and I think we could tag jtc mod_jk_1_2_0 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 02, 2002 12:52 AM To: Tomcat Dev List Subject: RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0 If you're referring to statically linking mod_jk into Apache 1.3.x, then I can confirm that it works just fine. I've been running that configuration for quite some time now. Bojan On Mon, 2002-07-01 at 18:53, GOMEZ Henri wrote: Ok, I'll remove them so, and will update the build documentation (in xdocs). BTW, who could tell us more about mod_jk 1.2.x static build ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 5:19 AM To: Tomcat Dev List Subject: Re: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0 As long as configure/make works I'm +1. Bojan On Fri, 2002-06-28 at 22:39, GOMEZ Henri wrote: Hi, What about removing all the outdated makefile and build.platform.sh present in jk/native now that we have a working configure/makefile or ant/jkant ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- 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] -- 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: cvs commit: jakarta-tomcat-connectors/jk/native/iis README
Who could update the iplanet README ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 9:34 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-connectors/jk/native/iis README nacho 2002/07/01 12:33:59 Modified:jk/native/iis README Log: * More on build i_r.dll from command line. Revision ChangesPath 1.2 +21 -3 jakarta-tomcat-connectors/jk/native/iis/README Index: README === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/README,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- README 1 Jul 2002 11:08:35 - 1.1 +++ README 1 Jul 2002 19:33:59 - 1.2 @@ -8,8 +8,26 @@ REQUIREMENT --- -MS VC 6.0 (+ update, latest service pack is sp5) -MS PLATFORM SDK +* MS VC 6.0 (+ update, latest service pack is sp5) + isapi_redirector.dll can be built using the command line tools, or + from within the Visual Studio IDE Workbench. The command line build + requires the environment to reflect the PATH, INCLUDE, LIB and other + variables that can be configured with the vcvars32 batch file: + + c:\Program Files\DevStudio\VC\Bin\vcvars32.bat + +* MS PLATFORM SDK + Visual C++ 6.0 builds require an updated Microsoft Windows Platform SDK + (http://www.microsoft.com/msdownload/platformsdk/sdkupdate/) to enable + some isapi_redirector.dll features. For command line builds, + the Platform SDK environment is prepared by the setenv batch file: + + c:\Program Files\Microsoft Platform SDK\setenv.bat + + Note that the Windows Platform SDK is only needed if you want authenticate + using IIS to compile a isapi_redirector.dll.. + + BUILDING @@ -17,7 +35,7 @@ The steps that you need to take are: 1. Change directory to the isapi redirector plugins source directory. - + 2. Execute the following command: MSDEV isapi.dsp /MAKE ALL If msdev is not in your path, enter the full path to msdev.exe -- 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: PROPOSAL: 5.0 configuration
[EMAIL PROTECTED] wrote: The basic idea is to use a 2-layer configuration mechansim, with a pluggable repository for preferene storage and JMX-based component configuration. For config storage, we should be able to use: - current XML files ( with few minor changes in the 3-4 classes that deal with reading config ) - JNDI - for config stored in a directory service ( ldap, active directory, nds, etc). - JDK1.4 preference API, if running in JDK1.4 ( that means registry on windows, well-defined xml files on unix ). - registry - using jk2 native calls - if tomcat is embeded in another application, the application-specific config repository. The config layer will be similar with the JDK1.4 preferences (which we can't use directly - we still have to support older versions ), and will be mostly independent of tomcat ( eventually move to commons - but after we get it stable and to do what we need in tomcat). There are few big benefits in this: - better scalability ( with directory services, in case of large site ). - consistent configuration with the applications embeding tomcat. - consistent configuration with the OS ( i.e. registry can be used on windows, etc ). - simpler API for configuration ( the XmlMapper/Digester are still a bit tricky, and is very difficult to make changes ) - allow us to capture what the user directly changes - the current mechanism for saving will just read all the properties from all beans. - we'll be able to use a single config storage/format for all components ( instead of server.xml, policy, jk2.properites, user.xml,etc) The implementation will actually use the same mechanism as today - except that instead of reading the XML file and using XmlMapper/Digester, we'll get the data from the repository. That seems like a very good idea to me. In Tomcat 4.1, there's currently a big difference configuration-wise when you embed Tomcat when compared to when you run it standalone; I think this is a problem. Another problem of the current config mechanism is that it is hardcoded for the digester, and is therefore is limited. The mechanisms to save back the configuration are also hackish and limited. In addition, any change will be made via the configurator and JMX, and will be recorded and saved ( with a bit of work it is even possible to save the xml files preserving the comments and with the same structure, and only what is modified will be written ). The second layer will be based on the JMX patterns - and will not require any change in the current code. The configurator will just set the attributes and create the components - using either direct introspection or JMX. As more components will be JMX-instrumented, we should be able to use the new configuration to setup those components as well ( log4j for example ) - without any special change in the code. There is nothing very new in this proposal - having pluggable config has been a goal since tomcat3.0, and the proposal itself will change very little as code. A basic implementation of this model is already part of mod_jk2 ( in jk_config.c - the java version will follow, if we agree on this proposal :-). Both layers will be based on existing standards and common patterns. JMX ( and the current java bean patterns ) are clearly the best way to configure components, and JNDI/prefs provide an excelent API for storing config data ( and XML can use that easily ) +1. This looks like a welcome step forward, and is well worth the effort. I don't see anything in the proposal which mentions removing the current configuration mechanisms; would you leave it there for compatibility ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: servlet authentication
i could be wrong, but i think once you call sendError(), the response is committed and
you cannot set any more headers. try reversing the order of the
sendError()/setHeader() calls:
response.setHeader(WWW-Authenticate, BASIC realm=\test\);
response.sendError(response.SC_UNAUTHORIZED);
-Original Message-
From: Michael Bergknoff [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 9:02 PM
To: [EMAIL PROTECTED]
Subject: servlet authentication
To test servlet-based authentication, I have a two
line servlet.
response.sendError(response.SC_UNAUTHORIZED);
response.setHeader(WWW-Authenticate, BASIC
realm=\test\);
Here is the output I get:
$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /myapp/servlet
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family :
sans-serif,Arial,Tahoma;color : white;background-color
: #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color : #0086b2;}
HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 401
- Unauthorized/h1HR size=1 noshadepbtype/b
Status report/ppbmessage/b
uUnauthorized/u/ppbdescription/b uThis
request requires HTTP authentication
(Unauthorized)./u/pHR size=1
noshade/body/htmlConnection closed by foreign
host.
The output contains no HTTP headers, just some Tomcat
generated HTML. Is this a bug in my servlet test or
what?
Thanks,
Mike
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
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: [4.1.6] New milestone release soon
Costin, I'm using RedHat 7.3, Apache 2.1.39, TC 4.1.6, mod_jk1, CoyoteJK2. I build a new mod_jk.so everytime I get a new Tomcat. So it is definetley recent. I'm not sure what additional information to provide that hasn't already been detailed in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018. Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 01 July 2002 23:54 To: Tomcat Developers List Subject: RE: [4.1.6] New milestone release soon On Mon, 1 Jul 2002, David Oxley wrote: Costin, This problem still happens with 4.1.6. Ok, I need more details then. Are you sure the mod_jk is recent ? Are you using mod_jk or mod_jk2 ( on apache side )? Any stack traces or message ? As I said, I'm doing large uploads/downloads currently, and it works fine. Costin Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 16:57 To: Tomcat Developers List Subject: RE: [4.1.6] New milestone release soon On Wed, 26 Jun 2002, David Oxley wrote: Remy, Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource (might apply to dynamic content as well as static) that's bigger than 8k. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018 Are you using a nightly ? I fixed the bug few days ago, I'm constantly doing large posts with jk2 in my day job. Please let me know ASAP if you still have this problem ! Costin Dave. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 12:14 To: Tomcat Developers List Subject: [4.1.6] New milestone release soon There are only a few issues remaining: - Updating JNDI resources with the admin webapp is not dynamic (for reasons currently beyond my understanding). Doing a stop/start on the context allows to pick up the changes, so the bug is only minor. - Nacho's IIS issues with JK 2. - Costin's bug with Jasper 2. None of these are showstoppers IMO, but it would be best to have them fixed before the release is tagged (the objective being to get back to beta status). By friday maybe ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c
mturk 2002/07/02 05:06:46 Modified:jk/native2/common jk_worker_jni.c Log: Disable the call ro the DestoryJavaVM. This call should be invoked when the TomcatStarter or something else signals that there will be no more calls. Revision ChangesPath 1.23 +7 -2 jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c Index: jk_worker_jni.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- jk_worker_jni.c 1 Jul 2002 23:11:42 - 1.22 +++ jk_worker_jni.c 2 Jul 2002 12:06:46 - 1.23 @@ -378,13 +378,18 @@ env-l-jkLog(env, env-l, JK_LOG_INFO, jni.destroy() calling main()...\n); - + (*jniEnv)-CallStaticVoidMethod(jniEnv, jniWorker-jk_java_bridge_class, jniWorker-jk_main_method, jargs,stdout_name,stderr_name); - +#if 0 +/* XXX Need to fix the TomcatStarter not calling jkSetAttribute + * and call the destroy JVM on that event. + * Perhaps the DestroyJavaVM is not needed at all. + */ vm-destroy(env, vm); +#endif } env-l-jkLog(env, env-l, JK_LOG_INFO, jni.destroy() done\n); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c
mturk 2002/07/02 05:08:25
Modified:jk/native2/common jk_channel_jni.c
Log:
Call the vm detach on 'afterRequest' and on
channel destoy.
Revision ChangesPath
1.31 +5 -1 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
Index: jk_channel_jni.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- jk_channel_jni.c 29 Jun 2002 18:31:00 - 1.30
+++ jk_channel_jni.c 2 Jul 2002 12:08:25 - 1.31
@@ -329,6 +329,10 @@
(*jniEnv)-DeleteGlobalRef( jniEnv, epData-jniJavaContext );
}
+jniCh-vm-detach( env, jniCh-vm );
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ channel_jni.close() ok\n );
+
endpoint-channelData=NULL;
return JK_OK;
@@ -522,7 +526,7 @@
if( we==NULL || we-vm==NULL ) {
return JK_OK;
}
-/* we-vm-detach( env, we-vm ); */
+we-vm-detach( env, we-vm );
if( worker-mbean-debug 0 )
env-l-jkLog(env, env-l, JK_LOG_INFO,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk2 shuts down
Hi, Finaly been able to gracefully shutdown the isapi_redirector without the need to reboot the machine! The reason were the ghost threads left attaching in other and detaching jvm in another. Right now we have the Apache2/WIN32 and IIS tested and working. What about other platforms, and how about some beta? MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [DOCS] Tyrex-Tomcat HOWTO
Hi all, Could we add this into the JNDI Datasources HOWTO that I wrote the other week (I dont think this has been committed yet BTW) If someone can commit my HOWTO, I'll merge the two together and submit a patch this afternoon. Hope this is OK Les -Original Message- From: David Haraburda [mailto:[EMAIL PROTECTED]] Sent: 28 June 2002 20:05 To: [EMAIL PROTECTED] Subject: [DOCS] Tyrex-Tomcat HOWTO Hi all, Here is a short HOWTO I've written on how to use Tyrex 1.0 with Tomcat 4.1 (which goes along with the patch I submitted, which was just recently committed). I've added the appropriate XML tags, using the other HOWTOs as examples, so very little modification should be needed. Feedback on the content however, is greatly appreciated. :-) Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk2 shuts down
Right now we have the Apache2/WIN32 and IIS tested and working. What about other platforms, and how about some beta? Good work!!, are you volunteering to be the release manager? :) In any case +1!!! Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10405] New: - ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call.
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=10405.
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=10405
ClassCastException is thrown when request.setAttribute(charset, non_string) is
called before request.getParameter() call.
Summary: ClassCastException is thrown when
request.setAttribute(charset, non_string) is called
before request.getParameter() call.
Product: Tomcat 3
Version: 3.3.1 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Here is a simple Servlet that reproduce the problem.
---
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Attr extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
request.setAttribute(charset, new Object());
request.getParameter(blah);
}
}
java.lang.ClassCastException: java.lang.Object
at
org.apache.tomcat.modules.mappers.DecodeInterceptor.getInfo(DecodeInterceptor.java:581)
at org.apache.tomcat.core.Request.getCharEncoding(Request.java:483)
at org.apache.tomcat.core.Request.getCharacterEncoding(Request.java:470)
at org.apache.tomcat.core.Request.handleQueryParameters(Request.java:451)
at
org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:277)
at Attr.doGet(Attr.java:12)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [DOCS] Tyrex-Tomcat HOWTO
David / All, Had problems rendering your doc so I've patched it onto the end of mine and cleaned up the XML so that it styles up OK. Here it is. Comments? Les PS I will stop moaning about getting this committed, I promise... :-) -Original Message- From: Les Hughes [mailto:[EMAIL PROTECTED]] Sent: 02 July 2002 13:29 To: 'Tomcat Developers List' Subject: RE: [DOCS] Tyrex-Tomcat HOWTO Hi all, Could we add this into the JNDI Datasources HOWTO that I wrote the other week (I dont think this has been committed yet BTW) If someone can commit my HOWTO, I'll merge the two together and submit a patch this afternoon. Hope this is OK Les -Original Message- From: David Haraburda [mailto:[EMAIL PROTECTED]] Sent: 28 June 2002 20:05 To: [EMAIL PROTECTED] Subject: [DOCS] Tyrex-Tomcat HOWTO Hi all, Here is a short HOWTO I've written on how to use Tyrex 1.0 with Tomcat 4.1 (which goes along with the patch I submitted, which was just recently committed). I've added the appropriate XML tags, using the other HOWTOs as examples, so very little modification should be needed. Feedback on the content however, is greatly appreciated. :-) Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] jndi-datasource-examples-howto.xml Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BufferedServletOutputStream.java
marcsaeg2002/07/02 06:52:40
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
BufferedServletOutputStream.java
Log:
If an invalid character is sent through BufferedServletOutputStream it will
cause an infinite loop on the error page because the same invalid character
will put into the error page which will then be sent through the BSOS which
will cause another exception to the error page which will start the whole
over again.
NOTE: I know that TC3.2.x has been obsoleted, but I came across this one
change that I made locally after the 3.2.4 release and figured I'd get into
CVS before it got lost on my local machine.
Revision ChangesPath
No revision
No revision
1.14.2.4 +5 -5
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletOutputStream.java
Index: BufferedServletOutputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletOutputStream.java,v
retrieving revision 1.14.2.3
retrieving revision 1.14.2.4
diff -u -r1.14.2.3 -r1.14.2.4
--- BufferedServletOutputStream.java 22 Jun 2001 19:57:06 - 1.14.2.3
+++ BufferedServletOutputStream.java 2 Jul 2002 13:52:39 - 1.14.2.4
@@ -215,9 +215,9 @@
// streams properly encode their output.
//
if ((c 0xff00) != 0) {// high order byte must be zero
- String errMsg = sm.getString(
+String errMsg = sm.getString(
servletOutputStreamImpl.fmt.not_iso8859_1,
- new Object[] {new Character(c)});
+ new Object[] {Integer.toHexString((int)c)});
throw new IOException(errMsg);
}
write(c);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10406] New: - Tomcat Memory Management
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=10406.
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=10406
Tomcat Memory Management
Summary: Tomcat Memory Management
Product: Tomcat 3
Version: 3.2.3 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Critical
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Product:Java Web Application
Operating system: Windows NT/2000 server, Linux, FreeBSD
Web Server: IIS, Apache etc
Application server: Tomcat 3.2.4 and above
Database server:MySQL 3.23.49, MS-SQL, Oracle etc
Java Architecture: JSP (presentation) + Java Bean (Business logic)
We are currently hosting our web application using Tomcat 4 with IIS 5
on Windows 2000 server. We have also supplied our product to some of our
customers who are hosting it on Linux using Tomcat 3.2.4 also. We have been
facing the following problem for quite some time now. As more and more people
are visiting and browsing the site, the Java.exe/Tomcat.exe size keeps growing
and finally we end up with Out of memory error. Even if we leave the server
inactive for hours, the memory doesn't get released and the only option is to
restart the Tomcat server. We have posted this problem in many forums and in
the Tomcat bug database also (both 3.* and 4). But we didn't get any solutions
and also we were told that the problem could lie with our application.
So, we decided to conduct a test with Tomcat example JSP pages, so as
to see whether the memory is getting released properly with them at least. The
memory.jsp contains the following code and all the example pages used had the
same code embedded to find out the memory usage.
memory.jsp:
%
try
{
out.println(table border=1trtdTotal Memory + Runtime.getRuntime
().totalMemory()/1000 + KB/td);
out.println(tdMemory in Use +((Runtime.getRuntime().totalMemory()-
Runtime.getRuntime().freeMemory())/1000) + KB/td);
out.println(tdThread Count + Thread.activeCount() + /td/tr/table);
}
catch(Exception ex)
{
out.println(ex);
}
%
Following is the result of the test done on Tomcat 4.03 as standalone server.
NameTotal memoryUsed memory Threads
memory.jsp 4026274422
examples/jsp/num/numguess.jsp 4026346422
examples/jsp/num/numguess.jsp?guess=4026370422
examples/jsp/dates/date.jsp 4435305422
examples/jsp/snp/snoop.jsp· 4435337422
examples/jsp/include/include.jsp4435395322
examples/jsp/forward/forward.jsp4599385022
examples/jsp/plugin/plugin.jsp 4599417622
examples/jsp/simpletag/foo.jsp 4730271222
memory.jsp 4730297722
After 30 mins (session timeout)
memory.jsp 4730318222
We felt, as in our application, the memory used by Tomcat doesn't get
released fully even for
Tomcat example JSP pages. We have repeated the same test many times, restarting
Tomcat, deleting work folder, clearing browser cache every time. We have even
tried the same after restarting the machine. The pattern is exactly the same
barring variations of few bytes here and there.
We repeated the same test on Tomcat 3.2.4 and the results were
similar. Only the figures were different. Then, we decided to conduct the same
test using JRun 3.1, so as to see whether the memory is getting released
properly with it at least.
Following is the result of the test done on JRun 3.1 as standalone server.
NameTotal memoryUsed memory Threads
memory.jsp 285924512
examples/jsp/num/numguess.jsp 373121884
examples/jsp/num/numguess.jsp?guess=373123394
examples/jsp/dates/date.jsp 387021504
examples/jsp/snp/snoop.jsp· 387024724
examples/jsp/include/include.jsp387020104
examples/jsp/forward/forward.jsp387022734
examples/jsp/plugin/plugin.jsp 387020064
examples/jsp/simpletag/foo.jsp
memory.jsp 387020634
After 30 mins
DO NOT REPLY [Bug 10407] New: - Tomcat Memory Management
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=10407.
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=10407
Tomcat Memory Management
Summary: Tomcat Memory Management
Product: Tomcat 4
Version: 4.0.3 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Critical
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Product:Java Web Application
Operating system: Windows NT/2000 server, Linux, FreeBSD
Web Server: IIS, Apache etc
Application server: Tomcat 3.2.4 and above
Database server:MySQL 3.23.49, MS-SQL, Oracle etc
Java Architecture: JSP (presentation) + Java Bean (Business logic)
We are currently hosting our web application using Tomcat 4 with IIS 5
on Windows 2000 server. We have also supplied our product to some of our
customers who are hosting it on Linux using Tomcat 3.2.4 also. We have been
facing the following problem for quite some time now. As more and more people
are visiting and browsing the site, the Java.exe/Tomcat.exe size keeps growing
and finally we end up with Out of memory error. Even if we leave the server
inactive for hours, the memory doesn't get released and the only option is to
restart the Tomcat server. We have posted this problem in many forums and in
the Tomcat bug database also (both 3.* and 4). But we didn't get any solutions
and also we were told that the problem could lie with our application.
So, we decided to conduct a test with Tomcat example JSP pages, so as
to see whether the memory is getting released properly with them at least. The
memory.jsp contains the following code and all the example pages used had the
same code embedded to find out the memory usage.
memory.jsp:
%
try
{
out.println(table border=1trtdTotal Memory + Runtime.getRuntime
().totalMemory()/1000 + KB/td);
out.println(tdMemory in Use +((Runtime.getRuntime().totalMemory()-
Runtime.getRuntime().freeMemory())/1000) + KB/td);
out.println(tdThread Count + Thread.activeCount() + /td/tr/table);
}
catch(Exception ex)
{
out.println(ex);
}
%
Following is the result of the test done on Tomcat 4.03 as standalone server.
NameTotal memoryUsed memory Threads
memory.jsp 4026274422
examples/jsp/num/numguess.jsp 4026346422
examples/jsp/num/numguess.jsp?guess=4026370422
examples/jsp/dates/date.jsp 4435305422
examples/jsp/snp/snoop.jsp· 4435337422
examples/jsp/include/include.jsp4435395322
examples/jsp/forward/forward.jsp4599385022
examples/jsp/plugin/plugin.jsp 4599417622
examples/jsp/simpletag/foo.jsp 4730271222
memory.jsp 4730297722
After 30 mins (session timeout)
memory.jsp 4730318222
We felt, as in our application, the memory used by Tomcat doesn't get
released fully even for
Tomcat example JSP pages. We have repeated the same test many times, restarting
Tomcat, deleting work folder, clearing browser cache every time. We have even
tried the same after restarting the machine. The pattern is exactly the same
barring variations of few bytes here and there.
We repeated the same test on Tomcat 3.2.4 and the results were
similar. Only the figures were different. Then, we decided to conduct the same
test using JRun 3.1, so as to see whether the memory is getting released
properly with it at least.
Following is the result of the test done on JRun 3.1 as standalone server.
NameTotal memoryUsed memory Threads
memory.jsp 285924512
examples/jsp/num/numguess.jsp 373121884
examples/jsp/num/numguess.jsp?guess=373123394
examples/jsp/dates/date.jsp 387021504
examples/jsp/snp/snoop.jsp· 387024724
examples/jsp/include/include.jsp387020104
examples/jsp/forward/forward.jsp387022734
examples/jsp/plugin/plugin.jsp 387020064
examples/jsp/simpletag/foo.jsp
memory.jsp 387020634
After 30 mins
RE: mod_jk2 shuts down
Good work!!, are you volunteering to be the release manager? :) What is this? A man hunt :) In any case +1!!! Would, but have no idea what the RM should do :) 1. We still need to update the docs before any release (just look at the Tomcat Users list). 2. Didn't do any tests with the 1.3 3. Unix builds (all that I have is a RH 7.3 under VMware) MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10410] New: - Adding 1 Resource-link element results in multiple displayed in admin webapp
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=10410. 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=10410 Adding 1 Resource-link element results in multiple displayed in admin webapp Summary: Adding 1 Resource-link element results in multiple displayed in admin webapp Product: Tomcat 4 Version: 4.1.6 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the Admin web-app to add resource-link elements, the webapp would add 3 elements for every 1 that I configured. I checked in server.xml, and only 1 resource-link was added, as well as a spurious resource element (spurious because I was linking to a global resource) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.6] Milestone available for testing
Hey, I may have missed something obvious, but if I didn't, are there plans to add context reset/stop/start to the new administration webapp? -Chad Johnson - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Cc: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, June 28, 2002 2:10 PM Subject: [4.1.6] Milestone available for testing Hightlights in this test release include: - fix for a memory leak in the request dispatcher - many fixes and refactorings in Jasper 2 - admin webapp improvements - other misc fixes See the release notes for the list of changes. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.6/ 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]
A couple of possible data-race bugs
I'm working on a tool for finding datarace bugs in Java programs. Roughly, we find places where data shared between threads is being accessed without locking or other synchronization. I found a couple of things in Tomcat (4.0.4 final, still present in CVS) that look like lurking problems: The first one is minor: in org.apache.catalina.connector.http.HttpConnector.start(), curProcessors is checked without holding the processors lock. So, between start() checking curProcessors maxProcessors and creating a new processor, the HttpConnector thread might get a bunch of connections and create its own processors up to maxProcessors, and so start() will create processor number maxProcessors+1. In org.apache.catalina.core.StandardWrapper, the countAllocated field is updated without any locking. If increments or decrements to countAllocated occur simultaneously in different threads, updates can be lost, leading to countAllocated having an incorrect value. It seems that an incorrect value could cause problems in unload(), where the loop that waits for countAllocated to go = 0 might either terminate early or never terminate at all. I'd appreciate any feedback on whether my understanding of the code is correct and whether these are real problems. Thanks, Robert O'Callahan IBM TJ Watson Research Staff Member Office: Hawthorne 1N-J20Phone: (914) 784-7911 The first to present his case seems right, till another comes forward and questions him. -- Proverbs 18:17 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.1.6] New milestone release soon
Got it. I'll check in, please test again. Costin On Tue, 2 Jul 2002, David Oxley wrote: Costin, I'm using RedHat 7.3, Apache 2.1.39, TC 4.1.6, mod_jk1, CoyoteJK2. I build a new mod_jk.so everytime I get a new Tomcat. So it is definetley recent. I'm not sure what additional information to provide that hasn't already been detailed in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018. Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 01 July 2002 23:54 To: Tomcat Developers List Subject: RE: [4.1.6] New milestone release soon On Mon, 1 Jul 2002, David Oxley wrote: Costin, This problem still happens with 4.1.6. Ok, I need more details then. Are you sure the mod_jk is recent ? Are you using mod_jk or mod_jk2 ( on apache side )? Any stack traces or message ? As I said, I'm doing large uploads/downloads currently, and it works fine. Costin Dave. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 16:57 To: Tomcat Developers List Subject: RE: [4.1.6] New milestone release soon On Wed, 26 Jun 2002, David Oxley wrote: Remy, Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource (might apply to dynamic content as well as static) that's bigger than 8k. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018 Are you using a nightly ? I fixed the bug few days ago, I'm constantly doing large posts with jk2 in my day job. Please let me know ASAP if you still have this problem ! Costin Dave. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 12:14 To: Tomcat Developers List Subject: [4.1.6] New milestone release soon There are only a few issues remaining: - Updating JNDI resources with the admin webapp is not dynamic (for reasons currently beyond my understanding). Doing a stop/start on the context allows to pick up the changes, so the bug is only minor. - Nacho's IIS issues with JK 2. - Costin's bug with Jasper 2. None of these are showstoppers IMO, but it would be best to have them fixed before the release is tagged (the objective being to get back to beta status). By friday maybe ? Remy -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [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]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
costin 2002/07/02 09:51:08
Modified:jk/native/common jk_ajp_common.c
Log:
Add more info to the message.
Revision ChangesPath
1.27 +3 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- jk_ajp_common.c 25 Jun 2002 07:08:03 - 1.26
+++ jk_ajp_common.c 2 Jul 2002 16:51:08 - 1.27
@@ -684,7 +684,8 @@
msglen += (head[3] 0xFF);
if(msglen jk_b_get_size(msg)) {
-jk_log(l, JK_LOG_ERROR, ajp_connection_tcp_get_message: Error - Wrong
message size\n);
+jk_log(l, JK_LOG_ERROR, ajp_connection_tcp_get_message: Error - Wrong
message size %d %d\n,
+ msglen, jk_b_get_size(msg));
return JK_FALSE;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
costin 2002/07/02 09:53:15
Modified:jk/native2/common jk_channel_socket.c
Log:
Minor fix - unix doesn't know about ioctlsocket.
For 5.0 we should deprecate the old 'backward compat' components
and use only APR.
Revision ChangesPath
1.37 +4 -2 jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
Index: jk_channel_socket.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- jk_channel_socket.c 27 Jun 2002 17:16:28 - 1.36
+++ jk_channel_socket.c 2 Jul 2002 16:53:15 - 1.37
@@ -285,10 +285,12 @@
/* convert from seconds to ms */
int set = ntimeout * 1000;
u_long zero = 0;
-if (ioctlsocket(sock, FIONBIO, zero) == SOCKET_ERROR) {
#ifdef WIN32
+if (ioctlsocket(sock, FIONBIO, zero) == SOCKET_ERROR) {
errno = WSAGetLastError() - WSABASEERR;
-#endif /* WIN32 */
+#else
+if (ioctl(sock, FIONBIO, zero) != 0) {
+#endif
env-l-jkLog(env, env-l, JK_LOG_ERROR,
channelSocket.open() ioctlcocket failed %s:%d %d %s \n,
socketInfo-host, socketInfo-port, errno, strerror(
errno ) );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_msg.h
costin 2002/07/02 09:53:59 Modified:jk/native2/include jk_msg.h Log: Change back the max message size to what we had in jk1. Without this we run into problems when jk2 talks with jk1. Revision ChangesPath 1.13 +1 -1 jakarta-tomcat-connectors/jk/native2/include/jk_msg.h Index: jk_msg.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_msg.h,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- jk_msg.h 11 Jun 2002 21:46:38 - 1.12 +++ jk_msg.h 2 Jul 2002 16:53:59 - 1.13 @@ -77,7 +77,7 @@ struct jk_ws_service; struct jk_logger; -#define DEF_BUFFER_SZ (8300) +#define DEF_BUFFER_SZ (8*1024) #define AJP13_MAX_SEND_BODY_SZ (DEF_BUFFER_SZ - 6) /** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common MsgAjp.java
costin 2002/07/02 09:55:03 Modified:jk/java/org/apache/jk/common MsgAjp.java Log: Fix for 10018, use the same size for the buffer as in jk1. Revision ChangesPath 1.12 +2 -1 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java Index: MsgAjp.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- MsgAjp.java 20 Jun 2002 18:47:48 - 1.11 +++ MsgAjp.java 2 Jul 2002 16:55:03 - 1.12 @@ -92,7 +92,8 @@ private static org.apache.commons.logging.Log log= org.apache.commons.logging.LogFactory.getLog( MsgAjp.class ); -private byte buf[]=new byte[8300]; +// that's the original buffer size in ajp13 - otherwise we'll get interoperability problems. +private byte buf[]=new byte[8*1024]; // The current read or write position in the buffer private int pos; /** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
costin 2002/07/02 09:57:31
Modified:jk/java/org/apache/jk/common ChannelSocket.java
jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Added a bit of code to display the time spent in jk and request.
I had it in my workspace, better to check it in so it doesn't get lost.
Revision ChangesPath
1.16 +2 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ChannelSocket.java5 Jun 2002 21:22:40 - 1.15
+++ ChannelSocket.java2 Jul 2002 16:57:30 - 1.16
@@ -471,7 +471,8 @@
log.warn(Closing ajp connection + status );
break;
}
-
+ep.setLong( MsgContext.TIMER_RECEIVED, System.currentTimeMillis());
+
ep.setType( 0 );
status= this.invoke( recv, ep );
if( status!= JkHandler.OK ) {
1.25 +39 -8
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- JkCoyoteHandler.java 21 Jun 2002 23:41:16 - 1.24
+++ JkCoyoteHandler.java 2 Jul 2002 16:57:30 - 1.25
@@ -83,6 +83,10 @@
{
protected static org.apache.commons.logging.Log log
= org.apache.commons.logging.LogFactory.getLog(JkCoyoteHandler.class);
+// Set debug on this logger to see the container request time
+private static org.apache.commons.logging.Log logTime=
+org.apache.commons.logging.LogFactory.getLog( org.apache.jk.REQ_TIME );
+
int headersMsgNote;
int c2bConvertersNote;
int utfC2bNote;
@@ -185,8 +189,8 @@
int len=chunk.getLength();
byte buf[]=msg.getBuffer();
-// 3 - hardcoded, byte[] marshalling overhead
-int chunkSize=buf.length - msg.getHeaderLength() - 3;
+// 4 - hardcoded, byte[] marshalling overhead
+int chunkSize=buf.length - msg.getHeaderLength() - 4;
int off=0;
while( len 0 ) {
int thisTime=len;
@@ -224,6 +228,9 @@
public int invoke( Msg msg, MsgContext ep )
throws IOException
{
+if( logTime.isDebugEnabled() )
+ep.setLong( MsgContext.TIMER_PRE_REQUEST,
System.currentTimeMillis());
+
org.apache.coyote.Request req=(org.apache.coyote.Request)ep.getRequest();
org.apache.coyote.Response res=req.getResponse();
res.setHook( this );
@@ -241,7 +248,7 @@
res.setNote( epNote, ep );
ep.setStatus( JK_STATUS_HEAD );
-
+
try {
adapter.service( req, res );
} catch( Exception ex ) {
@@ -301,6 +308,7 @@
public void action(ActionCode actionCode, Object param) {
try {
if( actionCode==ActionCode.ACTION_COMMIT ) {
+if( log.isDebugEnabled() ) log.debug(COMMIT );
org.apache.coyote.Response res=(org.apache.coyote.Response)param;
if( res.isCommitted() ) {
@@ -312,15 +320,17 @@
} else if( actionCode==ActionCode.ACTION_RESET ) {
if( log.isInfoEnabled() )
log.info(RESET );
+
} else if( actionCode==ActionCode.ACTION_CLIENT_FLUSH ) {
+if( log.isDebugEnabled() ) log.debug(CLIENT_FLUSH );
org.apache.coyote.Response res=(org.apache.coyote.Response)param;
MsgContext ep=(MsgContext)res.getNote( epNote );
ep.setType( JkHandler.HANDLE_FLUSH );
ep.getSource().invoke( null, ep );
+
} else if( actionCode==ActionCode.ACTION_CLOSE ) {
-if( log.isDebugEnabled() ) {
-log.debug(CLOSE );
-}
+if( log.isDebugEnabled() ) log.debug(CLOSE );
+
org.apache.coyote.Response res=(org.apache.coyote.Response)param;
MsgContext ep=(MsgContext)res.getNote( epNote );
if( ep.getStatus()== JK_STATUS_CLOSED ) {
@@ -343,12 +353,16 @@
ep.getSource().invoke( msg, ep );
ep.setStatus(JK_STATUS_CLOSED );
+
+if( logTime.isDebugEnabled() )
+
DO NOT REPLY [Bug 10418] New: - logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418.
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=10418
logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken
Summary: logic whether URL needs to be encoded in
HttpServletResponse.encodeURL() broken
Product: Tomcat 4
Version: 4.0.4 Final
Platform: All
URL: http://www.freiheit.com/users/hzeller/SessionBugDemonstr
ation.java
OS/Version: Linux
Status: NEW
Severity: Critical
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
[ This applies to current 4.1 CVS as well ]
The logic to determine whether a URL needs to be encoded in
HttpServletResponse.encodeURL() is broken. In
HttpServletResponseBase.isEncodeable(String location), it
decides, that the URL needn't be encoded in the URL, if the
current ID comes from the cookie; see code-snippet from
HttpServletResponseBase:
---
if (hreq.isRequestedSessionIdFromCookie()) {
return (false);
}
--
However, this does not take into account, that the session ID we got
might have been from some previous session that already is invalidated,
i.e. is not valid. In this case isRequestedSessionIdFromCookie() will
return true, but this does not say anything if future (valid) sessions
will come through the cookie.
The fix is easy: So the only way to check this correctly is:
-
if (hreq.isRequestedSessionIdFromCookie()
hreq.isRequestedSessionIdValid()) {
return (false);
}
-
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
You're right. It should have been -r TOMCAT_4_1_2 (which checks out fine for me). - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 6:06 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems Hi Bill. Didn't have any luck with that either (see below). Does it work for you? Any idea what the message about the CVS locks means / how to fix it? Yeah, I see what you mean re: files in the attic. I'm curious how things looked before I started changing things, to better understand what caused this code collision... -Dan Here's what I got when I tried to do the -r thing: [dan@oogie tmp]$ echo $CVSROOT :ext:[EMAIL PROTECTED]:/home/cvs [dan@oogie tmp]$ cvs co -r tomcat_4_1_2 jakarta-tomcat-4.0 Protocol error: uncounted data discarded Bill Barker wrote: -r tomcat_4_1_2 should work. You could also add the files back from the Attic, since it's a completely different directory. - Original Message - From: Dan Sandberg [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 01, 2002 4:25 PM Subject: Re: [PATCH] Re: SSI Servlet has big problems I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PROPOSAL: 5.0 configuration
On Tue, 2 Jul 2002, Remy Maucherat wrote: [EMAIL PROTECTED] wrote: The basic idea is to use a 2-layer configuration mechansim, with a pluggable repository for preferene storage and JMX-based component configuration. That seems like a very good idea to me. In Tomcat 4.1, there's currently a big difference configuration-wise when you embed Tomcat when compared to when you run it standalone; I think this is a problem. Another problem of the current config mechanism is that it is hardcoded for the digester, and is therefore is limited. The mechanisms to save back the configuration are also hackish and limited. Saving the configuration is what got me started. Beeing able to integrate configuration for multiple 'domains' ( tomcat, jk, logging, etc ) was the other big itch. +1. This looks like a welcome step forward, and is well worth the effort. I don't see anything in the proposal which mentions removing the current configuration mechanisms; would you leave it there for compatibility ? I think learned something in the last years :-) No, I plan to minimize the changes ( hopefully none will be required in existing code ), and I'll certainly not touch the existing config mechanism. Tomcat already follow the right patterns ( i.e. beans, setters, etc ), and all components are also JMX enabled now - so no changes in tomcat are needed. This will happen in util, as a new package - most likely an API based on util.prefs and an implementation based on code in jk2. When ready I'll first enable jk to use it, then probably I'll have to make few minor changes in Startup/Main. An intersting point - JMX has a nice notification mechanism. There are few problems - the attribute change notification is optional - but since we 'instrument' using modeler and dynamic mbeans we can intercept all the config changes done directly by JMX and persist them too. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] New: - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
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=10419. 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=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions Summary: Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions Product: Tomcat 4 Version: 4.0.4 Final Platform: All URL: http://www.freiheit.com/users/hzeller/SessionBugDemonstr ation.java OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [ Applies to current 4.1 CVS as well ] There is a bug in the way, the session id is grabbed from the request. If there is more than one session id in the request -- in the URL and a Cookie, for instance -- the session id found in the cookie _always_ wins. This is a problem, if the browsers sends an invalidated cookie and you choose to use URL-encoding in a later session: even if the session id from the URL (via encodeURL(), that works only after fixing Bug #1) is valid, the application always gets the old and invalid session from the cookie instead of the valid session from the URL. The expected behaviour of course is: give preference to valid session id's if we get more than one session id. The current session id grabbing-from-http-request algorithm is as follows (from HttpProcessor.java) 1. get the session ID from the URL, if any. [HttpProcessor.parseRequest()] 2. go through the cookies. If there is _any_ jsessionid - grab the _first one_ and override the jsession-id found in the URL unconditionally. And set request.setRequestedSessionCookie(true); request.setRequestedSessionURL(false); even if the jsession id found in the cookie is the _same_ as found in the URL, in that case it should be setRequestedSessionURL(true). [HttpProcessor.parseHeaders()] - However, it should be something like: - 1. get the jsessionid from the URL, if any. if found there, setRequestedSessionURL(true) else setRequestedSessionURL(false) 2. go through the cookies. FOREACH jsessionid found in the cookies: IF the sessionid found is valid in that context IF found session id equals id already in request setRequestedSessionCookie(true) ELSE (* see below) override the session id in request with the cookie-value setRequestedSessionCookie(true) setRequestedSessionURL(false) ENDIF BREAK FOREACH ELSE IF we have not found any session id before (either from URL or a previous cookie) // set at least some session id set the session id from the cookie setRequestedSessionCookie(true) END FOREACH - This makes sure, that we find the valid session id, if there is more than one session. discussion I'd even suggest to give a higher priority to the URL encoded session: if the session id found in the URL is _valid_, then ignore any valid session id in the cookies unless it is the same. This enables to have two independant web-application instances in the same browser: one with cookie, and one with URL-encoding (otherwise this mode only works with two applications both with URL-encoding). This behaviour can be implemented by adding -- IF not request.isRequestedSessionIdValid() -- at the point denoted with (*) above. /discussion In an attempt to fix this bug myself, I found, that at that stage it is not yet possible to check whether isRequestedSessionIdValid() [ implementation in HttpRequestBase ], since the context is not yet set in the HttpProcessor.process() stage -- so we don't have the manager and cannot check the session ID in that context for validity. The context is set much later in the processing in StandardHostMapper.map() after having gone through several valves/Pipelines. Since I don't know the internals of the tomcat (yet) I have no quick fix at hand, but for you guys its probably no big deal. Or give me an hint - then I'll fix it myself. To demonstrate this and the previously posted bug, I've written a small servlet, that goes through several steps to create two sessions; one as cookie, one with URL rewriting - just follow the instructions the servlet gives. Note, that Bug #2 can only be checked thoroughly if Bug #1 has been fixed; otherwise Bug #1 does not do URL-encoding in the first place. -- To
DO NOT REPLY [Bug 7588] - Session cannot be established if there are multiple session cookies
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=7588. 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=7588 Session cannot be established if there are multiple session cookies --- Additional Comments From [EMAIL PROTECTED] 2002-07-02 17:23 --- This is a Bug, that manifests itself in Bug #10419. Only the first cookie with a session-id is taken from the response, but it is not checked, whether this is a valid session within that context. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DOCS] Tyrex-Tomcat HOWTO
Thanks for fixing up my XML typos. I guess I personally don't really care where the Tyrex HOWTO goes.. Tyrex is a bit different though, so it may belong somewhere else. Only one comment: you put my Tyrex stuff under Tyrex Connection Pool and Castor ORM with mysql, and this is an inaccurate title. Tyrex is more than connection pooling, and it doesn't have anything to do with (at least the example doesn't) Castor ORM. Also, I didn't really mean for it to serve as an example for MySQL, because I didnt actaully test that config. That's my $0.02 about it :-) Thanks, David Les Hughes wrote: David / All, Had problems rendering your doc so I've patched it onto the end of mine and cleaned up the XML so that it styles up OK. Here it is. Comments? Les PS I will stop moaning about getting this committed, I promise... :-) -Original Message- From: Les Hughes [mailto:[EMAIL PROTECTED]] Sent: 02 July 2002 13:29 To: 'Tomcat Developers List' Subject: RE: [DOCS] Tyrex-Tomcat HOWTO Hi all, Could we add this into the JNDI Datasources HOWTO that I wrote the other week (I dont think this has been committed yet BTW) If someone can commit my HOWTO, I'll merge the two together and submit a patch this afternoon. Hope this is OK Les -Original Message- From: David Haraburda [mailto:[EMAIL PROTECTED]] Sent: 28 June 2002 20:05 To: [EMAIL PROTECTED] Subject: [DOCS] Tyrex-Tomcat HOWTO Hi all, Here is a short HOWTO I've written on how to use Tyrex 1.0 with Tomcat 4.1 (which goes along with the patch I submitted, which was just recently committed). I've added the appropriate XML tags, using the other HOWTOs as examples, so very little modification should be needed. Feedback on the content however, is greatly appreciated. :-) Thanks, David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Name: jndi-datasource-examples-howto.xml jndi-datasource-examples-howto.xmlType: XML Document (text/xml) Encoding: quoted-printable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/conf tomcat-jk2.manifest
costin 2002/07/02 12:45:50
Modified:jk build.xml
Added: jk/conf tomcat-jk2.manifest
Log:
Added a manifest for tomcat-jk2. It sets a minimal classpath and starts JkMain
Revision ChangesPath
1.45 +1 -2 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- build.xml 23 Jun 2002 19:04:48 - 1.44
+++ build.xml 2 Jul 2002 19:45:49 - 1.45
@@ -99,8 +99,6 @@
mkdir dir=${jk.build}/classes/
mkdir dir=${jk.build}/classes/META-INF /
mkdir dir=${jk.build}/lib/
-copy file=${commons-logging.jar}
- todir=${jk.build}/lib /
copy todir=${jk.build}/conf
fileset dir=conf includes=* /
/copy
@@ -190,6 +188,7 @@
/jar
jar jarfile=${jk.build}/lib/tomcat-jk2.jar
+ manifest=conf/tomcat-jk2.manifest
basedir=${jk.build}/classes
include name=org/apache/jk/** /
exclude name=org/apache/jk/ant/** /
1.1 jakarta-tomcat-connectors/jk/conf/tomcat-jk2.manifest
Index: tomcat-jk2.manifest
===
Main-Class: org.apache.jk.server.JkMain
Class-Path: tomcat-util.jar workers.jar ../classes/ commons-logging.jar log4j.jar
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
costin 2002/07/02 12:56:24
Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
Log:
Few changes to delay the introspection until it is neede.
Revision ChangesPath
1.3 +10 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
Index: DynamicMBeanProxy.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DynamicMBeanProxy.java6 Jun 2002 22:17:00 - 1.2
+++ DynamicMBeanProxy.java2 Jul 2002 19:56:24 - 1.3
@@ -79,7 +79,7 @@
Object real;
String name;
-Method methods[];
+Method methods[]=null;
Hashtable attMap=new Hashtable();
@@ -166,7 +166,10 @@
*/
public void setReal( Object realBean ) {
real=realBean;
+}
+private void init() {
+if( methods!=null ) return;
methods = real.getClass().getMethods();
for (int j = 0; j methods.length; ++j) {
String name=methods[j].getName();
@@ -213,7 +216,6 @@
continue;
invokeAttMap.put( name, methods[j]);
}
-
}
}
@@ -226,6 +228,9 @@
*
*/
public MBeanInfo getMBeanInfo() {
+if( methods==null ) {
+init();
+}
try {
MBeanAttributeInfo attributes[]=new MBeanAttributeInfo[attMap.size()];
@@ -272,6 +277,7 @@
public Object getAttribute(String attribute)
throws AttributeNotFoundException, MBeanException, ReflectionException
{
+if( methods==null ) init();
Method m=(Method)getAttMap.get( attribute );
if( m==null ) throw new AttributeNotFoundException(attribute);
@@ -291,6 +297,7 @@
public void setAttribute(Attribute attribute)
throws AttributeNotFoundException, InvalidAttributeValueException,
MBeanException, ReflectionException
{
+if( methods==null ) init();
Method m=(Method)setAttMap.get( attribute.getName() );
if( m==null ) throw new AttributeNotFoundException(attribute.getName());
@@ -316,6 +323,7 @@
public Object invoke(String method, Object[] arguments, String[] params)
throws MBeanException, ReflectionException
{
+if( methods==null ) init();
Method m=(Method)invokeAttMap.get( method );
if( m==null ) return null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
costin 2002/07/02 12:57:49
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
Allow customization of thread.setDaemon().
Previous versions of TP set all the threads in non-daemon mode, but
this can create restart problems in some cases. However non-daemon mode
is usefull in some cases
Revision ChangesPath
1.3 +19 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ThreadPool.java 22 Apr 2002 18:55:56 - 1.2
+++ ThreadPool.java 2 Jul 2002 19:57:49 - 1.3
@@ -125,6 +125,9 @@
*/
protected boolean stopThePool;
+/* Flag to control if the main thread is 'daemon' */
+protected boolean isDaemon=true;
+
static int debug=0;
/**
@@ -176,6 +179,18 @@
return maxSpareThreads;
}
+/** The default is true - the created threads will be
+ * in daemon mode. If set to false, the control thread
+ * will not be daemon - and will keep the process alive.
+ */
+public void setDaemon( boolean b ) {
+isDaemon=b;
+}
+
+public boolean getDaemon() {
+return isDaemon;
+}
+
//
// You may wonder what you see here ... basically I am trying
// to maintain a stack of threads. This way locality in time
@@ -395,7 +410,7 @@
shouldTerminate = false;
this.p = p;
t = new Thread(this);
-t.setDaemon(true);
+t.setDaemon(p.getDaemon() );
t.setName( MonitorRunnable );
t.start();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
costin 2002/07/02 12:58:27
Modified:jk/java/org/apache/jk/common ChannelSocket.java
jk/java/org/apache/jk/server JkMain.java
Log:
Add support for the daemon setting.
Minor fix in JkMain
Revision ChangesPath
1.17 +11 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ChannelSocket.java2 Jul 2002 16:57:30 - 1.16
+++ ChannelSocket.java2 Jul 2002 19:58:27 - 1.17
@@ -201,6 +201,17 @@
public int getInstanceId() {
return port-startPort;
}
+
+/** If set to false, the thread pool will be created in
+ * non-daemon mode, and will prevent main from exiting
+ */
+public void setDaemon( boolean b ) {
+tp.setDaemon( b );
+}
+
+public void getDaemon() {
+return tp.getDaemon();
+}
/* */
ServerSocket sSocket;
1.27 +1 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- JkMain.java 5 Jun 2002 21:24:29 - 1.26
+++ JkMain.java 2 Jul 2002 19:58:27 - 1.27
@@ -208,6 +208,7 @@
// XXX use IntrospectionUtil to find myself
this.guessHome();
}
+home=wEnv.getJkHome();
if( home != null ) {
File hF=new File(home);
File conf=new File( home, conf );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java
costin 2002/07/02 13:00:16
Modified:jk/java/org/apache/jk/common ChannelSocket.java
Log:
No comment...
Revision ChangesPath
1.18 +1 -1
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ChannelSocket.java2 Jul 2002 19:58:27 - 1.17
+++ ChannelSocket.java2 Jul 2002 20:00:15 - 1.18
@@ -209,7 +209,7 @@
tp.setDaemon( b );
}
-public void getDaemon() {
+public boolean getDaemon() {
return tp.getDaemon();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10423] New: - Premature packet header end
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=10423. 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=10423 Premature packet header end Summary: Premature packet header end Product: Tomcat 4 Version: 4.0.3 Final Platform: All URL: http://www.challenger.com OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This seems similiar to bug#3509 but here is my story. I'm using tomcat 4.0.3 final, apache 1.3.26, redhat linux 7.3. In my 'apache_log__mm_dd' log file I get this error/warning (at the bottom of this) From my research I really couldn't find much. One comment somewhere in bugzilla said this wasn't a bug, just a warning. (I can't find that same message) My site works from what I can determine from my testing, I just want to make sure that my customers aren't seeing any sort of errors when viewing the static and java servlet pages. Thanks! ... 2002-07-02 15:14:11 WarpEngine[www.challenger.com]: Mapping request 2002-07-02 15:14:11 WarpHost[www.challenger.com]: Mapping request for Host 2002-07-02 15:14:26 WarpEngine[www.challenger.com]: Mapping request 2002-07-02 15:14:26 WarpHost[www.challenger.com]: Mapping request for Host 2002-07-02 15:16:23 [org.apache.catalina.connector.warp.WarpConnector] Connection from 10.10.10.2/10.10.10.2:33437 to 10.10.10.2/10.10.10.2:8008 2002-07-02 15:16:23 [org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings (0) 2002-07-02 15:16:24 [org.apache.catalina.connector.warp.WarpConnector] Connection from 10.10.10.2/10.10.10.2:33438 to 10.10.10.2/10.10.10.2:8008 2002-07-02 15:16:24 [org.apache.catalina.connector.warp.WarpConnector] Connection from 10.10.10.2/10.10.10.2:33439 to 10.10.10.2/10.10.10.2:8008 2002-07-02 15:16:24 [org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings (0) 2002-07-02 15:16:24 [org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings (0) 2002-07-02 15:16:40 [org.apache.catalina.connector.warp.WarpConnection] Exception on socket java.io.IOException: Premature packet header end at org.apache.catalina.connector.warp.WarpConnection.recv (WarpConnection.java:237) at org.apache.catalina.connector.warp.WarpRequestHandler.handle (WarpRequestHandler.java:112) at org.apache.catalina.connector.warp.WarpConnection.run (WarpConnection.java:194) at java.lang.Thread.run(Thread.java:479) 2002-07-02 15:16:42 [org.apache.catalina.connector.warp.WarpConnection] Exception on socket java.io.IOException: Premature packet header end at org.apache.catalina.connector.warp.WarpConnection.recv (WarpConnection.java:237) at org.apache.catalina.connector.warp.WarpRequestHandler.handle (WarpRequestHandler.java:112) at org.apache.catalina.connector.warp.WarpConnection.run (WarpConnection.java:194) at java.lang.Thread.run(Thread.java:479) 2002-07-02 15:16:44 [org.apache.catalina.connector.warp.WarpConnection] Exception on socket java.io.IOException: Premature packet header end at org.apache.catalina.connector.warp.WarpConnection.recv (WarpConnection.java:237) at org.apache.catalina.connector.warp.WarpRequestHandler.handle (WarpRequestHandler.java:112) at org.apache.catalina.connector.warp.WarpConnection.run (WarpConnection.java:194) at java.lang.Thread.run(Thread.java:479) 2002-07-02 15:26:24 WarpEngine[www.challenger.com]: Mapping request 2002-07-02 15:26:24 WarpHost[www.challenger.com]: Mapping request for Host 2002-07-02 15:26:25 WarpEngine[www.challenger.com]: Mapping request 2002-07-02 15:26:25 WarpHost[www.challenger.com]: Mapping request for Host 2002-07-02 15:52:29 WarpEngine[www.challenger.com]: Mapping request 2002-07-02 15:52:29 WarpHost[www.challenger.com]: Mapping request for Host -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10425] New: - Null Pointer Exception on all requests to tomcat after start
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=10425. 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=10425 Null Pointer Exception on all requests to tomcat after start Summary: Null Pointer Exception on all requests to tomcat after start Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Quite often when i start Tomcat I make a http request to the server and on the server side the following exception prints out. On the client side the browser just sits awaiting a response from Tomcat till it times out. This occurs till the server is restarted, it does not recover from the error. Exception on the console: java.lang.NullPointerException at java.io.Writer.write(Writer.java:126) at java.io.PrintWriter.newLine(PrintWriter.java:254) at java.io.PrintWriter.println(PrintWriter.java:405) at java.io.PrintWriter.println(PrintWriter.java:516) at org.apache.catalina.logger.LoggerBase.log(LoggerBase.java:262) at org.apache.catalina.connector.http.HttpProcessor.log (HttpProcessor.java:421) at org.apache.catalina.connector.http.HttpProcessor.process (HttpProcessor.java:1026) at org.apache.catalina.connector.http.HttpProcessor.run (HttpProcessor.java:1107) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
4.1.7 / mod_jk 1.2.0 / mod_jk 2.0.0
Remy: I just fixed one serious bug in jk2/java ( the one reported by David Oxley ). I think we need a 4.1.7 for that ( and possibly other bug fixes ). We are pretty close IMHO. Henri: what about tagging the workspace for mod_jk1 with 1.2.0, and use the same naming convention as in 4.1.x. Nacho, Mladen: same thing for mod_jk2 - we should use the 'milestone' style, and mod_jk2.0.0 will be the first tagged milestone. There is no need for anything fancy - it's just an alpha release. I think we should try to synchronize a bit - and maybe tag jk1.2.0 and jk2.0.0 at the same time with 4.1.7. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.7 / mod_jk 1.2.0 / mod_jk 2.0.0
On Tue, 2002-07-02 at 15:47, [EMAIL PROTECTED] wrote:
Remy: I just fixed one serious bug in jk2/java ( the one reported by
David Oxley ). I think we need a 4.1.7 for that ( and possibly other
bug fixes ). We are pretty close IMHO.
Henri: what about tagging the workspace for mod_jk1 with 1.2.0,
and use the same naming convention as in 4.1.x.
Nacho, Mladen: same thing for mod_jk2 - we should use the 'milestone'
style, and mod_jk2.0.0 will be the first tagged milestone. There is
no need for anything fancy - it's just an alpha release.
I think we should try to synchronize a bit - and maybe tag jk1.2.0
and jk2.0.0 at the same time with 4.1.7.
For what it is worth, here are two patches (not pretty) to get the
tomcat 4.1.6-LE-jdk1.4 to compile with the struts-1.1-b1. Don't know if
you want this for 4.1 final.
--- jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/build.xml~ Fri Jun
28 11:03:48 2002
+++ jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/build.xml Sat Jun 29
17:27:13 2002
@@ -22,6 +22,7 @@
pathelement location=${jmx.jar}/
pathelement location=${servlet.jar}/
pathelement location=${struts.jar}/
+pathelement location=${commons-beanutils.jar}/
/path
@@ -140,6 +141,7 @@
!-- BUILD: Copy JARs
== --
target name=copy-struts.jar if=struts.present
copy todir=${webapps.build}/${webapp.name}/WEB-INF/lib
file=${struts.jar}/
+copy todir=${webapps.build}/${webapp.name}/WEB-INF/lib
file=${commons-beanutils.jar}/
copy todir=${webapps.build}/${webapp.name}/WEB-INF
file=${struts.lib}/struts-bean.tld/
copy todir=${webapps.build}/${webapp.name}/WEB-INF
file=${struts.lib}/struts-html.tld/
copy todir=${webapps.build}/${webapp.name}/WEB-INF
file=${struts.lib}/struts-logic.tld/
AND:
---
jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java~
Fri Jun 28 11:03:48 2002
+++
jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java
Sat Jun 29 17:07:50 2002
@@ -70,8 +70,7 @@
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.jsp.tagext.TagSupport;
-import org.apache.struts.util.PropertyUtils;
-
+import org.apache.commons.beanutils.PropertyUtils;
/**
* Custom tag that retrieves a JMX MBean attribute value, and writes it
--
Brian Millett
Enterprise Consulting Group Shifts in paradigms
(314) 205-9030 often cause nose bleeds.
[EMAIL PROTECTED] Greg Glenn
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Question about patch submission
Hey all, Quick question about patch submission: I submitted a patch a week or so ago and was curious if it was even received or acknowledged or anything or simply diverted to /dev/null. If it was rejected is there any protocol for the submitter getting notice or anything? thx, russ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call.
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=10405. 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=10405 ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call. --- Additional Comments From [EMAIL PROTECTED] 2002-07-02 23:12 --- DecodeInterceptor expects charset to be a String. Why do need it to be an Object? Bojan PS. Here is that line of code: -- charset=(String)req.getAttribute( charsetAttribute ); -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.7 / mod_jk 1.2.0 / mod_jk 2.0.0
[EMAIL PROTECTED] wrote: Remy: I just fixed one serious bug in jk2/java ( the one reported by David Oxley ). I think we need a 4.1.7 for that ( and possibly other bug fixes ). We are pretty close IMHO. Henri: what about tagging the workspace for mod_jk1 with 1.2.0, and use the same naming convention as in 4.1.x. Nacho, Mladen: same thing for mod_jk2 - we should use the 'milestone' style, and mod_jk2.0.0 will be the first tagged milestone. There is no need for anything fancy - it's just an alpha release. I think we should try to synchronize a bit - and maybe tag jk1.2.0 and jk2.0.0 at the same time with 4.1.7. Ok. I'll see if there are some other critical fixes that are needed to 4.1.6. So far, I didn't get any report of serious problems (except DBCP issues; I'll update again to pick up the latest changes; Glenn, could you comment on that if you're around ?), so I'd say it looks good and I'll do the release (and I hope it will be beta worthy :-D). We'll have to go do a cleanup of Bugzilla someday. Many bugs there are not relevant to 4.1.x, though. I'll try to update the version of those which are confirmed or in need of a review to be to a 4.1.x number. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question about patch submission
Putting the patch in bugzilla makes it easier to track and cannot get lost that way ;-) Mvgr, Martin On Wed, 2002-07-03 at 01:10, Russ Trotter wrote: Hey all, Quick question about patch submission: I submitted a patch a week or so ago and was curious if it was even received or acknowledged or anything or simply diverted to /dev/null. If it was rejected is there any protocol for the submitter getting notice or anything? thx, russ -- 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: [4.1.6] Milestone available for testing
On Tue, 2 Jul 2002, Chad Johnson wrote: Date: Tue, 2 Jul 2002 10:53:32 -0500 From: Chad Johnson [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [4.1.6] Milestone available for testing Hey, I may have missed something obvious, but if I didn't, are there plans to add context reset/stop/start to the new administration webapp? Those facilities are all available in the Manager webapp. Because manager is accessed via HTTP, it is very easy to integrate these capabilities into your development environment -- for example, 4.1.x includes custom Ant tasks that install/reload/remove apps directly from your build.xml file, and the deploytool that ships with the Java Web Services Developer Pack (JWSDP) http://java.sun.com/webservices/ uses them behind the scenes to provide a GUI experience people packaging and deploying web applications. -Chad Johnson Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 PROPOSAL-5.0.txt
remm2002/07/02 16:42:47 Modified:.PROPOSAL-5.0.txt Log: - Add links to the specification drafts. Revision ChangesPath 1.4 +5 -1 jakarta-tomcat-4.0/PROPOSAL-5.0.txt Index: PROPOSAL-5.0.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/PROPOSAL-5.0.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- PROPOSAL-5.0.txt 28 Jun 2002 17:47:15 - 1.3 +++ PROPOSAL-5.0.txt 2 Jul 2002 23:42:47 - 1.4 @@ -127,12 +127,16 @@ limited, and shouldn't cause any major architectural changes in Catalina. Catalina 2.0 will also inherit from all the refactorings done in Catalina 1.1. +Servlet 2.4 Specification Draft: +http://jcp.org/aboutJava/communityprocess/review/jsr154/index.html + E) Implementation of the JSP 2.0 Specification Jasper 2 will be modified to support the new JSP Specification. More important changes will be required than for supporting the new Servlet Specification. - +JSP 2.0 Specification Draft: +http://jcp.org/aboutJava/communityprocess/review/jsr152/index.html Resources needed: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] Apache Tomcat 5.0 Proposal
After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy Proposal for Apache Tomcat 5.0 == Introduction: This document is a proposal for the next major release of Apache Tomcat, Apache Tomcat 5.0. Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache Tomcat 4.1 architectures, by making them simpler, more flexible and more modular, while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications, currently under development by the Java Community Process. The major goals for Apache Tomcat 5.0 are to: - improve scalability, reliability and performance over previous versions - have simpler/cleaner code, so more people can get involved - merge of the various ideas in 3.x and 4.x - get the community togheter - provide maximum modularity and compliance to the standards - make it easy to continue to maintain the existing codebases Testing will occur to make sure the stated robustness and performance goals are met by Tomcat 5.0. This proposal also tries to take advantage of the lessons learned while optimizing and maintaining Tomcat. Note: The development of Apache Tomcat 4.1.x will continue in parallel to the implementation of this proposal. General architecture: An improved version of Coyote 1.0, called Coyote 2.0, will be used as the Apache Tomcat 5.0 core. Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under development in the jakarta-tomcat-connectors repository. Coyote 1.0 includes: - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI - Adapter for Tomcat 3.3 - Adapter for Tomcat 4.x Extensibility capabilities will be added to Coyote, as well as JMX management features, and if possible, addional protocol handlers (like WARP 1.0). The Servlet API 2.4 specification will be implemented in a new version of Catalina, called Catalina 2.0. A new version of the Coyote adapter will be written for it if mandated by API changes. Components which duplicate functionality provided by Coyote will be removed, including the old connectors. On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed to Jasper 3, and is the proposed Jasper codebase. It provides many improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including good tag library handling, and near zero overhead when compared to an equivalent hand coded servlet. Jasper 2 will also undergo additional optimizations. Apache Tomcat 5.0 will be made by default of the following components: - Coyote 2.0 - core - Catalina 2.0 - Servlet API 2.4 implementation - Jasper 2 - JSP 2.0 implementation Many other configurations are also possible, and it is expected that advanced users take advantage of it to make Tomcat better suit their needs. It is also possible that new special purpose components, like a bare bones Servlet API implementation, be developed to address the embedded market. Due to the scope of this work, this initial Proposal only plans the implementation and support of the default configuration described above. Changes over Apache Tomcat 4.1.x: A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code. The following major changes and additions are proposed to the current Apche Tomcat code, and related dependencies: A) Removal of the org.apache.catalina.connector.* This package is currently deprecated in Tomcat 4.1 because of its implementation inefficiencies, and general bad design. It is thus proposed that it is removed in Tomcat 5.0. B) Addition of new loader code for the commons-daemon subproject It is proposed that, in an attempt to solve the problems with using startup scripts, as well as adding additional features oriented towards reliability (including the capability to restart Tomcat automatically should the JVM crashes or experience memory management related problems), the launcher code which will be developed as part of commons-daemon be adopted. This code will be based in part on the launcher code used for the Sun Web Services Pack, and in part on the Wrapper project code (available at SF.net), if we manage to come to an agreement with the Wrapper developers. C) Extensions to Coyote It is proposed that Coyote 2.0 include the following changes over Coyote 1.0: - The current hook mechanism used in Coyote 1.0 will be extended to be more generic and
DO NOT REPLY [Bug 9941] - Jasper in Tomcat 4.1.2 throws JasperExcepetion when comiling JSP's
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=9941. 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=9941 Jasper in Tomcat 4.1.2 throws JasperExcepetion when comiling JSP's [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
On Tue, 2 Jul 2002, Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. I won't read the mail for the rest of the week ( I'll be back next Mon ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlet authentication
Looks like you're right.
Thanks,
Mike
From: Kevin Seguin
Subject: RE: servlet authentication
Date: Tue, 02 Jul 2002 02:39:06 -0700
i could be wrong, but i think once you call
sendError(), the response is committed and
you cannot set any more headers. try reversing the
order of the
sendError()/setHeader() calls:
response.setHeader(WWW-Authenticate, BASIC
realm=\test\);
response.sendError(response.SC_UNAUTHORIZED);
-Original Message-
From: Michael Bergknoff [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 9:02 PM
To: [EMAIL PROTECTED]
Subject: servlet authentication
To test servlet-based authentication, I have a two
line servlet.
response.sendError(response.SC_UNAUTHORIZED);
response.setHeader(WWW-Authenticate,
BASIC
realm=\test\);
Here is the output I get:
$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /myapp/servlet
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family :
sans-serif,Arial,Tahoma;color :
white;background-color
: #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color :
black;background-color
: white;} B{color : white;background-color :
#0086b2;}
HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status
401
- Unauthorized/h1HR size=1
noshadepbtype/b
Status report/ppbmessage/b
uUnauthorized/u/ppbdescription/b
uThis
request requires HTTP authentication
(Unauthorized)./u/pHR size=1
noshade/body/htmlConnection closed by foreign
host.
The output contains no HTTP headers, just some
Tomcat
generated HTML. Is this a bug in my servlet test or
what?
Thanks,
Mike
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Fwd: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET]
I've verified this change of behavior between Tomcat 4.0.3 and Tomcat
4.0.4, and Barry Levinson has tracked down the probable cause.
Despite the omission of the port in Host request headers by Microsoft
.Net software (VS.NET and WSDL.EXE), Tomcat 4.0.3 was able to properly
determine the port in calls to HTTPUtils.getRequestURL, Tomcat 4.0.4
defaults it.
Suggestions? Why can't Tomcat simply use socket.getPort()?
Original Message
Subject: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET
Date: Tue, 2 Jul 2002 15:11:38 -0400
From: Barry Levinson [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
some more info :
looks like HttpProcessor.java changed in tomcat exposesing this VS .net
bug :
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/ap
ache/catalina/connector/http/HttpProcessor.java
Revision 1.44 / (view) - annotate - [select for diffs] , Thu Feb 28
04:23:17 2002 UTC (4 months ago) by remm
Branch: MAIN
CVS Tags: jwsdp_10_ea2_10, jwsdp_10_ea2_09, jwsdp_10_ea2_08,
jwsdp_10_ea2_07, jwsdp_10_ea2_06, jwsdp_10_ea2_05
Changes since 1.43: +9 -4 lines
Diff to previous 1.43 (colored)
- Fix bug 6668.
- If no port is specified, the default port for the service is assumed.
Note: This
can break broken clients, as it forces them to specify the port in the
host header.
- Patch submitted by Craig Setera craig.setera at kingland.com
VS .net seems to be broken in violation of rfc 2616 section 14.23 :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23
I wonder what the chances of getting MS to fix this are? Anyone know who
to email a bug report to?
--Barry
-Original Message-
From: Barry Levinson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET
oops : I'm running tomcat 4.0.4
When I downloaded an ran tomcat 4.0.3, of course VS .net still specifies
the incorrect Host:localhost in the HTTP header, however, tomcat responds
with the correct port in the WSDL. in 4.0.3 tomcat must get the URL info
from a combination of the connection record, and the URL specified in HTTP
1.1.
I have an additional problem with .net when the wsdl specifies the wrong
URL. If the URL is not correct, the session is not correctly maintained
from the returned cookie. This is the case even if I manually change the
URL in the .net generated client stubs.
For now, I'll use 4.0.4 tomcat.
BTW - is this list moderated? Why do my emails seem to have a 3-6hr
delay?
--Barry
-Original Message-
From: Barry Levinson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 11:21 AM
To: [EMAIL PROTECTED]
Subject: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET
From running tcpmon, it looks like Visual Studio .net doesn't specify the
correct URL in it's HTTP Host: line. Instead of specifying Host:
localhost:8081 it specifies Host: localhost. This is probably why the
wsdl comes back with the incorrect url.
I'm running tomcat 4.0.3.
I'll download Tomcat 4.0.2 and try it again to see if there are any
differences.
--Barry
-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Strange bug: Axis in Tomcat 4.0.4 and .NET
Arne M. Degenring wrote:
Hi everybody,
I recently upgraded to Tomcat 4.0.4 and found out a problem with .NET.
I'm running Tomcat on port 8081. When I access a WSDL file via IE 6.0
at:
http://localhost:8081/axis/services/SomeWS?wsdl
I get back the WSDL file which contains the correct adress location:
wsdlsoap:address
location=http://localhost:8081/axis/services/SomeWS/
No problem so far. BUT: When I access the same WSDL URL from the
Microsoft .NET platform, e.g. via .NET WebService Studio or via .NET's
wsdl.exe tool, the port number is missing in the WSDL's adress
location!!
wsdlsoap:address location=http://localhost/axis/services/SomeWS/
.NET's generated proxy class (SubmitWSService.cs) does not work, of
course, because of the missing port number. This strange behaviour first
occured after I upgraded to Tomcat 4.0.4. No problem with 4.0.3.
BTW: I'm using the Axis build 2002-07-01.
Any ideas?
I'll try to reproduce. I've verified that 2002-07-01 w/Tomcat 4.0.3
works, running wsdl.exe against
http://nagoya.apache.org:5049/axis/services/SoapInteropImport1Port?wsdl
results in
public Import1() {
this.Url =
http://nagoya.apache.org:5049/axis/services/SoapInteropImport1Port;;
}
- Sam Ruby
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call.
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=10405. 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=10405 ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call. --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 05:02 --- API doc says containers can use request attributes. I did not know that. I was worrying about the conflicts of the attribute names used by application and container. So, this is not a bug, but the API doc says that the attribute name should follow the same conventions as package names; i.e. org.apache..charset. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call.
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=10405. 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=10405 ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call. --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 05:26 --- I'm not sure if anything in Tomcat depends on this behaviour. Anyway, you can always work around this by using your own unique attibute identifiers. Something like: domain-name.package-name.app-name.charset Then it won't get in the way. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call.
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=10405. 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=10405 ClassCastException is thrown when request.setAttribute(charset, non_string) is called before request.getParameter() call. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 05:27 --- The charset attribute is documented at http://jakarta.apache.org/tomcat/tomcat-3.3- doc/serverxml.html#DecodeInterceptor, where it also tells you how to change the name if you want to use charset for yourself. Given that this particular attribute is supposed to be set by the web-app developer (it's the TC 3.3 version of the 2.3 setCharacterEncoding), I think that having a simple name is justified. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10321] - Encoding problem in solaris environment (Solaris 2.6)
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=10321. 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=10321 Encoding problem in solaris environment (Solaris 2.6) --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 06:09 --- On my Solaris 2.7 box, I have no problems getting Tomcat to guess UTF-8 for simple examples. For a discription of the settings, See: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html Things to try: 1) If the page containing the form is a static (i.e. foobar.html) page, then you might want to upgrade to 3.3.1 and take advantage of the useAcceptLanguage and/or useCharset attribute of StaticInterceptor. 2) If your entire site uses UTF-8, you could set the defaultEncoding=UTF-8 attribute on DecodeInterceptor. 3) If you don't care about portability to other servlet-containers, you could modify your servlet to call: request.setAttribute(charset, UTF-8); before any of the parameters are processed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
