Re: How to disable AutoDeploy in Tomcat 4.1.29 ?
suviswan wrote: Hi I have tried changing autoDeploy=false in server.xml. But it's not working. It's still discovering the web applicatios under webapps directory. Any ideas ? Try setting the deployOnStartup property to false in your host definition. Look at section Automatic Application Deployment in tomcat docs for more info on this: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/host.html#Automatic%20Application%20Deployment regards, -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: virtual host in tomcat 4?
SH Solutions wrote: Hi So if I add the following somewhere in my server.xml file the user that types www.aa.com will be pointed to http://myipaddress:8080/webapps/aa/index.jsp? No. As I have already said, there is NOTHING, you can to to archieve this. Yes he can. If the hosting company for aa.com is kind enough to allow him to URI forward his domain to http://myipaddress:8080 or 8443 (that is if he has port 8443 visible from outside, which I think he said he does.), he'll almost get what he wants. -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat monitor plugin Prototype
Peter Lin wrote: well I've managed to get a rough prototype coded and working. I don't want to check it into JMeter's CVS yet, since the code is still ugly and needs to be cleaned up. I'm planning on posting it on my system tonight. Anyone interested in testing it and giving me feedback? it would really help for people to give it a shot and kick the tires a bit. once it's cleaned up and more stable, I will check it into JMeter's CVS. I would like to give it a shot, as well. Are you going to post the URL to the binary (?) on your system later tonight? Keep up the good work, -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: virtual host in tomcat 4?
SH Solutions wrote: Hi Yes he can. If the hosting company for aa.com is kind enough to allow him to URI forward his domain to http://myipaddress:8080 or 8443 (that is if he has port 8443 visible from outside, which I think he said he does.), he'll almost get what he wants. Which would in fact be what I called to have an reverse proxy outside the firewall. There is definitly nothing you can do (apart of putting your tomcat or a remote proxy outside of your filewall). I wasn't sure you meant the same thing, but if you did, then OK :) -- A - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: virtual host in tomcat 4?
Forte, Graham wrote: This is getting a little off-topic, but here goes: I think I need to take baby steps. My goal right now is to be able to access my development machine from another machine on the LAN. Right now I have to type the following to access my dev machine from another LAN box: http://myMachineName:8080/myWebApp/logon.jsp I want to(baby steps) be able to access it by the following: Step 1: http://myMachineName/myWebApp/logon.jsp (NO PORT) Have your sys admin open up port 80 on your box or redirect traffic from port 80 to port 8080 (like Steffan suggested) Step 2: http://myMachineName/logon.jsp(NO APP ROOT) Add logon.jsp to your ROOT context Step 3: http://myMachineName/(NO PAGE URL) Modify the welcome-file directive for your ROOT context to include logon.jsp Step 4: www.myNewDomain.com I will have only one web site running on this machine and I(my company) will be hosting it. Modify myNewDomain.com's DNS to point to your system or rinse, wash, repeat as necessary. Good luck, -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Process Died | Production
Christopher Schultz wrote: I've experienced even more random crashes (SEGV). It turned out to be bad memory (or bus), and it only showed up under pretty heavy load. :( This is a little OT, but just out of curiosity, has anybody been successful in gaining root/tomcat/whatever-uid shell by capitalizing on a JVM's (not necessarily tomcat's) core dump? I've always wondered if that was possible. I know its extremely hard (impossible?) to consistently overflow JVM's stack, but has it ever been done? I've never heard of anything like this before. However, Java's stack is not what gets overflowed, here. IF the JVM goes down, it's the JVM code that faults, not the Java code itself. Java's stack and heap are pretty far away from anything that's executing. Notice I said overflowing of the JVM's stack not Java's (bytecode) stack. I am well aware of the fact that you can't smash a Java stack - that's just how the language is architected. -- A - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Process Died | Production
Christopher Schultz wrote: I've had the displeasure of experiencing a Tomcat JVM core dump on me not too long ago (in a multi-user development environment, fortunately) on a Sparc/Solaris box. It turned out to be due to insufficient swap memory in the system. I didn't see any OutOfMemoryExceptions raised prior to the crash, so it wasn't that obvious, but the top command came to the rescue in the end. Good one ;) It reminds of another time, where I had internal crashes occurring due to a low limit of file descriptors (ulimit -a will show you the limits). That one was frustrating ;) I'm sure many people on this list of horror stories with seemingly random crashes... I've experienced even more random crashes (SEGV). It turned out to be bad memory (or bus), and it only showed up under pretty heavy load. :( This is a little OT, but just out of curiosity, has anybody been successful in gaining root/tomcat/whatever-uid shell by capitalizing on a JVM's (not necessarily tomcat's) core dump? I've always wondered if that was possible. I know its extremely hard (impossible?) to consistently overflow JVM's stack, but has it ever been done? -- A - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process Died | Production
Shapira, Yoav wrote: Yeah, I've encountered internal crashes, as I imagine many others on the list have. In my case it was due to missing Solaris OS patches. The hs_err produced by the JVM when it has an internal crash sometimes says things like could not allocate font package xxx which is a hint to a badly installed JDK. Other people on Linux have had internal crashes with the wrong thread library configured, or the wrong kernel version. You can search the archives for all this information. It's more an art than a science to debug these, and that can be frustrating. I agree. I've had the displeasure of experiencing a Tomcat JVM core dump on me not too long ago (in a multi-user development environment, fortunately) on a Sparc/Solaris box. It turned out to be due to insufficient swap memory in the system. I didn't see any OutOfMemoryExceptions raised prior to the crash, so it wasn't that obvious, but the top command came to the rescue in the end. -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and SSL: problem with expiration of VeriSign Global Server ID Intermediate Root
Jörn Böckenkamp wrote: It IS easy when you're using a self-signed cert, but I have to use one from VeriSign and I don't think that I can regenerate the VeriSign cert with a new date :-) Did you try importing the new certificate directly into the user's keystore? For example, if you run the service as root , you'll have to remove the old certificate and import the new one into /.keystore (in UNIX of course) with alias 'tomcat'. I'd recommend you backup the keystore file before you make any changes to it. Also, restart the server after you make the change, so TC starts up with the new certificate. HTH, -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Very Very Slow performance of Tomcat - Connection Pool Dies
Harry Mantheakis wrote: If your firewall drops idle connections after some time, you will need to tune a couple of settings. In your sysctl settings for the Apache machine, set your tcp keepalive time to a value lower than the drop time of your firewall. I have a very strict firewall policy on my Linux box - using iptables. Only port 80 packets get through. Nothing else. Does that have something to do with my problem? Is there an ICMP port that I need to open up? It does sound more like a firewalling issue. I'd doubt its the iptables, though, unless you have squid running on your Linux box ? Also, do you connect to the Oracle DB through VPN or another secure link? I know of many corporate VPN servers, Proxies set up by default to drop connections inactive for a specific amount of time, which is more or less what you're seeing. To corroborate this, I would set up a simple TCP server on the Linux box with an open connection to the Oracle backend and leave it open and see if I'd get similar results. -- A - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: include files
...and if you're a windowz fanatic, you still have hope. You can download a copy of touch from: ftp://ftp.microsoft.com/Services/TechNet/samples/ps/win98/Reskit/FILE/ (TOUCH.EXE, is what you're looking for) or you could simply install Cygwin, the greatest unix emulator on the face of this planet! (Sorry, couldn't resist) Yiannis Mavroukakis wrote: The touch command is on Unix OS'es. It hasn't got anything to do with tomcat. What it does is it updates (among other things) the last modified attribute of a file, but in your case the purpose is (at least if my head is screwed on right) to trigger Tomcat into detecting a file change in the work directory, hence doing a reload. If I got the Tomcat bit wrong, shoot at the bright red target on my forehead :) Yiannis. -Original Message- From: Chris Daly [mailto:[EMAIL PROTECTED] Sent: 10 February 2004 14:50 To: Tomcat Users List Subject: Re: include files thanks. do i delete the name of the app under tomcat, for example work/Standalone/localhost/Website ? and all the $... files and the two directories - Help and WEB-INF under this directory ? what is the touch cmd ? i cant find it in my wrox tomcat book ? cheers chris snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: JavaScript Doubt
Shapira, Yoav wrote: Howdy, Is it really necessary to include a 20-line legal disclaimer in a 20 character long response? I'm a fan of mailing list etiquette, but in defense of this poster, many companies add disclaimers to outgoing messages without knowledge, (explicit) consent, or control of the individual sender. Yoav Shapira Not to extend this thread any further than it really should, but I can understand if the legal disclaimer is appended by the company outside the control of the employee sending the email, though, I'm unsure if that's done without the knowledge of the sender. Either way, adding terms of confidentiality to a message is a little redundant when the mail is sent to a public mailing list, IMO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat und SSL
Unless you've resolved the issue recently, both URIs come up fine for me. Tested on Mozilla 1.6b and IE 6.0 Lars Schreiber wrote: Hi thanks for help and for confidene to my english knowledge :-) in order that you understand my problem.. i have prepared a link for you https://test.extremewebs.de:8443/test/StatusServlet if im use the link over the mod_jk2 he works fine https://test.extremewebs.de/test/StatusServlet but here ist the problem, as soon as put html form tags or links etc to my servlet the server response a information about unsecure parts on my website. i dont have find any good solution to work with apache and tomcat together someone dont work if anybody here to explain me step to step how to setup a apache with ssl and a conector to tomcat with ssl ? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error-page for exception-code
Merrill Cornish wrote: I originally had errorPage declarations at the top of all my JSP pages, which worked. Then I heard about the error-page element in web.xml. So I replaced all of the individual errorPage declarations with: error-page exception-typejava.lang.Exception/exception-type location/errorPage.jsp/location /error-page in my application's web.xml, and it worked fine. Next I tried error-page exception-code404/exception-code location/login.jsp/location /error-page to intercept bad URLs and redirect them to the login page. However, THIS does not work. Bad URLs just get the standard Tomcat 404 error page as always. I've Googled the problem and found it doesn't work for me, but it DOES work for me, but it does NOT work for me, and so on. Is there some secret here? (I'm running 5.0.18.) Merrill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Replace the exception-code with the error-code tag and you'll be in business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Prohibited Content
Philipp Taprogge wrote: Ha... just got another one... if complained about my message having different SMTP-To: and MIME-To: headers. I am not sure if that's what you got as well. I'm getting the same error from a Symantic server, specifically hosted by the leds.com domain. Its due to the fact that I relay the emails from a different SMTP server than my default mail domain. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] installing new java jdk
Try the following URI under wget to see if that works for you: http://tinyurl.com/yugvm Its the download link to the J2SDK 1.4.2 RPM. Adam Hardy wrote: That trick with wget didn't work for me because wget complained it couldn't run the https protocol. Is there a wget that will run https? I'll check it out. On 01/26/2004 04:54 PM Philipp Taprogge wrote: Hi! Adam Hardy wrote: If I go to my webserver with a linux shell and use Lynx, the download page at java.sun.com gets truncated. wget and curl don't work either because they're not interactive so you can't click on the 'accept terms' submit button. This is a problem I often run into as well. Although there are ways to get the sun download page to work with curl, I have not yet figured them out. Easiest is is fact to download the sdk from another machine and ftp/scp it to your server. There is another way that might work: go to the sun page from your desktop-machine, click your way through past the license terms and then let wget fetch _exactly_ whatever link your browser provides for the download. I have used that one successfully, but only with machines that are NATted through the same router. HTH Phil - 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]
[OT] Re: JavaScript Doubt
[EMAIL PROTECTED] wrote: as already said..pls maintain list protocols... Pavan Kumar Tata Consultancy Services Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com [Redundant disclaimer snipped] which, BTW includes the following section from the Netiquette Guidelines (RFC 1855) - If you include a signature keep it short. Rule of thumb is no longer than 4 lines. Remember that many people pay for connectivity by the minute, and the longer your message is, the more they pay. Is it really necessary to include a 20-line legal disclaimer in a 20 character long response? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP not reloading
A few things to try here: 1. What happens when you access your JSPs directly through tomcat (port 8080?). Do you get the same result? 2. What happens when you do $touch foo.jsp? Does your server pick up the changes, then? 3. Did you try upgrading to 5.0.16? *duck* Mike Curwen wrote: Alright, I've tried upgrading to 4.1.29. The exact same behaviour is occuring with this version as well! I'm kinda desperate here... developing under these conditions is negative fun. Someone just give me a hint! Anything!! :) -Original Message- From: Mike Curwen [mailto:[EMAIL PROTECTED] Sent: Monday, December 22, 2003 12:18 PM To: [EMAIL PROTECTED] Subject: JSP not reloading Hi everyone, This has been covered before, I know. But there doesn't seem to be a common agreement on what the problem (and therefore solution) is. Our Tomcat 4.1.24 instance has spontaneously decided to no longer recognize JSP changes! I say spontaneously, because we were running fine, in production, a number of different sites. As it happens, a couple of these sites are getting 'tweaked'.. and so there are a large number of 'small changes' being made to the JSP pages. And as of Thursday last week, here's what we're observing... From the 'ok' state, we can get away with making one change to a JSP page. Then we click refresh in the browser, and see the change we made. For every subsequent change to the JSP, the change is NOT reflected in the browser. That page is now considered in the 'not ok' state. We go for lunch, or come back the next day. If we make a change, it is recognized. (So the page was back in the 'ok' state)... but like before lunch, or yesterday, after that one change, it's back to the 'bad' state. This applies to JSPs invoked from the address bar, AND through a JSP Include on the server-side. Even after 'touching' the parent JSP, the 'included' one still appears as the 'old' version. The ugly hack: If my JSP is called foo.jsp, I edit foo.jsp for my changes. Then in a command line window I type cp foo.jsp fooX.jsp (where X is an ever increasing integer). And then I call fooX.jsp from the browser. To ugly fix: We must stop Tomcat, clear the work directory's folder for that web app, and restart. Then we're back to every page in the 'ok' state for just one change. There have been *zero* configuration changes to any of httpd.conf, workers.proprties and server.xml files in the timeframe of when it all went south. It's not the 4.1.27 reloading issue. We're on the internal network, there is no proxy caching. It's not browser caching. It's not a server timestamp out of sync. Here's one thing of interest: One of the contexts that is under development has the reloadable=true in its Context entry. The other does not. But that aside, BOTH of these web apps were reliably picking up changes, up until last week. (Does reloadable have anything to do with JSP's or just items under WEB-INF ?) Slackware 9 Apache 2.0.45 Tomcat 4.1.24 JK (not sure of version) Has anyone run into this behaviour?? Is there a FAQ or google page covering this? I know this little bug has been around in some form or another for quite some time. Here's one entry: http://www.mail-archive.com/[EMAIL PROTECTED]/msg 99927.html I'm thinking I'll have to try upgrading to 4.1.29. - 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: JSP not reloading
Mike Curwen wrote: 3. Did you try upgrading to 5.0.16? *duck* no, we're not wanting to use 5.0 until (probably) 5.1. There's nothing we need from the new servlet spec. I didn't mean for you to switch over to 5.x for good (If you didn't want to, that is). I just wanted to see if you experienced the same problems with 5.x, and if you did, then I'd bet the problem is with the settings on your box and not directly related to Tomcat.You won't have to set up the new server entirely, just unpack, start it with the default configuration, and test it out with a simple JSP in the examples context. -- Ankur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP not reloading
Also, If you're still open to ideas, what happens when you do this with your old/new server: 1. You make changes in a different (examples) context? 2. Do you get a 404 (File not found) error if you move foo.jsp to fooX.jsp? Mike Curwen wrote: -Original Message- From: Ankur Shah [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 12:15 PM To: Tomcat Users List Subject: Re: JSP not reloading A few things to try here: 1. What happens when you access your JSPs directly through tomcat (port 8080?). Do you get the same result? same (bad) result 2. What happens when you do $touch foo.jsp? Does your server pick up the changes, then? no 3. Did you try upgrading to 5.0.16? *duck* no, we're not wanting to use 5.0 until (probably) 5.1. There's nothing we need from the new servlet spec. - 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: TC5 + SSL: Keystore password bound to default changeit?
Remy Maucherat wrote: Baer Peter Christoph Alexander wrote: Hi! I have a question about something, I observe, but don't want to believe... ;-) Tomcat 5 can use my keystore, but only if the password is changeit, the default password. Now, the docs say, one should use this, but with TC 4.0.6 it was possible to change it. Is the password hard coded in TC 5? I didn't test that particular feature myself, but I believe this works ok. The way connectors parameters (and in particular SSL parameters) are defined changed in TC 5.0.x. Look there: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/coyote.html There's the SSL howto also. Also, you might want to make sure that the password of your *target key* matches your keystore password. I'm not sure how that plays out in tomcat world, but I can see that to be a problem if the server assumes the key's password to be the same as that of the keystore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL problem with TC 5.0.16
Are you able to query your keystore (D:\ourwebapp\certificate\keystore) using the specified password from the command-line? For instance, what happens when you do this?: c:\%JAVA_HOME%/bin/keytool -list -keystore D:\ourwebapp\certificate\keystore -storepass yeahsure I just downloaded TC 5.0.16, configured SSL and ran it with no problems, FWIW. Baer Peter Christoph Alexander wrote: Yes, we set keystorePass to what we entered when creating the keystore. Below are the Connectors from our server.xml. Do you see anything wrong, here? Something, that was ok with TC 4.0.6, but is no longer valid for TC 5.0.16? Thanks in advance! Alex snip Connector acceptCount=100 connectionTimeout=3 debug=0 disableUploadTimeout=true enableLookups=true maxSpareThreads=75 maxThreads=150 minSpareThreads=25 port=8080 redirectPort=8443 scheme=https secure=yes / !-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -- Connector acceptCount=100 debug=0 disableUploadTimeout=true enableLookups=false maxSpareThreads=75 maxThreads=150 minSpareThreads=25 port=8443 scheme=https secure=true Factory clientAuth=false keystoreFile=D:\ourwebapp\certificate\keystore keystorePass=yeahsure protocol=TLS / /Connector !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- Connector debug=0 enableLookups=false port=8009 protocol=AJP/1.3 redirectPort=8443 / /snip -Original Message- From: Luc Foisy [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 5:53 PM To: Tomcat Users List Subject: RE: SSL problem with TC 5.0.16 Did you set keystorePass? -Original Message- From: Baer Peter Christoph Alexander [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 11:49 AM To: '[EMAIL PROTECTED]' Subject: SSL problem with TC 5.0.16 Hi, before you start throwing eggs and tomatoes at me: I *have* searched the mailing list archive before posting this message... ;-) I just installed Tomcat 5.0.16. Now we want to migrate an application from TC 4.0.6 to it. For this we need to run TC with SSL. However, there's apparently a mistake in our SSL configuration. After adapting server.xml for our webapp, we see the following startup error message: snip INFO: Starting Coyote HTTP/1.1 on port 8080 08.12.2003 17:01:45 org.apache.coyote.http11.Http11Protocol start SCHWERWIEGEND: Error starting endpoint java.io.IOException: Keystore was tampered with, or password was incorrect at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:748) at java.security.KeyStore.load(KeyStore.java:652) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocket Factory.java:295) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESoc ketFactory.java:259) at org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.getKeyManagers(JS SE14SocketFactory.java:172) /snip Following the docs, we checked the password and we have also created quite a few new keystores and put there paths into the keystoreFile attribute of the Factory tag. In TC5 even the old keystore with the original certificate of our application is rejected. Has anybody seen this before? Can you provide some hint, what the problem could be caused by? We can rule out the things mentioned in the docs, I think! Thanks in advance! Regards Alex - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
