Tomcat 4.1.12/Apache and file downloads problem
We have a server that handles authentication and logging for client file downloads. Our clients are (charitably) less-than-knowledgable. To allow save as right click functionality, the url on the constructed links are like this: http://host/app/servlet/Controller/FileNameToUse.foo?a=dw; where FileNameToUser.foo causes the save-as dialog to get the right file name, and the query params are used to route through the server to check authentication and log the download. (I know, but I inherited it) This works fine under Tomcat 3.*, but Tomcat 4.1.12 refuses to co-operate. The download action is not called. If the url is changed to http://host/app/servlet/Controller?a=dw; it gets the file ok, but the filename in the save-as dialog is not set correctly, and we could NEVER expect our clients to get that right. So: 1. Am I missing something in the config of 4.* that's blocking this functionality? or 2. Is there another way to force the filename on the download output stream? -- Michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bean Choices (code question)
I have a lot of informational beans that hold static reference data (think ISO codes, State abbreviations, etc...) With these types of beans, I have the choice of instantiating a singleton object reference to the bean and accessing the methods through the object, or making all the methods public static so I can access them via BeanName.method(). For the former, the bean does all of it's initialization and database access in it's constructor and my JSP's have something like the following at the top: Isn't this a prime candidate for application-level beans? These are instantiated when the servlet is started and reused, no? -- Michael
IE problem or tomcat bug?
We've recently moved to a tomcat/apache server under linux using the most recent release builds. Some of our clients are experiencing strange behavior, like getting the following stack trace to their browser: Tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(THreadPool.java:498) at java.lang.Thread.Run(Thread.java:484) (may be incomplete; sent by a client in email since we cannot duplicate the problem) The common thread seems to be that they're using IE as the browser. Is this a known problem (thought I couldn't find it in the archives)? Is there some workaround? Would backing off to ajp12 fix it (we never had the problem with apache/jserv on NT)? Thanks for any suggestions. -- Michael
Re: IE problem or tomcat bug?
At 07:59 AM 4/18/01, you wrote: I've not seen this before. You might want to try contacting the developers of mod_jk (I take it your using this if your using ajpv13?) directly. Its always a pain when you can't reproduce these kind of problems. Are all of the problems based around the same version of IE? Which browser do you yourself use? sam Looks like different versions of IE all have the same problem. To make matters worse, the same version of IE works fine on some computers but not others. We have tested IE versions from 4.0 up and none have the problem in our tests. We're assuming it may be an interaction between various MS programs (outlook, etc) on the client end. Netscape users never experience the problem. Thanks for the response. -- Michael
appending to existing log on restarts?
Is there some way to get logging to append to existing files rather than starting new ones at startup time? -- Thanks -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
