Problem downloading 5.5.12-alpha Re: [ANN] Apache Tomcat 5.5.12-alpha Released
From: Yoav Shapira [EMAIL PROTECTED] Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5 Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5 The filenames are wrong for the 5.5.12-alpha downloads. They all point to jakarta-tomcat-5.5.12* instead of apache-tomcat-5.5.12*. The files are there if you change the URL in the browser, but the links do not work. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem downloading 5.5.12-alpha Re: [ANN] Apache Tomcat 5.5.12-alpha Released
Hi, I just fixed this, and the fix will be on the web site in ~15 minutes. My apologies, and thanks for letting us know quickly ;) Yoav --- Wendy Smoak [EMAIL PROTECTED] wrote: From: Yoav Shapira [EMAIL PROTECTED] Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5 Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5 The filenames are wrong for the 5.5.12-alpha downloads. They all point to jakarta-tomcat-5.5.12* instead of apache-tomcat-5.5.12*. The files are there if you change the URL in the browser, but the links do not work. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36735] New: - Problem with SSL - swf - Explorer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36735. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36735 Summary: Problem with SSL - swf - Explorer Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When requesting a page with one or more swf files from MS Internet Explorer 6 (maybe any version) using the SSL encryption protocol to a Tomcat 5.0.28 o 5.0.30 (maybe all 5.0.x family) the html and images are loaded correctly, but the swf is not. When requesting directly a swf file from the url (in https) the browser response with a Page cannot be found message. Everything works fine using Mozilla FireFox or when the container is Tomcat 4.1.x. I've tried only with a self made certificate on Win 2k and Linux RHEL AS 3U5. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36735] - Problem with SSL - swf - Explorer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36735. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36735 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-09-20 19:13 --- *** This bug has been marked as a duplicate of 27122 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36437] New: - problem this requestURI decoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36437. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36437 Summary: problem this requestURI decoding Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] in class org.apache.catalina.connector.Connector field's /** URI encoding as body. */ protected boolean useBodyEncodingForURI = false; default value is false; this causes that httpServletRequest.setCharacterEncoding(some-encoding) doesn't affect requestURI decoding. Think this should be changed to protected boolean useBodyEncodingForURI = true; -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36437] - problem this requestURI decoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36437. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36437 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Summary|problem this requestURI |problem this requestURI |decoding|decoding -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36218] - principal replication problem in cluster
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36218 --- Additional Comments From [EMAIL PROTECTED] 2005-08-22 11:21 --- Hmm, the JAASRealm.createPrincipal return a GenericPrincipal s. L.509 // Return the resulting Principal for our authenticated user return new GenericPrincipal(this, username, null, roles, userPrincipal); Can you better discribe your failure szenario? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36218] - principal replication problem in cluster
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36218 --- Additional Comments From [EMAIL PROTECTED] 2005-08-22 11:52 --- it seems I was looking at (and using) the 5.5.9 stable source code, not the 5.5.10 HEAD. You are correct, this looks better. Let me do a new CVS checkout, build and test this was my error message: 107 55946 ERROR session.DeltaRequest - DeltaManager only support GenericPrincipal. Your realm used principal class com.lostboys.playground.common.security.UserPrincipal. and our UserPrincipal extends java.security.Principal (In reply to comment #3) Hmm, the JAASRealm.createPrincipal return a GenericPrincipal s. L.509 // Return the resulting Principal for our authenticated user return new GenericPrincipal(this, username, null, roles, userPrincipal); Can you better discribe your failure szenario? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] New: - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 Summary: problem with Failover in jk_lb_worker.c Product: Tomcat 5 Version: 5.0.30 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Apache 1.3.33 Tomcat 5.0.30 mod_jk 1.2.14 Solaris 9 Hi, There seems to be a problem in supporting Failover of a failed Tomcat server on Solaris 9 with mod_jk 1.2.14. When I simulate the failed Tomcat server by pulling the network cable, the worker will do all the appropriate socket_timeouts and retries, but when that fails, as it should, another worker is not chosen, and the failed worker is not put in_error. Here is a snippet from the log: [trace] service::jk_lb_worker.c (551): enter [trace] get_most_suitable_worker::jk_lb_worker.c (453): enter [debug] get_most_suitable_worker::jk_lb_worker.c (539): found best worker (giraffe) using by request method [trace] get_most_suitable_worker::jk_lb_worker.c (543): exit [debug] service::jk_lb_worker.c (587): service worker=giraffe jvm_route=giraffe [trace] ajp_service::jk_ajp_common.c (1630): enter [debug] ajp_service::jk_ajp_common.c (1670): processing with 3 retries [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=2 [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=3 [error] ajp_service::jk_ajp_common.c (1758): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=giraffe failed [trace] ajp_service::jk_ajp_common.c (1768): exit log ends The ajp_service::jk_ajp_common.c method is called by the service::jk_lb_worker.c method, but there are no more log messages after ajp_service returns. We should at least see an exit trace log for the service method. I put in logging statements in the code, and found the offending lines. From jk_lb_worker.c ln. 603-607: service_stat = end-service(end, s, l, is_service_error); /* IT IS ONE OF THESE TWO LINES THAT CAUSES THE THREAD TO DIE OR HANG */ rec-s-readed += end-rd; rec-s-transferred += end-wr; end-done(end, l); A logging message directly after the end-service method is called is seen, but one right before the end-done method is called is not. In any case, if I comment out the two lines that update the shared memory, everything works as expected. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 21:09 --- Created an attachment (id=16117) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16117action=view) A full log file showing one failed request -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 21:33 --- I would like to see your workers.properties and the Jk directives in your httpd configuration. Also: Could you please check, if the failing Apache child processes are still there, or if they died? The log chows the PID of the relevant process directly behind the date. If the process is still there, you can use /usr/proc/bin/pstack PID to write a thrad dump. That way we can confirm, in which function the hanging process sits. You could attach the pstack. If the process is not there any more, it might have crashed. In case you succeed in dumping a core file of the process, you can again use pstack on that core file. Finally it might be interesting to use truss (or if you are already familiar with it dtrace) to find out, if the error is related to some system call. Configure apache to only use very few children (like startng 2 servers and having sparemax and min also equals to 2). Start the server via truss -f -o some_output_file -w all -r all -v all \ /usr/local/apache/bin/apachectl start and then redo your tests (apache will be a little slow). The file some_output_file contains information about all system calls, about bytes read and written, signals received, errnos etc. To have a somewhat easier test case: In the log you attached one can see, that the working request for the html produces to image requests going to two apache processes in parallel which both fail. I ould be a simpler retest to only use single requests, not something in parallel, e.g. not automatically reloading embedded objevcts via the browser. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:21 --- Created an attachment (id=16119) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16119action=view) workers.properties -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:22 --- Created an attachment (id=16120) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16120action=view) Mod_jk configuration file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 22:24 --- The pstack returned nothing, and I confirmed by watching TOP that the process is created then dies when the http request is over. I am having trouble running truss, I'll get back to you with that when I can. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 23:43 --- Config is pretty basic and looks OK. The process dead is strange and I don't see an immediate reason for it. It would be good, if you could reproduce it with without parallel requests to simplify the situation. Did you build apache and mod_jk yourself? Have they been compiled using the same compiler and the same CFLAGS? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36281] - problem with Failover in jk_lb_worker.c
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36281 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-08-20 01:28 --- Sorry for all this. We were building on a seperate machine using the gcc compiler, because our primary Sun build machine wasnt working at the time. Now it is and I recompiled on it, and everything is hunkey-dorey now. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36218] - principal replication problem in cluster
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36218 --- Additional Comments From [EMAIL PROTECTED] 2005-08-18 18:09 --- I tested it with the MemoryRealm settings using tomcat-users.xml for data of users, and the fix works. This with FORM authentication. however, we would like to use our custom JAAS login module. For this we programmed a module, and added 2 Principals to the config for user and role. These classes extend java.security.Principal. And this does not work yet. I think it has to do with the method createPrincipal(String username, Subject subject) in org.apache.catalina.realm.JAASRealm. All the other real implementations deal with GenericPrincipal, while here java.security.Principal is used. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36218] New: - principal replication problem in cluster
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36218 Summary: principal replication problem in cluster Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] when using clustering the Principal seems not to be replicated correctly It seems to be linked to the UserDatabaseRealm, using a o.a.c.users.MemoryUser principal instead of a GenericPrincipal see: http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg74250.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36218] - principal replication problem in cluster
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36218 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-08-17 12:46 --- Now the UserDatabaseRealm also create GenericPrincipal class and at my test cases with basic login config at web.xml it works. OK, the set userPrincipal from GenericPrincipal are not transfered and this can be a problem. Please, can you checkout the last tomcat cvs head and test the fix? Thanks Peter -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26183] - ServletResponse#reset() method and cookie session control problem on tomcat4.1.24
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26183 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 13:23 --- *** Bug 36023 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26183] - ServletResponse#reset() method and cookie session control problem on tomcat4.1.24
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26183 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 13:40 --- Why is this bug closed? If the specification doesn't say anything about it, do what is most convenient for the users/developers. Other servletcontains add the session-cookie - even if reset() was called. So perhaps Tomcat should do that too. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36001] New: - @include file encoding problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36001. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36001 Summary: @include file encoding problem Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] If I use %@ include file=foo2.jsp% in foo.jsp, where foo2.jsp contains a different encoded text other than 8859, seems that foo.jsp cannot display the correct text. If I put foo2.jsp literally in foo.jsp without using include directive, everthing works fine. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-31 09:11 --- Please show where the Tomcat bug is (response dumps, etc): we're not going to install the crap that is quicktime simply to investigate this. Likely the old qt release doesn't support the HTTP response that JK is sending. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:AJP |Connector:HTTP -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|All |Windows XP -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35914] New: - Problem to create and delete Access Log Valve many times
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35914. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35914 Summary: Problem to create and delete Access Log Valve many times Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: Webapps:Administration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm adding test cases to JOnAS administration console and I have a problem to remove Access Log Valve. I have reproduced the problem with Tomcat administration. 1-I create a new Access Log Valve in directory logs/ 2-I delete the valve 3-I create a new Access Log Valve in directory logs/ again 4-I try to delete the valve and I have an error : org.apache.commons.modeler.BaseModelMBean invoke GRAVE: Exception invoking method removeValve java.lang.NullPointerException at org.apache.catalina.mbeans.MBeanFactory.removeValve(MBeanFactory.java:1069) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:501) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:221) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:84) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:203) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1043) at org.apache.webapp.admin.valve.DeleteValvesAction.execute(DeleteValvesAction.java:124) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1192) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:430) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.webapp.admin.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:123) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) I think that the error is when the valve is removed
DO NOT REPLY [Bug 35827] New: - Problem with POST forms with jk connector/IIS/WindowsXP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35827 Summary: Problem with POST forms with jk connector/IIS/WindowsXP Product: Tomcat 5 Version: 5.0.19 Platform: PC URL: http://www.proyectoquorum.com OS/Version: Windows XP Status: NEW Severity: blocker Priority: P4 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hello. We have several servers with Windows 2003/IIS/Tomcat 5.0.19 working fine. Now, we have tried to install the same code on a XP machine, SP1, and everything works fine except the POST traffic, when we submit a form. This issue is related to: http://issues.apache.org/bugzilla/show_bug.cgi?id=30551 When we use a POST form, the browser fail by timeout, and we find this information in the log: 21-jul-2005 13:12:32 org.apache.jk.common.HandlerRequest invoke GRAVE: Error decoding request java.io.IOException at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:294) at org.apache.jk.common.HandlerRequest.decodeRequest (HandlerRequest.java:570) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:393) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:716) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:650) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:829) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:688) at java.lang.Thread.run(Thread.java:536) 12 34 02 23 02 04 00 08 48 54 54 50 2f 31 2e 31 | .4.#HTTP/1.1 00 00 1d 2f 6e 70 6f 72 74 61 6c 2f 62 6d 73 5f | .../nportal/bms_ 63 6f 72 70 2f 64 6f 6c 6f 67 69 6e 2e 6a 73 70 | corp/dologin.jsp 00 00 09 31 32 37 2e 30 2e 30 2e 31 00 00 09 31 | ...127.0.0.1...1 32 37 2e 30 2e 30 2e 31 00 00 09 6c 6f 63 61 6c | 27.0.0.1...local 68 6f 73 74 00 00 50 00 00 0c a0 01 00 85 69 6d | host..P...?..?im 61 67 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 | age/gif, image/x 2d 78 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f | -xbitmap, image/ 6a 70 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65 | jpeg, image/pjpe 67 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 | g, application/v 6e 64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 70 | nd.ms-excel, app 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 2d | lication/vnd.ms- 70 6f 77 65 72 70 6f 69 6e 74 2c 20 61 70 70 6c | powerpoint, appl 69 63 61 74 69 6f 6e 2f 6d 73 77 6f 72 64 2c 20 | ication/msword, 2a 2f 2a 00 a0 04 00 02 65 73 00 a0 06 00 0a 4b | */*.?...es.?...K 65 65 70 2d 41 6c 69 76 65 00 a0 0b 00 09 6c 6f | eep-Alive.?...lo 63 61 6c 68 6f 73 74 00 a0 0d 00 2c 68 74 74 70 | calhost.?..,http 3a 2f 2f 6c 6f 63 61 6c 68 6f 73 74 2f 6e 70 6f | ://localhost/npo 72 74 61 6c 2f 62 6d 73 5f 63 6f 72 70 2f 6c 6f | rtal/bms_corp/lo 67 69 6e 32 2e 6a 73 70 00 a0 0e 00 45 4d 6f 7a | gin2.jsp.?..EMoz 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 61 74 | illa/4.0 (compat 69 62 6c 65 3b 20 4d 53 49 45 20 36 2e 30 3b 20 | ible; MSIE 6.0; 57 69 6e 64 6f 77 73 20 4e 54 20 35 2e 31 3b 20 | Windows NT 5.1; 2e 4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 | .NET CLR 1.1.432 32 29 00 a0 09 00 2b 4a 53 45 53 53 49 4f 4e 49 | 2).?..+JSESSIONI 44 3d 41 43 32 36 43 30 43 32 45 36 39 37 32 33 | D=AC26C0C2E69723 38 38 33 34 30 42 31 33 45 38 45 31 39 35 35 37 | 88340B13E8E19557 34 37 00 a0 08 00 02 32 38 00 a0 07 00 21 61 70 | 47.?...28.?..!ap 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 77 77 77 2d | plication/x-www- 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 65 64 00 | form-urlencoded. a0 03 00 0d 67 7a 69 70 2c 20 64 65 66 6c 61 74 | ?...gzip, deflat 65 00 00 0d 63 61 63 68 65 2d 63 6f 6e 74 72 6f | e...cache-contro 6c 00 00 08 6e 6f 2d 63 61 63 68 65 00 00 07 6e | l...no-cache...n 6f 76 69 6e 65 74 00 00 04 76 31 2e 30 00 03 00 | ovinet...v1.0... 00 00 04 00 00 00 ff | ..? 21-jul-2005 13:12:32 org.apache.jk.common.ChannelSocket processConnection ADVERTENCIA: processCallbacks status 2 We're sure that the problem is with POST traffic, and if we use Tomcat directly, without using IIS, the form works, so it seems that the problem is on the connection between tomcat and IIS. And we know that the problem only appears on Windows XP. In the bug ID=30551, there was no solution to this problem, and we are not sure if the problem is caused by Windows XP, IIS or the JK connector. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee
DO NOT REPLY [Bug 35827] - Problem with POST forms with jk connector/IIS/WindowsXP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35827 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||30551 Component|Native:JK |Connector:AJP -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35827] - Problem with POST forms with jk connector/IIS/WindowsXP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35827 --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 14:27 --- It has been tested with 1.2.1, 1.2.6 and 1.2.8 versions of isapi_redirect.dll -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binary streaming / content-type problem with mod_jk ?
Thanks for your answer Henri :) I agree with you, finally I don't think the problem comes from mod_jk It may be Apache (using mod_jk and Tomcat) like described by Stuart Hynd in his post on this page : http://www.junlu.com/msg/107218.html Or, perhaps, QuickTime 6 which is more weaker than QT7 which doesn't care about the thing which makes the problem (and I would like to know where this thing comes from). But the incredible thing is that, using this : http://localhost:8080/my_test/BinaryStreamingit works perfectly on QT6 (without the 8080 port, the latence problem appears - QT6 or the servlet or Apache, is waiting for the video file entirely created before starting to play it)... Any other suggestions or opinions about this mystery ? :) Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com Le 20 juil. 05, à 23:24, Henri Gomez a écrit : not true, mod_jk didn't change the mime type provided by servlet output. I'm doing it on productions servers to handle on the fly generated PDFs 2005/7/20, Jérôme Chauvin [EMAIL PROTECTED]: Any ideas ? It would be helpful :) Thanks, Jérôme Chauvin Le 19 juil. 05, à 10:09, Jérôme Chauvin a écrit : Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binary streaming / content-type problem with mod_jk ?
Any ideas ? It would be helpful :) Thanks, Jérôme Chauvin Le 19 juil. 05, à 10:09, Jérôme Chauvin a écrit : Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com
Re: binary streaming / content-type problem with mod_jk ?
not true, mod_jk didn't change the mime type provided by servlet output. I'm doing it on productions servers to handle on the fly generated PDFs 2005/7/20, Jérôme Chauvin [EMAIL PROTECTED]: Any ideas ? It would be helpful :) Thanks, Jérôme Chauvin Le 19 juil. 05, à 10:09, Jérôme Chauvin a écrit : Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35791] New: - binary streaming / content-type problem with mod_jk ?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35791 Summary: binary streaming / content-type problem with mod_jk ? Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Keywords: APIBug, FAQ Severity: major Priority: P2 Component: Connector:AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
binary streaming / content-type problem with mod_jk ?
Hi all ! I've developed a servlet (BinaryStreaming based on StreamingContent by Raj Behera) which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... not important ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well (- MacOS and Windows) but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it, progressively. - like it does with QT7 and QT6 with :8080 OR when I use QT7 without :8080. I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) I really need to fix this ! :( Thanks in advance. :o) Regards, Jérôme --- Jérôme Chauvin OPSOMAI 77, rue de Charonne 75011 Paris - France Tél : +33 (0)1 58 39 38 22 Fax : +33 (0)1 43 70 70 72 @ : [EMAIL PROTECTED] URL : http://www.opsomai.com
Re: binary streaming / content-type problem with mod_jk
Hi all ! I've developed a servlet which does a binary stream of a mpeg video file which is created progressively (by another servlet/software/Unix command/... ) and finally read and played by Quicktime. I use Apache and Tomcat so I've installed mod_jk All work well but... : If I go on http://localhost:8080/my_test/BinaryStreaming it works well with QuickTime 7 and QuickTime 6 (6, 6.5, 6.5.2, ...). I have mod_jk so I can go on http://localhost/my_test/BinaryStreaming and here it still works well with QT7. But QT6 seems to wait that the video file is entirely created to start the viewing instead of starting to play the movie as soon as there is data in it. (- like it does with QT7 and QT6 with :8080 or without :8080 and when I use QT7). I think it's due to mod_jk but I've no idea to make it work I've found that another person had a similar problem, but no answer was given : http://www.junlu.com/msg/107218.html This message was posted in 09/2004 and it seems that Apache causes problems with pre-defined MIME-Types. Does someone have an answer or an idea ? :-) Thanks in advance. Regards, Jérôme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with request dispatcher
Hello,
i'm having a problem with calling a servlet
and dispatching to a jsp.
my example:
here is my simple html form:
html
body
form method=post action=test
Login input type=text name=login
Password input type=text name=password
input type=submit value=Envoyer
/form
/body
/html
Here's my processing servlet:
public class Test2 extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
System.err.println(test: doGet());
getServletContext().getRequestDispatcher(/index2.jsp).forward(request,
response);
return;
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException
{
System.err.println(test: doPost());
getServletContext().getRequestDispatcher(/index2.jsp).forward(request,
response);
return;
}
}
[/code
Here's index2.jsp code:
[code]
html
head
title/title
/head
body
test
/body
/html
The logs of the server Tomcat 5.5 on W2K and IE 6 with a single form submit:
test: doPost()
test: doGet()
When i remove doGet implementation from the servlet, there is only
test: doPost() log. So it's OK.
When the two methods are implemented, that doesn't work good.
When i remove getRequestDispatcher... line in the doPost() method, it works.
I don't understand.
it happens every time with this example.
Thanks for your help
Julien
Problem when a click a button that it execute a servlet n times
Hi, I have a problem with a button in my jsp page. When I click the button then it excutes a servlet. But if i click two or three or n times it executes a servlet n times. How can I do that this button execute only once independent of the number of times that you click the button. Thanks. - Correo Yahoo! Comprueba qué es nuevo, aquí http://correo.yahoo.es
There is a problem in 'SessionManager' implementation
Hi,
There is a problem in 'SessionManager' implementation regarding count of
expired sessions.
In 'org.apache.catalina.session.ManagerBase' class:
For each session, method 'ManagerBase.processExpires()' calls
''org.apache.catalina.session.StandardSession.isValid()' method and increments
number of expired session (in case that session isn`t valid)
...
if (!sessions[i].isValid()) {
expiredSessions++;
expireHere++;
}
.
But, 'StandardSession.isValid()' method triggers 'StandardSession.expire(true)'
method in cases when session should be invalidated. This method also increments
number of expired sessions ('SessionManager' attribute).
expire(boolean value)
...
int numExpired = manager.getExpiredSessions();
numExpired++;
manager.setExpiredSessions(numExpired);
At the end, as result of session invalidation process, number of expired
sessions is doubled.
Regards,
Radivoj Milin
DO NOT REPLY [Bug 35606] New: - Problem with Session cookies and multiple webapps on different ports or subdomains
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35606. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35606 Summary: Problem with Session cookies and multiple webapps on different ports or subdomains Product: Tomcat 5 Version: 5.0.27 Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When i run two instances of tomcat on different ports and access the first webapp, a session is created. when i access the second webapp, a new session is created. but this overwrites the session cookie of the first webapp. The same happens when i have a webapp on a domain (e.g. test.com) and a second webapp on a subdomain (other.test.com), but not in all cases (i think it depends on which domain i call first). The problem could be solved if the cookie name could be changed but this will violate the specs afaik. In Bug 16822 is a description how the problem could be solved otherwise: tomcat should use a session id supplied by the client when this is not already in use. in this case both applications would use the same session id (which should case no problems because they have different classloaders). Michael. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34474] - Problem with // in url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34474. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34474 --- Additional Comments From [EMAIL PROTECTED] 2005-07-04 16:25 --- fixing jk_uri_worker_map.c is wrong, mod_jk.c in jk_translate() is the place to fix the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34474] - Problem with // in url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34474. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34474 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25835] - Synchronization problem with RequestFilterValve
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25835. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25835 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-07-04 22:42 --- This has been fixed in CVS for 4.1.x and will be included in 4.1.32+ For the record, this was fixed in 5.5.x as part of the migration to java.util.regexp.* -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 12156] - Apache and Tomcat 3.3.1 Interworking problem
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 12156] - Apache and Tomcat 3.3.1 Interworking problem
Thank-you for your e-mail. Please note that i will be away from the office starting Wednesday June 29th, returning Thursday July 7th, with no access to email. In my absence, kindly contact Cheri Dueck at [EMAIL PROTECTED] Kind Regards, Natasha Hasmani Senior Event Manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12156] - Apache and Tomcat 3.3.1 Interworking problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=12156. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=12156 --- Additional Comments From [EMAIL PROTECTED] 2005-07-01 15:57 --- The today version is 3.3.2 please retry with 3.3.2 or any newer version. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35124] New: - catalina stop problem, uses kill approach
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35124.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35124
Summary: catalina stop problem, uses kill approach
Product: Tomcat 5
Version: 5.0.1
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
catalina.sh script uses 'kill' approach for stopping catalina. For killing it
finds tomcat pid using
tomcat_process=`netstat -anp | grep 8009 | awk '{print $NF}' | cut -d/ -f1`
kill -9 $tomcat_process
problem with this approach is that when any connection is in timewait state,
then the kill command will become 'kill -9 -' which actually kills the current
shell as well.
Other thing is that it uses 8009 port for finding pid of tomcat. Now this port
is subject to change by the user. So it might create problem.
Kill approach causes other commands not to be executed, after catalina.sh stop.
We uses in httpd service, so it creates problem in starting httpd service from
midway.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35124] - catalina stop problem, uses kill approach
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35124. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35124 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-05-31 02:14 --- The following command is used for the kill: kill -9 `cat $CATALINA_PID` Your linux distro must be repackaging and doing bad things. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29777] - HttpServletRequest#getParameterNames problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29777. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29777 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED OS/Version|Solaris |All Resolution||WONTFIX Version|4.1.30 |4.1.31 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 21:50 --- I have done some testing and I can repeat this on both Linux and Win32. The bug is in the parameter handling of the org.apache.ajp.tomcat4.Ajp13Connector connector, as you correctly point out. The fix is to use the newer org.apache.coyote.tomcat4.CoyoteConnector connector with the org.apache.jk.server.JkCoyoteHandler The connector documentation is not as clear about which connectors are deprecated and which are not and as a result I have re-written large chunks of the documentation as a result. I will update the website soon, but I need to filter out changes in the docs that relate to features implemented post 4.1.31 first. Since the connector with the bug is deprecated, this bug is WONTFIX. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK shutdown problem
Thanks for the reply Mladen.
I was wrong, this is not a lingering time problem, but instead related
to the value that is being used for MAX_SECS_TO_LINGER, which is 16.
I still have data waiting to be transferred from Tomcat after 16 receives.
Each call to jk_tcp_socket_recvfull() returns data, but it takes more than
16 loops to get a JK_SOCKET_EOF.
Apache is using 30 for MAX_SECS_TO_LINGER. Any objection why
mod_jk cannot use the same value?
Thanks,
--JJ
[EMAIL PROTECTED] 5/20/2005 12:21 PM
Jean-Jacques Clar wrote:
Hi,
file: jk_connect.c
in jk_shutdown_socket(); when reading data from tomcat in the while loop,
the variable ttl is incremented every time by one, until breaking out of the
loop:
snippet:
line 505 *-
/* Read all data from the peer until we reach end-of-file (FIN
* from peer) or we've exceeded our overall timeout. If the client does
* not send us bytes within12 second, close the connection.
*/
while (1) {
nbytes = jk_tcp_socket_recvfull(s, dummy, sizeof(dummy));
if (nbytes = 0)
break;
ttl += SECONDS_TO_LINGER;
if (ttl MAX_SECS_TO_LINGER)
break;
}
The problem is because I do not have a Netware box.
You guys can try to enable the following:
#if defined(WIN32)
setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,
(const char *) tmout, sizeof(int));
#endif
for Netware too...
I didn't try to enable that because so many times the
JK has been broken because of Netware build bugs ;)
Also the code in nb_connect:
#if defined(WIN32)
int tmout = timeout * 1000;
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
(const char *) tmout, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
(const char *) tmout, sizeof(int));
#else ...
Shuld be checked for: (probably but who knows ;)
for :
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JK shutdown problem
Hi,
file: jk_connect.c
in jk_shutdown_socket(); when reading data from tomcat in the while loop,
the variable ttl is incremented every time by one, until breaking out of the
loop:
snippet:
line 505 *-
/* Read all data from the peer until we reach end-of-file (FIN
* from peer) or we've exceeded our overall timeout. If the client does
* not send us bytes within12 second, close the connection.
*/
while (1) {
nbytes = jk_tcp_socket_recvfull(s, dummy, sizeof(dummy));
if (nbytes = 0)
break;
ttl += SECONDS_TO_LINGER;
if (ttl MAX_SECS_TO_LINGER)
break;
}
end *--
I don't see any linger time happening when calling recv(), in fact it returns
immediately,
therefore the while will loop 16 times maximum instead of 16 seconds. This is
causing
a problem on NetWare, where I have a socket still trying to send data for few
more loops.
It will then cause an IO exception in Java.
Removing the break based on the number of loop fixes my problem.
Is the problem present for all platforms or this is only because of our
implementation of winsock?
The same code in apache ap_lingering_close() does not seem to cause problems,
at least reported ones.
Thank you very much,
Jean-Jacques
Re: JK shutdown problem
Jean-Jacques Clar wrote:
Hi,
file: jk_connect.c
in jk_shutdown_socket(); when reading data from tomcat in the while loop,
the variable ttl is incremented every time by one, until breaking out of the loop:
snippet:
line 505 *-
/* Read all data from the peer until we reach end-of-file (FIN
* from peer) or we've exceeded our overall timeout. If the client does
* not send us bytes within12 second, close the connection.
*/
while (1) {
nbytes = jk_tcp_socket_recvfull(s, dummy, sizeof(dummy));
if (nbytes = 0)
break;
ttl += SECONDS_TO_LINGER;
if (ttl MAX_SECS_TO_LINGER)
break;
}
The problem is because I do not have a Netware box.
You guys can try to enable the following:
#if defined(WIN32)
setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,
(const char *) tmout, sizeof(int));
#endif
for Netware too...
I didn't try to enable that because so many times the
JK has been broken because of Netware build bugs ;)
Also the code in nb_connect:
#if defined(WIN32)
int tmout = timeout * 1000;
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
(const char *) tmout, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
(const char *) tmout, sizeof(int));
#else ...
Shuld be checked for: (probably but who knows ;)
for :
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem during authentication
I have just committed a fix for this. Mark Andrey Grebnev wrote: Hello, I suppose I found the problem with Tomcat. I have already write about it into tomcat-user mailting list but I did not get feedback. I have a problem under following environment: - Windows XP SP2 - JDK 1.4.2_04 - Tomcat 5.5.9 - Struts 1.2.4 I use characterEncodingFilter to setup UTF-8 encoding into request before using the content of the request. When I submit form with POST method it works well. I use FORM based authentication. However if I perform the following steps I have the problems with encoding: 1. Open JSP with HTML form which submit some UTF-8 string data using POST method. 2. Waiting when the HTTP session is invalidated (session timeout). 3. Submit the form. 4. Because session is invalidated I need to re-authenticate myself. 5. After success authentication The processing of the original request is continued. 6. The data of the form (from first step) is saved in incorrect encoding. I suppose that Valve (FormAuthenticator) which responsible for authentication is processed earlier then characterEncodingFilter and the parameters from POST request are parsed using DEFAULT_CHARACTER_ENCODING=ISO-8859-1 when the original request information is saved into session. I have tried to specify enctype=application/x-www-form-urlencoded; charset=utf-8 attribute for my FORM tag. But e.g. Mozilla browser specify only Content-Type: application/x-www-form-urlencoded header and cut out specified charset. Any ideas? -- Best regards. Andrey Grebnev ! - 30% 1:00 9:00. 600- - 1.75, - 1.89, - 1.96, 5- - 2,03, - 2,10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34835] New: - strange problem--In two different time , it is showing different figure from static database
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34835. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34835 Summary: strange problem--In two different time , it is showing different figure from static database Product: Tomcat 5 Version: 5.0.9 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We are running JSP based program from it. In 1 minutes difference it is showing different figure whereas this figure is shown from the past stored data -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34835] - strange problem--In two different time , it is showing different figure from static database
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34835. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34835 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 19:51 --- Try the tomcat-user list. If you want a useful response you are going to have to provide a lot more informatino than this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Encoding problem during authentication
Hello, I suppose I found the problem with Tomcat. I have already write about it into tomcat-user mailting list but I did not get feedback. I have a problem under following environment: - Windows XP SP2 - JDK 1.4.2_04 - Tomcat 5.5.9 - Struts 1.2.4 I use characterEncodingFilter to setup UTF-8 encoding into request before using the content of the request. When I submit form with POST method it works well. I use FORM based authentication. However if I perform the following steps I have the problems with encoding: 1. Open JSP with HTML form which submit some UTF-8 string data using POST method. 2. Waiting when the HTTP session is invalidated (session timeout). 3. Submit the form. 4. Because session is invalidated I need to re-authenticate myself. 5. After success authentication The processing of the original request is continued. 6. The data of the form (from first step) is saved in incorrect encoding. I suppose that Valve (FormAuthenticator) which responsible for authentication is processed earlier then characterEncodingFilter and the parameters from POST request are parsed using DEFAULT_CHARACTER_ENCODING=ISO-8859-1 when the original request information is saved into session. I have tried to specify enctype=application/x-www-form-urlencoded; charset=utf-8 attribute for my FORM tag. But e.g. Mozilla browser specify only Content-Type: application/x-www-form-urlencoded header and cut out specified charset. Any ideas? -- Best regards. Andrey Grebnev ! - 30% 1:00 9:00. 600- - 1.75, - 1.89, - 1.96, 5- - 2,03, - 2,10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Encoding problem during authentication
??? Andrey Grebnev [EMAIL PROTECTED] wrote:Hello, I suppose I found the problem with Tomcat. I have already write about it into tomcat-user mailting list but I did not get feedback. I have a problem under following environment: - Windows XP SP2 - JDK 1.4.2_04 - Tomcat 5.5.9 - Struts 1.2.4 I use characterEncodingFilter to setup UTF-8 encoding into request before using the content of the request. When I submit form with POST method it works well. I use FORM based authentication. However if I perform the following steps I have the problems with encoding: 1. Open JSP with HTML form which submit some UTF-8 string data using POST method. 2. Waiting when the HTTP session is invalidated (session timeout). 3. Submit the form. 4. Because session is invalidated I need to re-authenticate myself. 5. After success authentication The processing of the original request is continued. 6. The data of the form (from first step) is saved in incorrect encoding. I suppose that Valve (FormAuthenticator) which responsible for authentication is processed earlier then characterEncodingFilter and the parameters from POST request are parsed using DEFAULT_CHARACTER_ENCODING=ISO-8859-1 when the original request information is saved into session. I have tried to specify enctype=application/x-www-form-urlencoded; charset=utf-8 attribute for my FORM tag. But e.g. Mozilla browser specify only Content-Type: application/x-www-form-urlencoded header and cut out specified charset. Any ideas? -- Best regards. Andrey Grebnev ! - 30% 1:00 9:00. 600- - 1.75, - 1.89, - 1.96, 5- - 2,03, - 2,10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ! \\\|/// \\ - - // ( @ @ ) oOOo- (_)-oOOo :gzlongzhijian QQ(OICQ) 40831127 Q :[EMAIL PROTECTED] :http://www.gzlzj.com 401 :510630 :020-33629058 Oooo oooO ( ) ( ) ) / \ ( (_/ \_) - Do You Yahoo!? 150MP3 1G1000
Re: Encoding problem during authentication
I have confirmed this behaviour. Your suggestion as to the root cause looks possible. I will investigate further. Mark Andrey Grebnev wrote: Hello, I suppose I found the problem with Tomcat. I have already write about it into tomcat-user mailting list but I did not get feedback. I have a problem under following environment: - Windows XP SP2 - JDK 1.4.2_04 - Tomcat 5.5.9 - Struts 1.2.4 I use characterEncodingFilter to setup UTF-8 encoding into request before using the content of the request. When I submit form with POST method it works well. I use FORM based authentication. However if I perform the following steps I have the problems with encoding: 1. Open JSP with HTML form which submit some UTF-8 string data using POST method. 2. Waiting when the HTTP session is invalidated (session timeout). 3. Submit the form. 4. Because session is invalidated I need to re-authenticate myself. 5. After success authentication The processing of the original request is continued. 6. The data of the form (from first step) is saved in incorrect encoding. I suppose that Valve (FormAuthenticator) which responsible for authentication is processed earlier then characterEncodingFilter and the parameters from POST request are parsed using DEFAULT_CHARACTER_ENCODING=ISO-8859-1 when the original request information is saved into session. I have tried to specify enctype=application/x-www-form-urlencoded; charset=utf-8 attribute for my FORM tag. But e.g. Mozilla browser specify only Content-Type: application/x-www-form-urlencoded header and cut out specified charset. Any ideas? -- Best regards. Andrey Grebnev ! - 30% 1:00 9:00. 600- - 1.75, - 1.89, - 1.96, 5- - 2,03, - 2,10 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Mladen, Mladen Turk schrieb: Peter Rossbach wrote: Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Are you sure this is absolute necessity? YES! We monitor the cluster and when one member is not accessiable or throw Out of memory Exception, the node was automaticly restart. Also this mode is fine for minor node or application configuration update. It is not usefull for complete new deployment, when serialized classes changed :-) I agree something like that might be usable on a development server, but on a production server? I'm not sure if your users will be happy with loosing sessions in a middle of a transaction or order. Hmm, but the fallback server (same cluster domain) has the sessions at this moment and the user see nothing from the switch. This suggestion is the result of my last two week pre production tests and customer discussions. Again, disable works as expected. It will preserve exiting sessions until session times out. When all existing sessions are gone, then you can do with that node what ever you wish. If you do not wish to wait, then simply disable and kill that instance. The existing sessions will be failovered to another node with loosing session data. But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? I see no reason whatsoever for introducing another 'immediate disable' flag to the worker. I hope my description help do understand my suggestion better. Regards, Mladeb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Mladen, I have made successfull a test implementation to deactived a worker. I works very fine for me at windows. Now made a second test under apache 2.0.54 and Linux 9.3 with worker and prefork MPM. I think in two hour I am ready to checkin the change. :-) Peter Peter Rossbach schrieb: Hey Mladen, Mladen Turk schrieb: Peter Rossbach wrote: Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Are you sure this is absolute necessity? YES! We monitor the cluster and when one member is not accessiable or throw Out of memory Exception, the node was automaticly restart. Also this mode is fine for minor node or application configuration update. It is not usefull for complete new deployment, when serialized classes changed :-) I agree something like that might be usable on a development server, but on a production server? I'm not sure if your users will be happy with loosing sessions in a middle of a transaction or order. Hmm, but the fallback server (same cluster domain) has the sessions at this moment and the user see nothing from the switch. This suggestion is the result of my last two week pre production tests and customer discussions. Again, disable works as expected. It will preserve exiting sessions until session times out. When all existing sessions are gone, then you can do with that node what ever you wish. If you do not wish to wait, then simply disable and kill that instance. The existing sessions will be failovered to another node with loosing session data. But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? I see no reason whatsoever for introducing another 'immediate disable' flag to the worker. I hope my description help do understand my suggestion better. Regards, Mladeb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Peter Rossbach wrote: Are you sure this is absolute necessity? But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? Well I'm -0 on the subject, because I think it's useless. You can of course commit what you think is appropriate, of course if that will not break the existing functionality. I think that the desired functionality can be achieved with status worker that will put the worker in error and disabled state at once, but of course you can add a new flag for that. IMO adding that 'active' flag to the workers.properties will only rise the fuzziness regarding to the 'disabled' flag. Once more, all the features you are searching for, can be achieved using the current configuration. Simply use the JMX and pause your node. But if you think that is realy needed then rename the 'disable' to be the function of your proposed 'active' and add a new flag 'standby' or 'pause' that will act as current negation of the disabled flag. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Mladen Turk schrieb: Peter Rossbach wrote: Are you sure this is absolute necessity? But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? Well I'm -0 on the subject, because I think it's useless. You can of course commit what you think is appropriate, of course if that will not break the existing functionality. Yes, I am on testing this. I hope you can help two test it also. Many thanks! I think that the desired functionality can be achieved with status worker that will put the worker in error and disabled state at once, but of course you can add a new flag for that. OK, I have add a deactived flag. IMO adding that 'active' flag to the workers.properties will only rise the fuzziness regarding to the 'disabled' flag. Once more, all the features you are searching for, can be achieved using the current configuration. Simply use the JMX and pause your node. Hmm, but curently the connection are keepalive. I see that only new connection drop, but the active connection are still alive. At my test the request don't stop. But if you think that is realy needed then rename the 'disable' to be the function of your proposed 'active' and add a new flag 'standby' or 'pause' that will act as current negation of the disabled flag. I name the flag deactived. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Peter Rossbach wrote: I name the flag deactived. Look, can we prolong that to the next release? I would really appreciate that, because the 1.2.11 should be a bug-fix release. Changing that would break the current configurations, and IMO we could think of something smarter in the future. Adding an extra checkbox to the status worker for putting the worker in error and disabled state at once, should do a trick I think. Any other directives should be carefully selected thought. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Malden, Mladen Turk schrieb: Peter Rossbach wrote: I name the flag deactived. Look, can we prolong that to the next release? I would really appreciate that, because the 1.2.11 should be a bug-fix release. Changing that would break the current configurations, and IMO we could think of something smarter in the future. The change not break the configuration, it extend the configuration. I also see that this flag make the configruation much more compilcate and that was really bad. But I can send you my changes before commit and you can have the descision it include inside 1.2.11 or not. Adding an extra checkbox to the status worker for putting the worker in error and disabled state at once, should do a trick I think. Any other directives should be carefully selected thought. Yes, I have also made the flag configurable, but I find it a little bit strange to set the error flag. But this was my first idea. Please review my changes. Better ideas welcome :-) Currently I have test all worker modes at windows, but now I have a compilation problem at suse 9.3 the compile can't jk_connect.c jk_connect.c: In function 'jk_shutdown_socket' : jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function) jk_connect.c:484: error (Each unde ... How can I find the missing declaration of SD_SEND? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Thanks, stopped is a very good name! Peter Georg v. Zezschwitz schrieb: On Tue, Apr 26, 2005 at 01:10:13PM +0200, Peter Rossbach wrote: I name the flag deactived. Sorry for a lurkers comment from the background (and I am neither a native speaker). But I guess it should be named: deactivated not deactived Also, based on Mladens points, what about a more strict name, like: stopped? Kind regards, Georg v.Zezschwitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk problem with domain clustering and restart node or application
One of my problems with clustering are: Szenario: - three domains of cluster with two or three tomcat nodes - have more then one application at this cluster - all nodes server the same application set - sticky session on Goal - restart an application at single node Probleme - How can configure that lb stop traffic for a spezial worker/node and for an single application? my idea: config via uriworkermap.properties -/myapps/*=node1 or -/myapps/*=loadbalancer.node1 /myapps/*=loadbalancer - Disable worker stop only the traffic for new session requests, but not for all requests. new worker config worker.node1.active=false ( The semantic of disable is a little bit strange for Sticky Session mode) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Peter Rossbach wrote: Goal - restart an application at single node Wow. Probleme - How can configure that lb stop traffic for a spezial worker/node and for an single application? I think that this is the Tomcat responsibility. If inside redeployment, it should hold the request until finished. For mod_jk you can set the socket_timeout that will cause the failover to another worker (if redeployment takes more then 60 seconds). Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Mladen Turk wrote: I think that this is the Tomcat responsibility. If inside redeployment, it should hold the request until finished. For mod_jk you can set the socket_timeout that will cause the failover to another worker (if redeployment takes more then 60 seconds). There is no way to hold a particular request. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hello Mladen , yes Remy, we have currently no chance inside tomcat. :-( My szenario is really important when automatic alive monitoring detect that inside an application or node is something wrong (Out Of Memory Exception, all thread hang, detect a deadlock or other nice application relevant bugs/feature) What I want is, that we can stop request sending from mod_jk side at a single node. Why we can't stop all requests for a worker, when we set a flag worker.node1.active=false ? Ok, then no application on this node get request, but we can control the tomcat restart. Peter Remy Maucherat schrieb: Mladen Turk wrote: I think that this is the Tomcat responsibility. If inside redeployment, it should hold the request until finished. For mod_jk you can set the socket_timeout that will cause the failover to another worker (if redeployment takes more then 60 seconds). There is no way to hold a particular request. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Peter Rossbach wrote: Hello Mladen , What I want is, that we can stop request sending from mod_jk side at a single node. Why we can't stop all requests for a worker, when we set a flag worker.node1.active=false ? Ok, then no application on this node get request, but we can control the tomcat restart. You have woker.node1.disabled=True directive. It will disable the worker in case it's member of load balancer, and no furher requests will took place on it unless referenced by some other worker with 'redirect' and not in error state. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hmm, that disabling feature not work at my configuration. I have made a test with current Tomcat head and mod_jk 1.2.10. === worker.list=lb,status worker.node1.port=9012 worker.node1.host=127.0.0.1 worker.node1.type=ajp13 worker.node1.cachesize=200 worker.node1.cache_timeout=60 worker.node1.disabled=false worker.node1.domain=A worker.node2.port=9022 worker.node2.host=127.0.0.1 worker.node2.type=ajp13 worker.node2.cachesize=200 worker.node2.cache_timeout=60 worker.node2.disabled=false worker.node2.domain=A worker.lb.balance_workers=node1,node2 worker.lb.type=lb worker.status.type=status === Setup to tomcat behind Apache 2.0.53 ( Windows XP) When I open browser send a request that open a session. Verify that next request goes to the same tomcat. disable tomcat/worker from which node request coming. Request again the same request and see that request goes to the same worker. Next test with remove the domain feature, and also test it with a fresh compile cvs head, but also it not working. What is wrong at my mod_jk configuration? Peter Mladen Turk schrieb: Peter Rossbach wrote: Hello Mladen , What I want is, that we can stop request sending from mod_jk side at a single node. Why we can't stop all requests for a worker, when we set a flag worker.node1.active=false ? Ok, then no application on this node get request, but we can control the tomcat restart. You have woker.node1.disabled=True directive. It will disable the worker in case it's member of load balancer, and no furher requests will took place on it unless referenced by some other worker with 'redirect' and not in error state. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Peter Rossbach wrote: Hmm, that disabling feature not work at my configuration. worker.node2.domain=A You don't need a domain unless you have a session replication What is wrong at my mod_jk configuration? worker.xxx.sticky_session=false All sticky sessions will need to timeout, and then you can restart your tomcat, not before. All new sessions will never go to the disabled host, but the existing one will be preserved because of sticky_session set to on by default. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Mladen Turk wrote: Peter Rossbach wrote: Hmm, that disabling feature not work at my configuration. worker.node2.domain=A You don't need a domain unless you have a session replication Or you can just set jvmRoute=A on each tomcat instance, make session replication, and then your config will work instantly when you disable one of the workers. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Peter Mladen Turk schrieb: Mladen Turk wrote: Peter Rossbach wrote: Hmm, that disabling feature not work at my configuration. worker.node2.domain=A You don't need a domain unless you have a session replication Or you can just set jvmRoute=A on each tomcat instance, make session replication, and then your config will work instantly when you disable one of the workers. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Peter Rossbach wrote: Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Are you sure this is absolute necessity? I agree something like that might be usable on a development server, but on a production server? I'm not sure if your users will be happy with loosing sessions in a middle of a transaction or order. Again, disable works as expected. It will preserve exiting sessions until session times out. When all existing sessions are gone, then you can do with that node what ever you wish. If you do not wish to wait, then simply disable and kill that instance. The existing sessions will be failovered to another node with loosing session data. I see no reason whatsoever for introducing another 'immediate disable' flag to the worker. Regards, Mladeb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34481] New: - mod_jk 1.2.10 status worker quick refresh problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34481. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34481 Summary: mod_jk 1.2.10 status worker quick refresh problem Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm testing the load balancing worker. My setup is: 2 hosts running Debian Linux (Sarge), Debian stock install of apache2. Apache2 using prefork workers. I've got two such Linux boxes, my workers.properties is: --- worker.list=lb,status worker.status.type=status worker.node1.port=10900 worker.node1.host=rhubarb worker.node1.type=ajp13 worker.node1.disabled=true worker.node2.port=10900 worker.node2.host=blueberry worker.node2.type=ajp13 worker.lb.balance_workers=node1,node2 worker.lb.type=lb worker.lb.sticky_session=true --- My VirtualHost directive is: --- VirtualHost * ServerName martin.rhubarb.salad.taglab.com ServerAlias martin.rhubarb JKMount /* lb JKMount /status status /VirtualHost -- I start doing some requests to http://martin.rhubarb/test.jsp; and it works fine, the test jsp prints out the session id and some trace output in the log. All requests keep going to the same host. All is fine. --- I look at the http://martin.rhubarb/status page and I can see: node1 ajp13 rhubarb:10900 192.168.100.85:10900Disabled1 1 0 0 0 0 0 node2 ajp13 blueberry:10900 192.168.100.86:10900OK 1 1 15 0 7.1K2.0K0 --- If I refresh the /status page too quickly (click reload before the previous page has loaded), the status can often get reset: --- node1 ajp13 rhubarb:10900 192.168.100.85:10900Disabled1 1 0 00 0 0 node2 ajp13 blueberry:10900 192.168.100.86:10900OK 1 1 0 0 0 0 0 --- Not only that, but sometimes it starts showing the Disabled and OK states completely erratic reporting Disabled or OK on the wrong one. This looks like a thread issue in the status worker since as far as I can tell the actual lb worker continues to work fine. Details of how I installed mod_jk.so: I downloaded the source for the connectors 1.2.10. Compiled and installed it like. $ cd jk/native $ ./configure --with-apxs=/usr/bin/apxs2 $ make $ cp apache-2.0/mod_jk.so /usr/lib/apache2/modules/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34481] - mod_jk 1.2.10 status worker quick refresh problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34481. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34481 --- Additional Comments From [EMAIL PROTECTED] 2005-04-16 10:34 --- Give the --prefork-enabled flag a chance to disable all threading code. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34481] - mod_jk 1.2.10 status worker quick refresh problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34481. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34481 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-04-16 10:49 --- The --enable-prefork did not fix it, however I know noticed in the apache error log: [Sat Apr 16 09:44:39 2005] [emerg] No JkShmFile defined in httpd.conf. LoadBalancer will not function properly! Configuring a global JkShmFile makes it start behave properly. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34474] New: - Problem with // in url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34474.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34474
Summary: Problem with // in url
Product: Tomcat 5
Version: 5.0.28
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
I had a webapp running on a tomcat 5.0.28 and visible through the ajp/1.3
connector via apache
This webapp generates urls to itself with // in them. When it is configured to
access the tomcat via the http connector it works correctly, but when it is
configured to operate via the ajp connector, the url is not reached.
I've noticed that this webapps works correctly on mod_jk 1.2.5.
I've had this problem on mod_jk 1.2.10
Having spent all the day to debug this problem, I think I've figured where it
hides.
The code in mod_jk.c uses ap_no2slash(clean_uri) to remove double slashes in
jk_translate(). I think this happens registering workers base url to be fetched
later at the time to forward the uris.
Adding an ap_no2slash() in /jk/native/common/jk_uri_worker_map.c seems to fix
the problem. I don't know if this is right, because I've got almost no knowledge
of jk or apache internals. But now it seems to be working. Here is a patch:
--- jk_uri_worker_map.c.old 2005-04-15 14:49:10.0 +
+++ jk_uri_worker_map.c 2005-04-15 11:05:23.0 +
@@ -454,6 +454,10 @@
if (JK_IS_DEBUG_LEVEL(l))
jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s' from %d maps,
uri, uw_map-size);
+ap_no2slash(uri);
+if (JK_IS_DEBUG_LEVEL(l))
+jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s' from %d maps,
+ uri, uw_map-size);
for (i = 0; i uw_map-size; i++) {
uri_worker_record_t *uwr = uw_map-maps[i];
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34475] New: - Problem with // in url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34475.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34475
Summary: Problem with // in url
Product: Tomcat 5
Version: 5.0.28
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
I had a webapp running on a tomcat 5.0.28 and visible through the ajp/1.3
connector via apache
This webapp generates urls to itself with // in them. When it is configured to
access the tomcat via the http connector it works correctly, but when it is
configured to operate via the ajp connector, the url is not reached.
I've noticed that this webapps works correctly on mod_jk 1.2.5.
I've had this problem on mod_jk 1.2.10
Having spent all the day to debug this problem, I think I've figured where it
hides.
The code in mod_jk.c uses ap_no2slash(clean_uri) to remove double slashes in
jk_translate(). I think this happens registering workers base url to be fetched
later at the time to forward the uris.
Adding an ap_no2slash() in /jk/native/common/jk_uri_worker_map.c seems to fix
the problem. I don't know if this is right, because I've got almost no knowledge
of jk or apache internals. But now it seems to be working. Here is a patch:
--- jk_uri_worker_map.c.old 2005-04-15 14:49:10.0 +
+++ jk_uri_worker_map.c 2005-04-15 11:05:23.0 +
@@ -454,6 +454,10 @@
if (JK_IS_DEBUG_LEVEL(l))
jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s' from %d maps,
uri, uw_map-size);
+ap_no2slash(uri);
+if (JK_IS_DEBUG_LEVEL(l))
+jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s' from %d maps,
+ uri, uw_map-size);
for (i = 0; i uw_map-size; i++) {
uri_worker_record_t *uwr = uw_map-maps[i];
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34475] - Problem with // in url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34475. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34475 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-04-15 17:06 --- *** This bug has been marked as a duplicate of 34474 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34474] - Problem with // in url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34474. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34474 --- Additional Comments From [EMAIL PROTECTED] 2005-04-15 17:06 --- *** Bug 34475 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
log4j problem in 5.5.9
Hello, I have a plug-in which configures log4j on per context basis from external property file. As result each of my contexts log to its own file and is configured from property file stored outside of its WAR file. The system allows log4j.jar and commons-logging.jar in server/lib or commons/lib as long as both jars are present in WEB-INF/lib as well. It was made to allow classes loaded by server loader (Realms, Valves ...) to logg to context logger as well. It is done as axtention of WebAppLoader class It all worked well till version 5.5.9 where I am getting a nasty error log4j:ERROR Could not instantiate appender named applog. log4j:ERROR A org.apache.log4j.RollingFileAppender object is not assignable to a org.apache.log4j.Appender variable. log4j:ERROR The class org.apache.log4j.Appender was loaded by log4j:ERROR [WebappClassLoader delegate: false repositories: /WEB-INF/classes/ -- Parent Classloader: [EMAIL PROTECTED] ] whereas object of type log4j:ERROR org.apache.log4j.RollingFileAppender was loaded by [EMAIL PROTECTED] ]. I can not figure out why RollingFileAppender of all the classes is not loaded by WebappClassLoader but by StandardClassLoader instead I am very careful to not to reference any log4j classes in my WebAppLoader extention class - all configuration is done via reflection and all classes are loaded from WebappClassLoader but when log4j configurator applies property file it fails with this error Everything works of course with no log4j files in server/lib common/lib but I would like to use log4j for server logging as well I would greatly appreciate your help Thank you Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j problem in 5.5.9
Roytman, Alex wrote: It is done as axtention of WebAppLoader class It all worked well till version 5.5.9 where I am getting a nasty error How about axing your axtension ? Stating that It all worked well till version 5.5.9 unfortunately does not make sense looking at the changelog. Everything works of course with no log4j files in server/lib common/lib but I would like to use log4j for server logging as well Since you know what you are doing, you should identify where: - Tomcat context classloader would be incorrectly set - The logger from this context (the container logger) would be accessed while the said classloader is not correctly set Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with mod_jk 1.2.8 (and 1.2.10) and Tomcat 4.0.4
Hello, I have a problem of ping pong between the connector mod_jk and tomcat 4.0.4 which entraine a significant load network. Sequence 1234 APACHE MOD_JK to TOMCAT Response AB (TOMCAT to APACHE MOD_JK) http://jakarta.apache.org/tomcat/connectors-doc-archive/jk2/common/AJPv13.html I manage to reproduce the problem in the following way: I have an application which allows me to send a file (I a file of 5 Mo takes for example) and I the transfer stops while close my navigator at this time there sequence AB/1234 never stops (infinite). Useless to say to you that if 20 or 30 users make celà, one arrives at a load very significant network. tcpdump on localhost showed me that there is continues traffic between both the httpd/mod_jk and the tomcat server (ajpv13). The traffic is always the same. A request from the container (AB - in ajpv13 this means Get Body Chunk) and a reply from the server (1234|00|00 - this is an 'empty packet' telling there is nothing more to be sent). I found only one mail in this direction in mailing list archive. And no response to this problem. Can you help me? http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg118112.html Best Regards, Laurent LE PRIEUR Rectorat de Nancy Metz Education Nationale - FRANCE
Re: Problem with mod_jk 1.2.8 (and 1.2.10) and Tomcat 4.0.4
Laurent LE PRIEUR wrote: Hello, I have a problem of ping pong between the connector mod_jk and tomcat 4.0.4 which entraine a significant load network. Did you tried your app with Tomcat5 or Tomcat5.5? Perhaps the problem is not with the native side of mod_jk. You can post your application if unable to install the Tomcat5. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with mod_jk 1.2.8 (and 1.2.10) and Tomcat 4.0.4
From: Mladen Turk [EMAIL PROTECTED] Laurent LE PRIEUR wrote: Hello, I have a problem of ping pong between the connector mod_jk and tomcat 4.0.4 which entraine a significant load network. Did you tried your app with Tomcat5 or Tomcat5.5? Perhaps the problem is not with the native side of mod_jk. This sounds similar to a problem that is fixed in 3.3.2, 4.1.31 and 5.x. http://marc.theaimsgroup.com/?l=tomcat-devm=107846357610458w=2 You can post your application if unable to install the Tomcat5. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jndi lookup problem
First, I apologize if this should go to the user list, but I've had no success over there and I'm desperately seeking an answer to what I think is a simple question. We have a servlet configured under tomcat that needs to call a method on a session bean running on a separate application server, in this case, jboss. When the code runs, we get an error message stating that Name ejb is not bound in this context. What I think is happening is that, instead of communicating with the jndi server on jboss, we are communicating with the jndi server in tomcat. In fact, jboss isn't even running and we get this. I've printed out the Context environment just before the lookup and the java.naming.provider.url is set correctly to point at jboss. I've looked throughout the documentation and can't find anything addressing this specific issue. We have gotten this to work in the past in version 3.x, we are now trying with 5.0.28 and having this problem. Any thoughts or pointers would be helpful. Regards Eric J. Kaplan Armanta, Inc. 350 Mt. Kemble Ave. Morristown, NJ 07960
Nested tag problem in tomcat 5.0.29
Hi all, I am having problem compiling jsp pages with nested struts tags. Is this a known error ? It says Unable to compile class for JSP Generated servlet error: %CATALINA_HOME%\work\Catalina\localhost\test\org\apache\jsp\ui\Showjsp .java:124: _jspx_meth_logic_equal_0(javax.servlet.jsp.tagext.JspTag,javax.servlet .jsp.PageContext) in org.apache.jsp.ui.ShowPricingConditionPanel_jsp cannot be applied to (org.apache.struts.taglib.html.FormTag,javax.servlet.jsp.PageContext) if (_jspx_meth_logic_equal_0(_jspx_th_html_form_0, _jspx_page_context)) Has anybody got this error. Kindly advise. Thanks and Regards, Satya
Re: Nested tag problem in tomcat 5.0.29
Please DO NOT cross post. The mailing list guidelines are very clear on this issue (http://jakarta.apache.org/site/mail.html) Mark Narayan, Satya wrote: Hi all, I am having problem compiling jsp pages with nested struts tags. Is this a known error ? It says Unable to compile class for JSP Generated servlet error: %CATALINA_HOME%\work\Catalina\localhost\test\org\apache\jsp\ui\Showjsp .java:124: _jspx_meth_logic_equal_0(javax.servlet.jsp.tagext.JspTag,javax.servlet .jsp.PageContext) in org.apache.jsp.ui.ShowPricingConditionPanel_jsp cannot be applied to (org.apache.struts.taglib.html.FormTag,javax.servlet.jsp.PageContext) if (_jspx_meth_logic_equal_0(_jspx_th_html_form_0, _jspx_page_context)) Has anybody got this error. Kindly advise. Thanks and Regards, Satya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12682] - Problem when recompiling servlets with JDBC connections with Oracle 9i
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=12682. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=12682 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED OS/Version||All Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-20 19:28 --- On reviewing this bug: - there is insufficient information to reproduce it - the change that caused the bug was a move from NT to 2000 Based mainly on the OS change causing the issue I am going to assume that this is not a Tomcat issue. Please feel free to re-open if you have evidence to support the position that this is not the case. Note that issues like this should first be discussed on the tomcat-user mailing list. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33932. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33932 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 14:11 --- BeanUtilsBean is not part of the Tomcat project (maybe it's commons-beanutils ?). Also, the associations in commons-logging with the webapp classloader are cleared when stopping the web application. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33932. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33932 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 14:44 --- I think I did not make myself very clear. I saw several classes from server/libs (BeanUtilsBean was one of them) that maintained references to Logger instances loaded by web app class loader, through the log static field. From my point of view, as long as common-beanutils and common-logging exist in server/lib, they are part of Tomcat web server. For the Tomcat user's point of view, bugs in the versions of these libs delivered with Tomcat are also bugs of Tomcat. I understand the tomcat developer's point of view, but you must also understand the user's point of view. Looking closer, I think the problem might be in common-logging, in LogFactoryImpl, that user the context class loader to load the logger instance. If a class from server/lib, loaded by Tomcat's class loader is first accessed from a web application, its logger will be loaded by the web application's class loader, and this class will always maintain this strong reference to the logger, no matter what cleanup you do in commons-logging when I stop the application. If this is the case, it is indeed a bug in commons-logging, but as far as I am concerned, it's also a bug is tomcat, as it is delivered with commons-logging as a part of it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33932. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33932 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 14:48 --- I was not interested in any additional feedback. I recommend you check your facts better before creating bug reports. Please do not reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33932] - Problem with common logging - uses wrong logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33932. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33932 --- Additional Comments From [EMAIL PROTECTED] 2005-03-15 19:48 --- There are changes in commons-logging 1.0.5 to address this type of memory leaks in container deployment. You might want to try with that version. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
X509 Certificate Public Key Problem in Displaying - HELP
Hi all ! I am facing problem in displaying Public Key. When I am pasring X509 certificate the Public Key is coming as a very long String as as given in Format 1 below, though it should come like as given in Format 2 below. out.println(x509certificate.getPublicKey()); I am using Bouncy Castle API and after that only the Public Key is coming like a long String. Please advice. I tried to convert the Public key into byte array then to String, but it is showing junk charaters. The encoding for Publick key is ASN.1 DER but its is giving error. I need your advice .. Please HELP...! byte buf [] = x509certificate.getPublicKey().getEncoded(); String s = new String(buf, UTF-8); s= new String(s.getBytes(ISO8859_1), UTF-8); out.println(s); Format 1 RSA Public Key modulus: cd288334541b89f30faf379131ffaf3160c9a8e8b21068ed9fe79336f10a64bb47f504173f23474dc5271981260c54720d882dd91f9a129fbcb371d380193f47667b8c3528d2b90adf24da9cd65079817a5ad337f7c24ad829922664d1e4986c3a008af5349b65f8ede310fffdb84958dca0de82396b81b1161961b954b6e643 public exponent: 3 Format 2 SunJSSE RSA public key: public exponent: 010001 modulus: c90a4f87 1cb7a888 b668a7a2 3b6ceb7b 6c1f2ad8 d548a4d3 34b5cdce 32535ed3 d122116a d8afc534 082b8877 fdc6f728 66d0b743 935f868a 80be4a94 e4d953ca 69bbf480 ff0ba33b bb7f88a4 05403841 7d74b823 3499f387 76e8a8ad a7fd0d91 07cda676 23df07ca d8afaa75 cfc245e7 10bb201d f6308f10 52b5fb79 66ab41f9 Thanks xue daoming for conversion but its not working , I tried searching the charset and encoding but no solution till now Best Regards, Sanjeev --- xue daoming [EMAIL PROTECTED] wrote: I think you can do as just below: byte[] buf = x509certificate.getPublicKey().getEncoded(); String s = new String(buf); On Thu, 10 Mar 2005 02:35:03 + (GMT), Sanjeev Srivastava [EMAIL PROTECTED] wrote: Hi All Can anybody tell me how to convert this Byte [] to String.. byte[] buf = x509certificate.getPublicKey().getEncoded(); Please help Thanks, Sanjeev Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33932] New: - Problem with common logging - uses wrong logger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33932. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33932 Summary: Problem with common logging - uses wrong logger Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I've deployed an application that uses common-logging with log4j to log. common-logging and log4j jars are located in WEB-INF/lib. With a profiler, I spotted some classes that are used internally by tomcat (BeanUtilsBean, for example) that use the log4j logger loaded by my application. This is very unusual, and causes memory leaks by maintaining strong ref to the web app class loader. I assume the problem is somewhere in common-logging, because of a context class loared, but I dod not have time to investigate. The workaround I've found was to put common-logging and log4j jars in share/libs. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29777] - HttpServletRequest#getParameterNames problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29777. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29777 --- Additional Comments From [EMAIL PROTECTED] 2005-03-07 20:33 --- If you have a new issue, please open a new bug report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29777] - HttpServletRequest#getParameterNames problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29777. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29777 --- Additional Comments From [EMAIL PROTECTED] 2005-03-06 22:08 --- Created an attachment (id=14418) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14418action=view) I had exact same code and same problem. But I got around by using for loop as displayed -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29777] - HttpServletRequest#getParameterNames problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29777. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29777 --- Additional Comments From [EMAIL PROTECTED] 2005-03-06 22:14 --- Created an attachment (id=14419) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14419action=view) But meanwhile I have same problem with loop of enumeration.hasMoreElements() from request.getAllAttributes() and I can see that enumeration.hasMoreElements() still true when there is no more. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33790] New: - Encoding problem D5 to 3F
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33790.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33790
Summary: Encoding problem D5 to 3F
Product: Tomcat 5
Version: Unknown
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
My servlets return 3F (in HEX) instead of D5
Example of code:
out.print(new String(new byte[]{(byte)0xD5}));
Result must be, D5, I suppose, but it is 3F
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
