| 00:08.32 | jasonb | Cow_woC: Yes. |
| 00:08.37 | jasonb | Cow_woC: You probaly can't fix it. |
| 00:08.47 | jasonb | Cow_woC: Or, if you can fix it, you probably won't want to. |
| 00:09.16 | vinse | lol |
| 00:09.19 | vinse | wow that's grim |
| 00:10.00 | jasonb | Cow_woC: The reason your request threads are getting ThreadDeath is because: when you restart your webapp after you redeploy (or whatever), Tomcat, the servlet container, tries to wait a limited amount of time for all existing requests to complete before restarting the webapp. |
| 00:10.51 | jasonb | Cow_woC: If it waits, say, 500ms (pick any amount of time for that..), and if there are still request threads that are not done, it will kill them at the end of the 500ms in order to restart the webapp. |
| 00:11.08 | jasonb | Cow_woC: It can't wait forever.. because the administrator is telling it to restart the webapp. |
| 00:11.25 | jasonb | Cow_woC: Now, the amount of time it waits there is hard-coded into Tomcat's code I believe. |
| 00:11.39 | jasonb | Cow_woC: How long it waits, I don't know. Look at the code.. it's in there. :) |
| 00:12.25 | jasonb | Cow_woC: If it is indeed a hard coded wait duration, then in order to change it you'll need to modify at least one Tomcat class file, and deploy/run your modified one. |
| 00:13.04 | jasonb | Cow_woC: The good news is: Tomcat is open source, and you can freely modify it all you want to. The bad news is: most people don't want to, usually because either they don't feel qualified to, or they don't want to maintain their own changes. |
| 00:13.30 | jasonb | Cow_woC: Make any sense? :) |
| 00:14.39 | jasonb | Cow_woC: The even worse news is: regardless of how long you make that delay, you can never be 100% sure to never kill any request threads since it's not up to you how long those take, really, it's up to the client in too many cases. |
| 00:15.28 | jasonb | Cow_woC: Also, does the ThreadDeath exception cause you any problem other than seeing the ugly stack trace about it in your logs? It shouldn't. |
| 00:17.14 | vinse | so the whole logging/classpath part of the zilla thread is a red herring? |
| 00:17.19 | vinse | or a different issue? |
| 00:25.52 | jasonb | vinse: It looks to me to be a red herring. |
| 00:26.15 | jasonb | vinse: I'm coming at this from the perspective of writing a servlet container myself, so I think I know what's going on with it. |
| 00:38.49 | vinse | he's still talking in ##java |
| 00:38.56 | vinse | i think you just depressed him :/ |
| 00:39.15 | jasonb | heh |
| 00:39.58 | jasonb | I suppose if the exception going into the log bothers him, he could modify Tomcat to not log the exception.. another modification he probably won't want to make. Oh well. |
| 00:40.11 | jasonb | I modify Tomcat all the time. It's fun. :) |
| 00:41.15 | jasonb | I modify, recompile, redeploy, & rerun a single class at a time usually, which is a pretty small thing to change, rather than trying to rebuild all of Tomcat. That makes it the easiest. |
| 00:41.33 | vinse | what if what he really wants is to make sure that all his requests are handled before a restart? |
| 00:41.54 | jasonb | Then he'll make that timeout value like 24 hours. :) |
| 00:42.30 | jasonb | Actually, IMHO, Tomcat doesn't offer enough robustness in this area. |
| 00:43.00 | jasonb | It should actually deploy a new instance of the webapp, leaving the old one to finish its requests, while allowing new requests to hit the new version of the webapp. |
| 00:43.07 | jasonb | Or, at least offer that feature. |
| 00:43.27 | jasonb | It means more memory gets used, but the tradeoff is that no threads need to die. |
| 00:43.47 | jasonb | Other servlet containers actually handle this better, I believe. |
| 00:57.32 | fallacy | at what point is init() called on servlets in tomcat, the first time the servlet is accessed or when the web app is deployed? |
| 01:00.08 | jasonb | When it is deployed. |
| 01:00.32 | fallacy | ok |
| 01:00.34 | fallacy | thanks |
| 01:00.34 | jasonb | The init() methods of all deployed servlets get called when the webapp is deployed. |
| 01:00.36 | jasonb | Yup. |
| 01:45.22 | fallacy | jasonb: hmm, that doesn't appear to be true |
| 01:45.36 | fallacy | I tried some System.err.println() and it only printed after I tried accessing the servlet |
| 01:52.39 | *** join/#tomcat fallacy (i=[U2FsdGV@ool-45777c95.dyn.optonline.net) |
| 01:53.12 | jasonb | fallacy: It really should be true. |
| 01:53.43 | jasonb | fallacy: Also, logging may be buffered. |
| 01:54.23 | jasonb | fallacy: I'd suggest using a debugger and setting a breakpoint at the first line of code inside the init() method. That's the only way to be sure when it gets run. |
| 01:56.15 | jasonb | fallacy: IIRC, the servlet spec forbids the servlet container from delaying the invocation of the init() method.. but I'm going by memory here, which is aging. :) |
| 02:00.25 | *** join/#tomcat loktar__ (i=EatMySho@ns20324.ovh.net) |
| 02:15.09 | fallacy | jasonb: I see, ok |
| 02:15.22 | fallacy | jasonb: but I think System.err is unbuffered |
| 02:15.34 | fallacy | but I'll try a debugger |
| 02:26.14 | jasonb | It's probably the only way to be sure. |
| 02:27.02 | jasonb | You could also look through the Tomcat source, but it probably wouldn't be easy to find where the init method is called by Tomcat.. there are lots of "init" methods, even in Tomcat's own source I think. |
| 02:35.26 | vinse | [init can be called] at any of these times: When the server starts When the servlet is first requested, just before the service() method is invoked At the request of the server administrator In any case, init() is guaranteed to be called before the servlet handles its first request. |
| 02:35.38 | vinse | from the oreilly java servlet book |
| 02:45.44 | vinse | yeah the spec says "loading and instantiation" can be delayed until the servlet is needed |
| 02:46.07 | vinse | i believe that's teh first time i've seen jasonb be wrong! |
| 03:30.38 | *** join/#tomcat bigred (n=bigred@adsl-68-92-157-151.dsl.snantx.swbell.net) |
| 03:30.40 | bigred | Hi |
| 03:31.51 | bigred | I have a struts app, and all my .do extensions are mapped to the struts servlet. Is it possible to map ONE url /foo.do in a url-mapping so that I can require it to use https |
| 03:32.01 | bigred | All of the examples talk about url-mapping a whole subdirectory |
| 03:40.20 | Cow_woC | back |
| 03:40.26 | bigred | hi cow |
| 03:40.28 | Cow_woC | hi |
| 03:40.34 | Cow_woC | I think jasonb was wrong about log4j and tomcat |
| 03:40.34 | bigred | you familiar with url-mapping |
| 03:40.41 | Cow_woC | bigred: somewhat...? |
| 03:40.59 | Cow_woC | hmm |
| 03:41.02 | Cow_woC | ok, I just read your question |
| 03:41.07 | Cow_woC | not sure how to force HTTPS on it |
| 03:41.23 | Cow_woC | I think (just a guess) you'd have to enforce this in your actual webapp |
| 03:41.30 | Cow_woC | and reject any non-authentication requests |
| 04:14.32 | *** join/#tomcat Markov (n=russell@cpe-69-135-213-236.woh.res.rr.com) |
| 04:15.22 | Markov | hello. I am wondering if it's standard proceedure to set the permissions on /opt/tomcat to allow non-root users to access it |
| 04:17.13 | Markov | nm there's a tomcat group |
| 04:28.54 | *** join/#tomcat Markov (n=russell@cpe-69-135-213-236.woh.res.rr.com) |
| 04:29.29 | Markov | okay... so i added myself to the tomcat group, but I still cannot create a directory or even create a new jsp file |
| 05:05.02 | *** part/#tomcat bigred (n=bigred@adsl-68-92-157-151.dsl.snantx.swbell.net) |
| 05:05.28 | *** join/#tomcat valmont (n=chrishol@pool-71-116-177-150.lsanca.dsl-w.verizon.net) |
| 05:39.21 | *** join/#tomcat linuxfreck (n=freck@p5492AEA4.dip0.t-ipconnect.de) |
| 05:53.01 | *** join/#tomcat jasonb (i=noneoyer@adsl-66-124-73-250.dsl.sntc01.pacbell.net) |
| 06:00.22 | *** join/#tomcat loktar__ (i=EatMySho@ems02.your-freedom.de) |
| 06:07.04 | *** join/#tomcat joee (n=jhiemer@62.40.10.39) |
| 06:37.12 | *** join/#tomcat harpoon (i=stueber@ultra20.rbg.informatik.tu-darmstadt.de) |
| 08:41.10 | *** join/#tomcat freck (n=freck@p54928F5D.dip0.t-ipconnect.de) |
| 09:57.34 | *** join/#tomcat joee (n=jhiemer@62.40.10.39) |
| 10:00.25 | *** join/#tomcat loktar2 (i=EatMySho@ns20322.ovh.net) |
| 10:04.03 | *** join/#tomcat RazorJimmy (n=RzaorJmi@85.105.23.144) |
| 10:09.08 | *** part/#tomcat vinse (n=vinse@h-69-3-183-98.lsanca54.dynamic.covad.net) |
| 10:14.35 | RazorJimmy | I've installed Tomcat and I'm having problems connecting to the test page in http://localhost:8080 |
| 10:15.05 | RazorJimmy | any idea about what could cause that? |
| 10:18.53 | joee | errormessage? |
| 10:25.42 | *** join/#tomcat randrew (n=raj@dolmen.cc.columbia.edu) |
| 10:46.40 | RazorJimmy | The connection was refused when attempting to contact localhost:8080. |
| 10:46.44 | *** join/#tomcat Ioras (n=david@213.0.106.125) |
| 10:49.06 | randrew | RazorJimmy: tomcat not running? |
| 10:50.00 | RazorJimmy | Service is running |
| 10:50.56 | RazorJimmy | Is it necessary to install and run a JK connector? |
| 10:55.38 | *** join/#tomcat angelete_ (i=nibs@246.Red-80-32-42.pooles.rima-tde.net) |
| 10:55.50 | angelete_ | hi! |
| 10:56.21 | angelete_ | i'm newbie, i've installed tomcat 5.5.9, but i can't serve jsp pages |
| 10:56.46 | angelete_ | i want them into a different directory than webapps |
| 10:56.52 | angelete_ | what should i do? |
| 11:01.00 | Ioras | why do you want to use another directory? |
| 11:01.57 | Ioras | jsp files must be under an accesible location to the web server. $CATALINA_HOME/webapps is ideal |
| 11:02.18 | freck | you can put them anywhere you want |
| 11:02.27 | RazorJimmy | Ioras, do you have any idea why I cant reach the default page of jakarta tomcat? |
| 11:02.29 | freck | but you need to setup a context for it then |
| 11:02.40 | freck | RazorJimmy: check the log file |
| 11:02.42 | RazorJimmy | I cant connect using a web browser.. ie localhost:8080 |
| 11:02.47 | RazorJimmy | ok I'll do that |
| 11:03.50 | RazorJimmy | This release of Apache Tomcat was packaged to run on J2SE 5.0 |
| 11:03.50 | RazorJimmy | or later. It can be run on earlier JVMs by downloading and |
| 11:03.50 | RazorJimmy | installing a compatibility package from the Apache Tomcat |
| 11:03.50 | RazorJimmy | binary download page. |
| 11:03.53 | freck | angelete_: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/deployer-howto.html and http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html |
| 11:03.55 | RazorJimmy | Oh |
| 11:04.16 | freck | we should put a "read the logs" line into the topic... :) |
| 11:04.42 | RazorJimmy | lol |
| 11:06.08 | RazorJimmy | That's really a good idea though. Although it is a very trivial way to understand what the problem is, it doesnt occur to most people to check them :) |
| 11:12.43 | *** topic/#tomcat by RazorJimmy -> http://jakarta.apache.org/tomcat Latest stable versions of Tomcat are 5.5.9, 4.1.31, and 3.3.2 If you are a newbie, use the official distribution on Jakarta's site. Be sure to check the log files before you attempt to search for a solution. |
| 11:14.50 | lyken | lol |
| 11:14.54 | lyken | the topic isnt locked? |
| 11:22.41 | RazorJimmy | Why would it be? |
| 11:25.42 | *** join/#tomcat Magnifikus (n=vst@muedsl-82-207-210-167.citykom.de) |
| 11:38.29 | *** join/#tomcat charlse (i=charlse@59.42.196.121) |
| 11:52.47 | *** join/#tomcat manic (n=manic@dynadsl-080-228-89-149.ewetel.net) |
| 12:05.59 | Ioras | one question |
| 12:06.41 | Ioras | i have used form-based authentication in an small application |
| 12:08.56 | freck | Ioras: that doesn't quite look like a question :) |
| 12:09.24 | Ioras | it works correctly at first. |
| 12:09.33 | Ioras | One minute, i'm developing the question |
| 12:10.49 | Ioras | however, when a user tries to autenticate and fails, and then another user tries to authenticate and success, what it happens is ... the correctly logged user is again in the authentication form |
| 12:10.58 | Ioras | instead of the protected page |
| 12:11.08 | Ioras | any idea? |
| 12:11.25 | Ioras | [sorry of poor english] |
| 12:12.29 | freck | well one reason might be that the session is lost because the user doesn't accept cookies |
| 12:12.52 | freck | and there could be any amount of programming errors, which I can't find without source code |
| 12:12.57 | Ioras | the user accepts cookies (it's me testing the application) |
| 12:13.41 | Ioras | probably there is a programming error, so i'm going to ask another question |
| 12:14.53 | Ioras | imagine you have succesfully logged in |
| 12:15.36 | Ioras | and then, you close your navigator window. Notice the cookie remains, containing a JSESSIONID. |
| 12:15.46 | Ioras | Then you try to log in again |
| 12:16.22 | freck | the cookie on the client should be deleted when the browser window closes |
| 12:16.28 | Ioras | but obtain a 404 error "the requested resource (/miapp/j_security_check) is not available." |
| 12:17.39 | Ioras | ok |
| 12:18.18 | freck | but the 404 error is probably completely unrelated to the rest |
| 12:19.17 | Ioras | ok, but imagine there is a reason a cookie is there. For example, the user hasn't close the window, or a hacker (imagine...) has poisoned your navigator with a cookie or theirs ... |
| 12:20.10 | freck | if a hacker can get a valid session id of a logged in user, you're screwed |
| 12:20.19 | Ioras | then, the server should think you are trying to log in when you have already logged in (the cookie would say so), obtaining in that case a 404 error. |
| 12:20.47 | Ioras | i want to invalidate the session when the login form is shown |
| 12:21.15 | freck | you only get a 404 when the resource you request doesn't exist. I don't see how the existance of a resource depends on you being logged in or not. |
| 12:22.44 | Ioras | it's a bit tricky, and maybe i'm not explaining well ... |
| 12:23.00 | Ioras | i will think a bit more of bit, and ask later |
| 12:23.04 | Ioras | thanks |
| 12:36.10 | *** join/#tomcat manicman (n=manicman@84.245.167.60) |
| 12:36.54 | *** join/#tomcat Adamskie (n=adam@217.207.170.178) |
| 12:53.30 | *** join/#tomcat vinny (n=vinicius@user.bireme.br) |
| 13:02.11 | *** part/#tomcat vinny (n=vinicius@user.bireme.br) |
| 13:14.15 | Ioras | bye |
| 13:14.19 | *** part/#tomcat Ioras (n=david@213.0.106.125) |
| 13:18.42 | *** join/#tomcat joered (n=chatter@81-208-83-246.fastres.net) |
| 13:28.46 | *** join/#tomcat andres_co (n=nomail@200.74.148.154) |
| 13:50.56 | *** part/#tomcat randrew (n=raj@dolmen.cc.columbia.edu) |
| 14:00.24 | *** join/#tomcat loktar2 (i=EatMySho@ems01.your-freedom.de) |
| 14:05.03 | *** join/#tomcat RazorJimmy (n=RzaorJmi@85.105.23.144) |
| 14:33.14 | *** join/#tomcat supergeek (n=daniel@dexter.computingoptions.com) |
| 14:52.18 | *** join/#tomcat vinny (n=vinicius@user.bireme.br) |
| 14:54.09 | *** part/#tomcat vinny (n=vinicius@user.bireme.br) |
| 15:36.08 | *** join/#tomcat jhight (n=jhight@64.186.48.15) |
| 15:37.53 | *** part/#tomcat jhight (n=jhight@64.186.48.15) |
| 16:27.53 | *** join/#tomcat jasonb (i=noneoyer@adsl-66-124-73-250.dsl.sntc01.pacbell.net) |
| 16:37.07 | *** join/#tomcat tbrown (n=tbrown@beaver.nrri.umn.edu) |
| 16:39.21 | tbrown | hi all, seems to me http://jakarta.apache.org/tomcat/tomcat-5.5-doc/appdev/sample/sample.war is corrupt...? |
| 16:39.49 | tbrown | 3 different zip progs (jar, unzip, and winzip) report CRC errors... |
| 17:10.56 | *** join/#tomcat valmont (n=chrishol@germany.pspdev.pas.earthlink.net) |
| 17:20.14 | *** join/#tomcat harpoon (i=stueber@ultra20.rbg.informatik.tu-darmstadt.de) |
| 17:23.35 | *** join/#tomcat jasonb (i=noneoyer@adsl-66-124-73-250.dsl.sntc01.pacbell.net) |
| 17:43.47 | tbrown | hi all, seems to me http://jakarta.apache.org/tomcat/tomcat-5.5-doc/appdev/sample/sample.war is corrupt...? |
| 17:43.48 | tbrown | 3 different zip progs (jar, unzip, and winzip) report CRC errors... |
| 17:52.19 | *** join/#tomcat Cow_woC (i=Cow_woC@i216-58-12-104.cybersurf.com) |
| 17:52.20 | Cow_woC | hi |
| 17:52.25 | Cow_woC | jasonb: you there? |
| 17:54.41 | Cow_woC | is anyone awake? |
| 18:00.24 | *** join/#tomcat loktar2 (i=EatMySho@ns20322.ovh.net) |
| 18:22.22 | tbrown | does anyone have a non-corrupted copy of http://jakarta.apache.org/tomcat/tomcat-5.5-doc/appdev/sample/sample.war? |
| 18:26.05 | *** join/#tomcat Valle (n=jhiemer@p54A98E63.dip0.t-ipconnect.de) |
| 18:51.53 | *** join/#tomcat vinny (n=vinicius@user.bireme.br) |
| 18:53.30 | vinny | hi there |
| 18:54.56 | *** part/#tomcat vinny (n=vinicius@user.bireme.br) |
| 19:14.53 | *** join/#tomcat Cow_woC (i=Cow_woC@i216-58-12-104.avalonworks.net) |
| 19:14.56 | Cow_woC | moo |
| 19:17.06 | *** join/#tomcat FreemaniaX (n=Freemani@ip67-153-106-58.z106-153-67.customer.algx.net) |
| 19:25.42 | *** join/#tomcat FreemaniaX (n=Freemani@ip67-153-106-58.z106-153-67.customer.algx.net) |
| 19:41.00 | *** join/#tomcat solus (n=martin@ua-83-227-192-23.cust.bredbandsbolaget.se) |
| 20:32.55 | Cow_woC | hello? anyone awake? |
| 20:34.06 | tbrown | Zzzz *cahk* hmm what? Hmm... zzzzzz |
| 20:35.29 | Cow_woC | yes, I hear you |
| 20:35.37 | Cow_woC | any idea how to solve the ThreadDeath problem with Tomcat + log4j? |
| 20:35.44 | Cow_woC | I can give you the bugparade issue if you want |
| 20:36.03 | Cow_woC | there: http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 |
| 20:36.17 | Cow_woC | I don't understand how to fix it.. |
| 20:39.57 | jasonb | Cow_woC: I told you all about it yesterday. |
| 21:16.00 | Cow_woC | jasonb: yes, but you were wrong I think |
| 21:16.10 | Cow_woC | you said the problem was that Tomcat kills processes that don't shut down in time |
| 21:16.17 | Cow_woC | but I'm not talking about shutting down |
| 21:16.31 | Cow_woC | at least I think not |
| 21:16.49 | Cow_woC | I am getting ThreadDeath on reload |
| 21:17.01 | Cow_woC | but I think it occurs when starting up the new webapp, not shutting down the old one |
| 21:18.08 | Cow_woC | essentially, I don't care about the process getting killed (if this is what is happening)... let it die... but this shouldn't prevent the new webapp from loading... |
| 21:25.46 | *** join/#tomcat Dougnaka (n=Doug@207.225.223.185) |
| 21:34.34 | jasonb | Cow_woC: You misunderstood what I was saying. |
| 21:34.55 | Cow_woC | it's possible :) so can you please explain? |
| 21:35.22 | jasonb | Cow_woC: Are you saying this happens on a reload of a webapp? Or, you're deploying the very first deployment of a webapp on an already-running Tomcat? |
| 21:35.26 | Cow_woC | I understand log4j is dieing with ThreadDeath because it's using a ClassLoader which is no longer valid... |
| 21:35.40 | Cow_woC | jasonb: reload, exactly every 2nd time |
| 21:35.53 | Cow_woC | jasonb: which is why it looks like a bug to me. Why every 2nd time ...? why not every time? |
| 21:36.12 | jasonb | Cow_woC: Okay.. reload. Perfect. So, when you reload your webapp, Tomcat shuts down the existing version, and reloads the classes, then starts up the new classes. |
| 21:36.23 | Cow_woC | ok, so far so good... |
| 21:36.31 | jasonb | Cow_woC: This problem occurs to request threads while Tomcat is stopping the first version of the webapp. |
| 21:37.06 | jasonb | Cow_woC: It will _not_ start the new version until the old version is all the way shut down, and that means all requests using the old version must either complete gracefully, or be killed if they don't complete gracefully. |
| 21:37.59 | Cow_woC | ok |
| 21:38.22 | Cow_woC | so we're assuming log4j is getting killed on shutdown? |
| 21:54.01 | jasonb | Cow_woC: Shutdown of one instance of a webapp. Sure. |
| 21:54.23 | Markov | What's the best way for deploying webapps with Tomcat on Linux? |
| 21:54.28 | jasonb | Cow_woC: And, "killed" only applies to the request thread. Remember, these are not processes. And, Tomcat itself isn't starting nor stopping here. |
| 21:55.18 | jasonb | Markov: Probably recursively copying an unpacked webapp dir tree into the Tomcat's webapps/ dir and letting Tomcat notice it there. |
| 21:56.02 | Markov | jasonb, so I shouldn't develop the webapp in the dir. ? |
| 21:56.29 | Markov | but, then what about testing/debugging |
| 21:57.07 | Cow_woC | jasonb: ok, so the request thread is killed... and log4j gets ThreadDeath on shutdown, is that the idea? |
| 21:57.28 | Cow_woC | jasonb: why wouldn't Tomcat ignore it, and continue deploying the new webapp? |
| 21:59.32 | jasonb | Cow_woC: The request thread getting killed and log4j getting ThreadDeath is 1 occurrence, not two. That's what I'm trying to convey. |
| 22:00.26 | *** join/#tomcat loktar2 (i=EatMySho@ems02.your-freedom.de) |
| 22:02.10 | jasonb | Cow_woC: Tomcat cannot just leave the request threads from the old version of the webapp processing while starting the new webapp because the classes from the first version must be unloaded from the classloaders so that the new versions can be loaded. Threads can't use a class that is being unloaded.. at least the way Tomcat is currently written. It is possible (however, very difficult) to write a servlet container that mana |
| 22:02.10 | jasonb | ges one set of classloaders per each version of the same webapp, and allow the request threads to just keep processing.. but the tradeoff is that this would severely complicate the code, plus at runtime it would take 2 or 3 times the RAM per version of the webapp that is loaded. |
| 22:03.19 | Cow_woC | I don't get it though.. so the thread is getting killed, log4j gets ThreadDeath... fine... so then aren't the classes are unloaded? |
| 22:03.26 | Cow_woC | are -> all |
| 22:06.30 | jasonb | After all the last request threads that were using the first version of the webapp are all done processing the request, or killed, the very next thing the servlet container does is proceed to unload the classes of the first version of the webapp, and then load the new version.. and then it starts up the new version, and allows threads to come into it again. |
| 22:08.22 | LaidBack_01 | hey can jkMount take extra stuff after it : like jkMount /*.jsp ajp13:/webapps/thisdirinstead |
| 22:08.47 | Cow_woC | jasonb: ok...? |
| 22:09.17 | Cow_woC | jasonb: but starting up of the new webapp is failing... right? |
| 22:11.18 | jasonb | Cow_woC: Why would you think that starting up the new version of the webapp fails? |
| 22:12.19 | jasonb | Cow_woC: Can you paste that ASF Bugzilla URL to that bug in here again? |
| 22:13.26 | Cow_woC | sure, hold on |
| 22:13.37 | Cow_woC | jasonb: http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 |
| 22:14.11 | Cow_woC | jasonb: well on my side, I am using Netbeans with its internal Tomcat 5.5.7 server... when I do a redeploy it returns a failure (and stops) with a ThreadDeath on every 2nd try |
| 22:19.03 | LaidBack_01 | I'm trying to setup tomcat to serve files out of dirs based on virtual host - is it possible to make defines - like ajp13_host1 ajp13_host2 and so on? |
| 22:26.30 | jasonb | Cow_woC: First things first: NetBeans's Tomcat 5.5.7 is broken in more ways than I'm aware of, so I'm not going to go out of my way to figure out what's wrong with it. It's just broken. If you see the same things with a stand-alone Tomcat (with a stable version, not 5.5.7), then I'm more interested in investigating.. |
| 22:26.59 | LaidBack_01 | man, I must be going about this the wrong way - I have multiple sites on a server - using apache vhosts. It can't be that I have to put ALL the files into the tomcat/webapps dirs can it? I mean - can't I seperate the files into some kind of directory structure and make it tomcat reade the correlating files from a dir based on vhost or some similar setup? |
| 22:27.14 | jasonb | Cow_woC: But, if your NetBeans is deciding that the ThreadDeath exception constitutes a webapp restart failure, then it's wrong about that. |
| 22:27.39 | jasonb | Cow_woC: I'd really like to know what failure you're seeing. The ThreadDeath exception itself isn't a failure here. |
| 22:30.18 | Cow_woC | jasonb: to my understanding, Netbeans uses catalina.bat to invoke redeploy |
| 22:30.34 | Cow_woC | jasonb: and it parses for failures, which is what ThreadDeath looks like, so it aborts |
| 22:30.49 | Cow_woC | it is also possible the batch file returns a non-zero return code to it..? not sure |
| 22:32.01 | LaidBack_01 | does anyone in here run multiple sites on apache with tomcat to do the .jsp pages and not store all the freaking pages in the same dir? |
| 22:32.13 | jasonb | Cow_woC: Okay, so that's proof that NetBeans doesn't know what it's talking about. The ThreadDeath is no restart failure. |
| 22:32.33 | Cow_woC | jasonb: hey, I'm not sure what Netbeans is saying |
| 22:32.37 | Cow_woC | jasonb: I'm *guessing* |
| 22:32.51 | Cow_woC | jasonb: I'd have to investigate it further to be sure |
| 22:33.08 | jasonb | Sure.. in that case though. |
| 22:33.14 | Cow_woC | jasonb: how is Netbeans supposed to check for success/failure on redeploy? |
| 22:33.49 | LaidBack_01 | wtf... am i invisible or something |
| 22:35.04 | *** join/#tomcat Big_Bozz (n=Big_Bozz@cpc1-shep4-3-0-cust153.leic.cable.ntl.com) |
| 22:35.43 | Cow_woC | LaidBack_01: I don't |
| 22:47.09 | LaidBack_01 | well.. I mean, this doesn't make sense - what I'm asking seems like it'd be easy: I have a site - domain1.com, it's got many .html files that apache handles fine and a few .jsp files that tomcat handles fine - it all works wonderful with a single site. So I want to add a site - domain2.com... but I can't get tomcat to understand that I have a directory structure it should follow... it want's to call file.jsp from the webroot - not webroot/domain2.com |
| 22:47.09 | LaidBack_01 | <PROTECTED> |
| 22:48.51 | LaidBack_01 | is tomcat so single minded that I HAVE to run multiple instances of it to get seperate dirs ??? I mean... what a freaking waste. |
| 22:48.57 | LaidBack_01 | I'm gonna switch to resin |
| 22:56.27 | jasonb | By all means, feel free. |
| 22:56.38 | jasonb | That's what's so great about open source. |
| 23:01.30 | LaidBack_01 | just found the virtual hosts docs on tomcat |
| 23:01.59 | LaidBack_01 | was just pissed cause it didn't appear to have it - and it seems like everywhere i go - no one has ever done this before... |
| 23:02.26 | LaidBack_01 | it's not like i'm asking something difficult.... but lack of familiarity leads to frustration. |
| 23:03.55 | *** join/#tomcat nichoj (N=nichoj@146-115-26-214.c3-0.abr-ubr1.sbo-abr.ma.cable.rcn.com) |
| 23:06.28 | nichoj | from a webapp, is there a way to refer to a file (ie new File(...)) stored somewhere where it's deployed (ie WEB-INF) ? |
| 23:07.20 | jasonb | LaidBack_01: Have you already read the section on vhosting in Tomcat: The Definitive Guide (O'Reilly)? |
| 23:09.55 | LaidBack_01 | no I have not |
| 23:10.02 | LaidBack_01 | I'll download that now |
| 23:10.17 | LaidBack_01 | I've been reading the docs on jakarta.apache.org/tomcat |
| 23:13.26 | jasonb | Generally, though, when you involve apache httpd with a Tomcat installation, all kinds of things become about 50 times harder than they should be. That, plus there are far too many bugs in the connector modules, plus configs are so flexible and unforgiving that you can have configs that are 99.9% right and it still doesn't really work. |