DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456 logs/context lost when restarting Context --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 08:23 --- Created an attachment (id=7323) without a compile bug on sessionState.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Regarding struts file upload
Dear Sir, With reference to the file uploading example int following link http://jakarta.apache.org/struts/faqs/actionForm.html I have a question. I have an almost similar example to run, using a String to retrieve the file name instead of FormFile object. However I am facing the following problem. My form tag is like this. html:form action=/Upload name=uploadForm type=xyz.UploadForm In my Action file's execute() method, I try to parse the uploaded file using MultipartParser. However the parser does not happen since the contentType is not multipart/form-data. If I change the tag to include the enctype as follows html:form action=/Upload name=uploadForm type=xyz.UploadForm enctype=multipart/form-data I get the following error javax.servlet.ServletException: BeanUtils.populate at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:954) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:795) at org. followed by root cause java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at Can I know what is the probable cause of this ? Is adding the enctype tag in the form tag not the only requirement ? If I dont use struts, I dont face such a problem and the file gets uploaded. Here are the relevant tags in my struts-config.xml form-bean name=uploadForm type=xyz.UploadForm/ action-mappings action path=/Upload type=xyz.UploadAction name=uploadForm scope = request input=/Upload.jsp forward name=success path=/UploadSuccess.jsp/ forward name=failure path=/Error.jsp/ /action /action-mappings Regards, C. Karthikeyan. ___ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek Kareena http://www.mpkdh.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21643] New: - Cannot create Valve with Mozilla 1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21643 Cannot create Valve with Mozilla 1.4 Summary: Cannot create Valve with Mozilla 1.4 Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I tried to create a new RemoteHostAddr access valve for Host using the Administration webapp. I can create a new valve, but I cannot switch the type/class of the valve to RemoteHostAddr using Mozilla 1.4, while this works with IE 6. I do get a 400 HTML status back; the error description claims that the client request was syntactically incorrect due to an invalid path /valve/RemoteHostAddr given. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21643] - Cannot create Valve with Mozilla 1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21643 Cannot create Valve with Mozilla 1.4 --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 10:06 --- HTTP Status 400 - Invalid path /valve/AddValve was requested type Status report message Invalid path /valve/AddValve was requested description The request sent by the client was syntactically incorrect (Invalid path /valve/AddValve was requested). Apache Tomcat/4.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21643] - Cannot create Valve with Mozilla 1.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21643. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21643 Cannot create Valve with Mozilla 1.4 --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 10:10 --- Correction: was trying to create a RemoteAddrValve (not a RemoteHostAddr valve). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.4 LB bug?
mod_jk will print out information about the lb config if you set the JkLogLevel to debug. I would suggest setting up a test system where you can test the below with JkLogLevel debug configured. Then grep the log for lines which have jk_lb_worker.c in them. This will tell you several things. 1. Whether the worker.properties are getting reread when you do an apache restart. (They should be) 2. What the lb worker thinks the config is. Then post those log lines here. Thanks, Glenn Hans Schmid wrote: Hi, I noticed the following with mod_jk 1.2.4, Apache 1.3.26 and Tomcat 3.3.1a on Solaris 8 JDK 1.4.1_03. Maybe a LB bug (Loadfactors do not recover after startup of new tomcat/graceful Apache restart). Let me explain my scenario first: I want to gracefully upgrade our webapp without loosing sessions + have a fail over scenario. Therefor we have sticky sessions enabled. Setup: 1 tomcat 01 running on Server A, 0 tomcat 02 running on Server A, 1 tomcat SB running on Server B 01 tomcat on Server A runs the application, SB tomcat on server B is standby(fallback), 02 tomcat is shutdown on Server A at the moment. All three Tomcats are in the same lb_worker: worker.list=lb-worker worker.ajp13-01.port=11009 worker.ajp13-01.host=A worker.ajp13-01.type=ajp13 worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=1 worker.ajp13-02.port=11019 worker.ajp13-02.host=A worker.ajp13-02.type=ajp13 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=0 worker.ajp13-sb.port=11015 worker.ajp13-sb.host=B worker.ajp13-sb.type=ajp13 worker.ajp13-sb.lbfactor=0 worker.ajp13-sb.local_worker=1 worker.lb-worker.type=lb worker.lb-worker.balanced_workers=ajp13-01, ajp13-02, ajp13-sb worker.lb-worker.local_worker_only=0 The worker List order should now be: 1. worker.ajp13-01 lbfactor=1,local_worker=1 TC 01 2. worker.ajp13-sb lbfactor=0,local_worker=1 TC SB 3. worker.ajp13-02 lbfactor=1,local_worker=0) TC 02 (not running) Now all requests go to worker.ajp13-01 (TC 01), none to worker.ajp13-sb (TC SB lbfactor=0), none to worker.ajp13-02.port (TC 02 not running). If Server A crashes (TC 01) all new requests go to Server B (TC SB worker.ajp13-sb) since this is then the only running Tomcat FINE This is our Fail-Over Solution (lost running sessions, but OK). Now the webapp update Scenario: 1.) shutdown TC SB on Server B, update the webapp, start tc SB and test via a seperate HTTPConnector port without Apache. 2.) this does not affect anything on production, since the lbfactor=0 on TC SB - no sessions arrive on tc SB 3.) When the test was successful, our Standby Tomcat SB is updated 4.) Now upgrade the webapp on Server A TC 02, which is currently not running. 5.) Start up TC 02 on Server A with the new version of the webapp, immediately exchange the worker.properties with a different version and gracefully restart apache: worker.list=lb-worker worker.ajp13-01.port=11009 worker.ajp13-01.host=A worker.ajp13-01.type=ajp13 worker.ajp13-01.lbfactor=1 worker.ajp13-01.local_worker=0 put old webapp on TC 01 to the foreign worker list worker.ajp13-02.port=11019 worker.ajp13-02.host=A worker.ajp13-02.type=ajp13 worker.ajp13-02.lbfactor=1 worker.ajp13-02.local_worker=1 put new webapp on TC 02 in front of the local worker list worker.ajp13-sb.port=11015 worker.ajp13-sb.host=B worker.ajp13-sb.type=ajp13 worker.ajp13-sb.lbfactor=0 worker.ajp13-sb.local_worker=1 worker.lb-worker.type=lb worker.lb-worker.balanced_workers=ajp13-01, ajp13-02, ajp13-sb worker.lb-worker.local_worker_only=0 Just the two lines marked above with swap (local_worker values of TC 01 and TC 02) 6.) now all 3 Tomcats are running. All existing sessions still go to TC 01 (sticky sessions; we do not loose running sessions) 7.) What I expect: TC 02 takes a while to startup. The worker List order should now be: 1. worker.ajp13-02 lbfactor=1,local_worker=1 TC 02 2. worker.ajp13-sb lbfactor=0,local_worker=1 TC SB 3. worker.ajp13-01 lbfactor=1,local_worker=0) TC 01 (old webapp) Since TC 02 needs 3 minutes to start up (filling caches etc.) it is not immediately availlable. During this time new sessions arrive at TC SB, since it is the next in the worker list. OK fine this works. Since these sessions are sticky as well, all users connecting during this time stay on TC SB during their whole session life. FINE 8.) As soon as TC 02 is up and running (finished all load-on-startup servlet initialisition stuff) I would expect that TC 02 gets all new Sessions (Number 1 in the worker List). This is not the case! All new Sessions still arrive at TC SB. 9.) After a while (one hour) we shutdown TC 01. Since no new sessions arrived there since our graceful restart of Apache, all old Sessions should have expired. 10.) even now (only 2 Tomcats running TC 02 and TC SB) and even after a graceful restart new Sessions arrive at TC SB Conclusion: Now, do I misunderstand the supposed behaviour of lbfactor and local_worker flag ? I think that the behaviour in 8.) is
DO NOT REPLY [Bug 21341] - Error page mechanism not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21341. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21341 Error page mechanism not working --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 13:01 --- Your patch is likely bad. The problem is likely the same that was causing FORM auth to cause problems when using a forward (instead of a redirect): because the request dispatcher was invoked from outside of the filter pipeline, its state was incorrect. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: jk 1.2.4 LB bug?
Thanks for your reply, comments see inline -Ursprungliche Nachricht- Von: Glenn Nielsen [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2003 12:26 An: Tomcat Developers List Betreff: Re: jk 1.2.4 LB bug? mod_jk will print out information about the lb config if you set the JkLogLevel to debug. done I would suggest setting up a test system where you can test the below with JkLogLevel debug configured. Then grep the log for lines which have jk_lb_worker.c in them. OK This will tell you several things. 1. Whether the worker.properties are getting reread when you do an apache restart. (They should be) Yes they were reread: Initial: [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (605)]: In jk_endpoint_t::ajp_close_endpoint [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (612)]: In jk_endpoint_t::ajp_close_endpoint, closed sd = 12 [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy ... closing other not related worker [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (172)]: Into jk_uri_worker_map_t::uri_worker_map_alloc [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (375)]: Into jk_uri_worker_map_t::uri_worker_map_open [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (396)]: jk_uri_worker_map_t::uri_worker_map_open, rule map size is 12 [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (321)]: Into jk_uri_worker_map_t::uri_worker_map_open, match rule /einsurance/=lb-einsurance was added [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (345)]: Into jk_uri_worker_map_t::uri_worker_map_open, exact rule /einsurance=lb-einsurance was added ... 5 other workers (including other lb-workers and normal workers) added [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (408)]: Into jk_uri_worker_map_t::uri_worker_map_open, there are 12 rules [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (422)]: jk_uri_worker_map_t::uri_worker_map_open, done [Wed Jul 16 14:11:16 2003] [jk_worker.c (88)]: Into wc_open [Wed Jul 16 14:11:16 2003] [jk_worker.c (222)]: Into build_worker_map, creating 6 workers [Wed Jul 16 14:11:16 2003] [jk_worker.c (228)]: build_worker_map, creating worker lb-einsurance [Wed Jul 16 14:11:16 2003] [jk_worker.c (148)]: Into wc_create_worker [Wed Jul 16 14:11:16 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance lb-einsurance of lb [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (586)]: Into lb_worker_factory [Wed Jul 16 14:11:16 2003] [jk_worker.c (171)]: wc_create_worker, about to validate and init lb-einsurance [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (420)]: Into jk_worker_t::validate [Wed Jul 16 14:11:16 2003] [jk_worker.c (148)]: Into wc_create_worker [Wed Jul 16 14:11:16 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance ajp13-01 of ajp13 [Wed Jul 16 14:11:16 2003] [jk_ajp13_worker.c (108)]: Into ajp13_worker_factory [Wed Jul 16 14:11:16 2003] [jk_worker.c (171)]: wc_create_worker, about to validate and init ajp13-01 [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1343)]: Into jk_worker_t::validate [Wed Jul 16 14:11:16 2003] [jk_ajp_common.c (1364)]: In jk_worker_t::validate for worker ajp13-01 contact is tomcathost-ei:11009 [Wed Jul 16
Solved AW: jk 1.2.4 LB bug?
Sorry Glenn, by looking deeper into the mod_jk.log. When changing worker names, I realized, that I was actually restarting Apache with the same worker.properties every time. There was a link earlier in the configuration chain, which made my switching useless :( We should definately reduce our linking !!! Thanks very much. p.s. If anybody else is interested in our LB/failover setup I am glad to provide some info. Best regards, Hans -Ursprungliche Nachricht- Von: Hans Schmid [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2003 15:15 An: Tomcat Developers List Betreff: AW: jk 1.2.4 LB bug? Thanks for your reply, comments see inline -Ursprungliche Nachricht- Von: Glenn Nielsen [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2003 12:26 An: Tomcat Developers List Betreff: Re: jk 1.2.4 LB bug? mod_jk will print out information about the lb config if you set the JkLogLevel to debug. done I would suggest setting up a test system where you can test the below with JkLogLevel debug configured. Then grep the log for lines which have jk_lb_worker.c in them. OK This will tell you several things. 1. Whether the worker.properties are getting reread when you do an apache restart. (They should be) Yes they were reread: Initial: [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (605)]: In jk_endpoint_t::ajp_close_endpoint [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (612)]: In jk_endpoint_t::ajp_close_endpoint, closed sd = 12 [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy ... closing other not related worker [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (172)]: Into jk_uri_worker_map_t::uri_worker_map_alloc [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (375)]: Into jk_uri_worker_map_t::uri_worker_map_open [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (396)]: jk_uri_worker_map_t::uri_worker_map_open, rule map size is 12 [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (321)]: Into jk_uri_worker_map_t::uri_worker_map_open, match rule /einsurance/=lb-einsurance was added [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (345)]: Into jk_uri_worker_map_t::uri_worker_map_open, exact rule /einsurance=lb-einsurance was added ... 5 other workers (including other lb-workers and normal workers) added [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (408)]: Into jk_uri_worker_map_t::uri_worker_map_open, there are 12 rules [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (422)]: jk_uri_worker_map_t::uri_worker_map_open, done [Wed Jul 16 14:11:16 2003] [jk_worker.c (88)]: Into wc_open [Wed Jul 16 14:11:16 2003] [jk_worker.c (222)]: Into build_worker_map, creating 6 workers [Wed Jul 16 14:11:16 2003] [jk_worker.c (228)]: build_worker_map, creating worker lb-einsurance [Wed Jul 16 14:11:16 2003] [jk_worker.c (148)]: Into wc_create_worker [Wed Jul 16 14:11:16 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance lb-einsurance of lb [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (586)]: Into lb_worker_factory [Wed Jul 16 14:11:16 2003] [jk_worker.c (171)]:
DO NOT REPLY [Bug 21659] New: - LogSetter not created when adding a new context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21659.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21659
LogSetter not created when adding a new context
Summary: LogSetter not created when adding a new context
Product: Tomcat 3
Version: 3.3.1 Final
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi,
When I add a new context with the admin webapp, I don't have my
servlet logs.
I have a file apps-myAppli.xml with this content :
?xml version=1.0 encoding=ISO-8859-1?
Server
Host name=myAppli
Context path= docBase=/usr/webapps/myAppli
LogSetter name=myAppli_log
path=logs/myAppli_servlet-${MMdd-HH:mm}.log
verbosityLevel=DEBUG
servletLogger=true/
/Context
/Host
/Server
For example, when I start tomcat, my context doesn't exist.
But, 2 minutes later, I add my new context with the webapps/myAppli.war and with
the file apps-myAppli.xml :
- the logFile myAppli_servlet-20030709-10:25.log is not created so there's no
servlet logs.
It seems that the ContextManager, when it adds a context, doesn't add its
interceptors like ContextXmlReader and LogSetter.
When I restart tomcat, the problem is solved.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Solved AW: jk 1.2.4 LB bug?
Glad I could help! Glenn Hans Schmid wrote: Sorry Glenn, by looking deeper into the mod_jk.log. When changing worker names, I realized, that I was actually restarting Apache with the same worker.properties every time. There was a link earlier in the configuration chain, which made my switching useless :( We should definately reduce our linking !!! Thanks very much. p.s. If anybody else is interested in our LB/failover setup I am glad to provide some info. Best regards, Hans -Ursprungliche Nachricht- Von: Hans Schmid [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2003 15:15 An: Tomcat Developers List Betreff: AW: jk 1.2.4 LB bug? Thanks for your reply, comments see inline -Ursprungliche Nachricht- Von: Glenn Nielsen [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2003 12:26 An: Tomcat Developers List Betreff: Re: jk 1.2.4 LB bug? mod_jk will print out information about the lb config if you set the JkLogLevel to debug. done I would suggest setting up a test system where you can test the below with JkLogLevel debug configured. Then grep the log for lines which have jk_lb_worker.c in them. OK This will tell you several things. 1. Whether the worker.properties are getting reread when you do an apache restart. (They should be) Yes they were reread: Initial: [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (605)]: In jk_endpoint_t::ajp_close_endpoint [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (612)]: In jk_endpoint_t::ajp_close_endpoint, closed sd = 12 [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_worker.c (118)]: Into wc_close [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (199)]: close_workers got 6 workers to destroy [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1461)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_worker.c (206)]: close_workers will destroy worker lb-einsurance [Wed Jul 16 14:11:14 2003] [jk_ajp_common.c (1468)]: Into jk_worker_t::destroy up to 1 endpoint to close [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy [Wed Jul 16 14:11:14 2003] [jk_lb_worker.c (561)]: Into jk_worker_t::destroy ... closing other not related worker [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (172)]: Into jk_uri_worker_map_t::uri_worker_map_alloc [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (375)]: Into jk_uri_worker_map_t::uri_worker_map_open [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (396)]: jk_uri_worker_map_t::uri_worker_map_open, rule map size is 12 [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (321)]: Into jk_uri_worker_map_t::uri_worker_map_open, match rule /einsurance/=lb-einsurance was added [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (345)]: Into jk_uri_worker_map_t::uri_worker_map_open, exact rule /einsurance=lb-einsurance was added ... 5 other workers (including other lb-workers and normal workers) added [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (408)]: Into jk_uri_worker_map_t::uri_worker_map_open, there are 12 rules [Wed Jul 16 14:11:16 2003] [jk_uri_worker_map.c (422)]: jk_uri_worker_map_t::uri_worker_map_open, done [Wed Jul 16 14:11:16 2003] [jk_worker.c (88)]: Into wc_open [Wed Jul 16 14:11:16 2003] [jk_worker.c (222)]: Into build_worker_map, creating 6 workers [Wed Jul 16 14:11:16 2003] [jk_worker.c (228)]: build_worker_map, creating worker lb-einsurance [Wed Jul 16 14:11:16 2003] [jk_worker.c (148)]: Into wc_create_worker [Wed Jul 16 14:11:16 2003] [jk_worker.c (162)]: wc_create_worker, about to create instance lb-einsurance of lb [Wed Jul 16 14:11:16 2003] [jk_lb_worker.c (586)]: Into lb_worker_factory [Wed Jul 16 14:11:16 2003] [jk_worker.c (171)]: wc_create_worker, about to validate and init lb-einsurance [Wed Jul 16 14:11:16 2003]
question on how to work IIS with Tomcat
Hello I try to configure the Tomcat in-process to work with IIS,I did all the configuration as suggested by Document, and restart IIS,The index.html page work, but the JSP and servlet didn't work .If I try to run jsp or servlet,the browser tell me to wait looking for the website. and then it display page not found. I have a question there are two uriworker.properties file one in jk directory and one in auto directory. I modified the one in jk directory. Am I doing the correct way? just wondering. I makes all the change in the worker.properties file as given in the document. but the jsp and servlet don't work unless I physically start Tomcat. I would appreciate if any one can help me and let me know where I am making mistake. I hope to hear from you soon. Thanks Best Regards Subhashish Dhar Purdue Pharma L .P One Stamford Forum Stamford, CT 06901-3431 Tel : 203-588-7469 [EMAIL PROTECTED] www.purduepharma.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Novice] JMX / Tomcat 4.1.X
Hi folks, 1. Is there some sample code that starts and stops a tomcat webapp via JMX? 2. Where is the actual implementation? (I get lost of the maze of tomcat modules). Thanks, dims = Davanum Srinivas - http://webservices.apache.org/~dims/ __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21666] New: - Form-based authentication doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21666. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21666 Form-based authentication doesn't work Summary: Form-based authentication doesn't work Product: Tomcat 5 Version: 5.0.4 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The action value j_security_check for a form element in a login page, configured to be used for the form-based authentication method, gives 404 The requested resource (j_security_check) is not available. Also, the login page is returned by doing a forward instead of a redirect. This means that relative paths in the login page can not be resolved. The spec is vague about how the login page should be delivered, so this may be okay, but I bet it takes many users by surprise. In TC 5.0.2, this worked fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21666] - Form-based authentication doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21666. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21666 Form-based authentication doesn't work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 22:44 --- This works for the admin webapp. The HTML code is: form method=POST action='j_security_check' name=loginForm ... input type=text name=j_username size=16 maxlength=16 id=username/ ... input type=password name=j_password size=16 maxlength=16 id=password/ ... /form Please provide a test case. Also, decision was made to use a forward, with all that implies. The spec allows this (and it should) ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2003/07/16 15:50:42
Modified:.build.xml
Log:
- Add the tester, similar to watchdog.
- The tester will need some more tweaks.
Revision ChangesPath
1.140 +64 -6 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.139
retrieving revision 1.140
diff -u -r1.139 -r1.140
--- build.xml 8 Jul 2003 06:27:09 - 1.139
+++ build.xml 16 Jul 2003 22:50:41 - 1.140
@@ -916,6 +916,63 @@
/ant
/target
+ !-- === TESTER: Run Catalina Tester Tests=== --
+
+ target name=dist-tester
+ description=Build the Catalina tester
+
+ant dir=${catalina.home}/tester target=dist
+ property name=tester.deploy value=${tomcat.build}/
+/ant
+ant dir=${catalina.home}/tester target=deploy
+ property name=tester.deploy value=${tomcat.build}/
+/ant
+
+ /target
+
+ target name=run-tester
+ description=Catalina Tests depends=dist-tester
+
+parallel
+
+java classname=LauncherBootstrap fork=yes
+arg value=-launchfile/
+arg value=catalina.xml/
+arg value=-verbose/
+arg value=catalina/
+arg value=start/
+classpath
+pathelement path=${java.class.path}/
+pathelement path=${tomcat.build}/bin/
+/classpath
+/java
+
+sequential
+!-- Let tomcat starts before starting Tester --
+sleep seconds=15/
+
+ant dir=${catalina.home}/tester/dist/bin antfile=tester.xml
+ target=all
+ property name=catalina.home value=${tomcat.build}/
+/ant
+
+java classname=LauncherBootstrap fork=yes
+arg value=-launchfile/
+arg value=catalina.xml/
+arg value=-verbose/
+arg value=catalina/
+arg value=stop/
+classpath
+pathelement path=${java.class.path}/
+pathelement path=${tomcat.build}/bin/
+/classpath
+/java
+/sequential
+
+/parallel
+
+ /target
+
!-- === WATCHDOG: Run Watchdog Tests --
target name=dist-watchdog depends=proxyflags
@@ -947,7 +1004,7 @@
/target
target name=prepare-watchdog
-copy todir=${catalina.build}/webapps
+copy todir=${tomcat.build}/webapps
fileset dir=${watchdog.home}/dist/webapps/
/copy
/target
@@ -964,13 +1021,13 @@
arg value=start/
classpath
pathelement path=${java.class.path}/
-pathelement path=${catalina.build}/bin/
+pathelement path=${tomcat.build}/bin/
/classpath
/java
sequential
!-- Let tomcat starts before starting Watchdog --
-sleep seconds=60/
+sleep seconds=15/
ant dir=${watchdog.home}/dist target=${watchdog.target}/
@@ -982,7 +1039,7 @@
arg value=stop/
classpath
pathelement path=${java.class.path}/
-pathelement path=${catalina.build}/bin/
+pathelement path=${tomcat.build}/bin/
/classpath
/java
/sequential
@@ -1003,7 +1060,7 @@
arg value=start/
classpath
pathelement path=${java.class.path}/
-pathelement path=${catalina.build}/bin/
+pathelement path=${tomcat.build}/bin/
/classpath
/java
@@ -1021,13 +1078,14 @@
arg value=stop/
classpath
pathelement path=${java.class.path}/
-pathelement path=${catalina.build}/bin/
+pathelement path=${tomcat.build}/bin/
/classpath
/java
/sequential
/parallel
/target
+
!-- == DIST: Create Directories --
target name=dist-prepare
mkdir dir=${tomcat.dist}/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21669] New: - JNDIRealm roleBase pattern enahncement
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21669.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21669
JNDIRealm roleBase pattern enahncement
Summary: JNDIRealm roleBase pattern enahncement
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Currently the roleBase attribute must be a fxed location in the directory. A
simple change would allow the role base to be specified relative to the user
DN. My enhancement suggestion would change the roleBase definition as follows:
roleBase - the base entry for the role search. If not specified, the search
base is the top level directory context. If specified it may optionally include
pattern replacements {0}..{n} corrosponding to the name parts of the user's
distinguished name (as returned by javax.naming.Name.get()).
For example, in the Realm defintion in server.xml you could specify the
roleBase as:
roleBase=ou=Groups,{1},{0}
The majority of the code to accomplish this would be in JNDIRealm.getRoles()
and could look like this:
String base = null;
if ( roleBaseFormat != null )
{
NameParser np = context.getNameParser();
Name name = np.parse(dn);
String nameParts[] = new String[name.size()];
for ( int idx = 0 ; idx name.size() ; idx++ )
nameParts[idx] = name.get(idx);
base = roleBaseFormat.format(nameParts);
}
// Perform the configured search and process the results
if (debug = 3) {
log( Searching role base ' + base + ' for attribute ' +
roleName + ');
log( With filter expression ' + filter + ');
}
NamingEnumeration results =
context.search(base, filter, controls);
Thank You,
Art
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21666] - Form-based authentication doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21666. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21666 Form-based authentication doesn't work --- Additional Comments From [EMAIL PROTECTED] 2003-07-16 23:33 --- Sorry about that. It _did_ fail as described on one machine, but it may have been related to other issues with the new forward behavior and relative paths. Anyway, on a new installation it seems to work as advertised. I should have investigated further before filing a report, but I figured it was a trivial bug introduced by the switch to forward. Regarding forward vs. redirect, I think it would be better if the spec was clear about which method _must_ be used to minimize portability concerns. Forward makes it easier to deal with POST data, but it has issues with relative links in the login/error pages. Still, maybe forward is best. It's too late to fix this in the 1.4 spec, so I guess we'll have to live with this potential incompatibility for a while. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Add Post to the clear list for protected pages
Bill Barker wrote: At the moment (with the default settings), Tomcat 4.1.x and higher add HTTP headers to non-SSL protected pages to prevent intermediate proxies from caching them. According to the HTTP/1.1 RFC (and even the HTTP/1.0 RFC), POSTed pages are not allowed to be cached by proxies (for the obvious reasons). I'd like to add request.getMethod().equals(POST) to the list of conditions to *not* add the headers. Not sure I understand :-) The RFC requires that proxies don't cache POST requests. Are you saying we should *not* include the headers, because proxies will not cache anyway ? Or to add the headers ? And what does it has to do with SSL ? ( I'm +0 any way ) Costin I'm happy if I can do this in 5.x, and ecstatic if I can back-port it to 4.1.x (since it almost removes my need to configure the Authenticator). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Add Post to the clear list for protected pages
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 8:38 PM Subject: Re: [PROPOSAL] Add Post to the clear list for protected pages Bill Barker wrote: At the moment (with the default settings), Tomcat 4.1.x and higher add HTTP headers to non-SSL protected pages to prevent intermediate proxies from caching them. According to the HTTP/1.1 RFC (and even the HTTP/1.0 RFC), POSTed pages are not allowed to be cached by proxies (for the obvious reasons). I'd like to add request.getMethod().equals(POST) to the list of conditions to *not* add the headers. Not sure I understand :-) The RFC requires that proxies don't cache POST requests. Are you saying we should *not* include the headers, because proxies will not cache anyway ? Or to add the headers ? And what does it has to do with SSL ? I'm saying to *not* include the headers, because any compliant proxy will not cache anyway. At the moment, SSL connections do not set the headers (since they also can't be cached), and that is the only current exception. At the moment, hitting the back button in the browser to a protected POSTed page forces you to re-post to view the page. This is generally a-bad-thing, since it results in you getting two copies of Madonna's CD (and charged twice ;-). ( I'm +0 any way ) Costin I'm happy if I can do this in 5.x, and ecstatic if I can back-port it to 4.1.x (since it almost removes my need to configure the Authenticator). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
