00:56.40 | jasonb | fallacy: Tomcat itself does not implement any way to proxy connections to another web server, but there are third party jars that are easy to add to Tomcat to make it do that. |
00:57.18 | jasonb | fallacy: http://www.servletsuite.com/servlets/httpproxy.htm |
01:16.23 | *** join/#tomcat alsa (n=shadow@212.98.136.28) |
01:21.32 | Hattori | jasonb: and mine? |
01:22.03 | jasonb | Hattori: You should ask the company who sold you jbuilder. We don't do tech support for them in here. |
01:26.59 | Hattori | jbuilder has not great support indeed =\ |
01:27.22 | Hattori | i would better move to eclipse asap.. |
01:27.47 | jasonb | I would suggest NetBeans. |
01:27.57 | jasonb | But, either one would be better than eclipse. |
01:28.03 | jasonb | err, better than Jbuilder. |
01:28.11 | Hattori | anyway, the stack trace should suggest what problem could be.. which file doesn't care about etc.. |
02:12.23 | fallacy | jasonb: great, thanks |
02:15.58 | jasonb | fallacy: You're welcome. |
02:51.23 | *** join/#tomcat codeshepherd (n=codeshep@bb121-7-80-240.singnet.com.sg) |
05:38.39 | *** part/#tomcat codeshepherd (n=codeshep@bb121-7-80-240.singnet.com.sg) |
06:59.41 | *** join/#tomcat johni (n=johni@utdpat241097.utdallas.edu) |
08:21.46 | *** join/#tomcat mmmmmmmmm (n=info@213.219.139.100.adsl.dyn.edpnet.net) |
08:41.58 | mmmmmmmmm | i've just installed tomcat5.5, this install is working properly as i can access it through localhost:8180. I've also installed mod_jk but there it fails with an internal server error |
08:42.06 | mmmmmmmmm | can't find any error |
08:42.17 | mmmmmmmmm | not in the apache2 log, not in the mod_jk log |
08:42.55 | mmmmmmmmm | probably something wrong with my virtualhost? |
08:43.42 | mmmmmmmmm | any ideas on how to solve this |
09:28.18 | *** join/#tomcat gregor_k (n=a@p54A19F23.dip0.t-ipconnect.de) |
11:10.00 | *** join/#tomcat fzlogik (n=fuzelogi@dhcp-152-78-61-16.ecs.soton.ac.uk) |
11:44.02 | *** join/#tomcat prgrmr (n=prgrmr@bzq-88-155-88-5.red.bezeqint.net) |
13:01.01 | *** join/#tomcat Erev (n=disvroia@183.Red-83-36-221.dynamicIP.rima-tde.net) |
13:24.26 | *** join/#tomcat Erev (n=disvroia@183.Red-83-36-221.dynamicIP.rima-tde.net) |
14:23.57 | *** join/#tomcat a4akb (n=Akbara@62.215.156.215) |
14:43.35 | *** join/#tomcat magz (n=ma9o0_st@222.127.48.206) |
14:44.01 | *** part/#tomcat magz (n=ma9o0_st@222.127.48.206) |
14:53.47 | *** join/#tomcat Erev (n=disvroia@183.Red-83-36-221.dynamicIP.rima-tde.net) |
16:16.57 | *** join/#tomcat wsmoak (n=wsmoak@ip68-110-100-131.ph.ph.cox.net) |
17:32.03 | *** join/#tomcat Rashmi (n=chatzill@ool-44c498ca.dyn.optonline.net) |
19:42.03 | *** part/#tomcat a4akb (n=Akbara@62.215.156.215) |
20:24.03 | *** join/#tomcat wsmoak (n=wsmoak@ip68-110-100-131.ph.ph.cox.net) |
21:30.30 | *** join/#tomcat russt (n=tom@c-24-8-8-142.hsd1.co.comcast.net) |
21:33.05 | russt | Hello - I have a development project that resides on a remote server. Since the project is in development mode there are frequent changes to the code. The current size of the war file is about 12.5 MB. However, having to transfer this to the remote host every time a single change is made seems a bit silly. On the other hand, if I copy just the modified classes and then restart the server, the new stuff is replaced by the contents of the existi |
21:37.44 | jasonb | truncated. |
21:44.02 | russt | hm |
21:44.21 | russt | jasonb: where did it stop? |
21:44.47 | jasonb | russt: " the new stuff is replaced by the contents of the exist" |
21:45.11 | russt | ing war file. I'm trying to figure out an elegant way to handle this scenario. Any ideas? |
21:46.09 | jasonb | 1. Stop using war files. Yes, I know. But, it will be a helpful thing to do. Trust me. |
21:46.19 | russt | I'd actually like to |
21:46.21 | jasonb | 2. Deploy using rsync if you can. |
21:46.36 | russt | lol that's what I was doing before, but something changed and that stopped working. |
21:46.57 | russt | that would be perfect in fact. |
21:47.10 | russt | I guess I'll have to fix what's broken and make that work again. |
21:47.24 | jasonb | Also, you should either restart the server when you redeploy, OR you should configure Tomcat to unpack any modified wars during runtime, not both. |
21:47.39 | russt | hm ok |
21:47.48 | jasonb | deploying via rsync is wonderful, especially in your case where you have a large webapp. |
21:48.24 | russt | ok, I'll try to get that working again. I'll need to find an rsync client for windows now, but that should be too hard. |
21:48.33 | jasonb | If you are having Tomcat unpack the war file in order to deploy this particular context, you *cannot* modify the unpacked dir without triggering a nother unpacking of the war file unless you tell Tomcat to only unpack at startup. |
21:48.36 | russt | shouldn't* |
21:48.41 | jasonb | cygwin. |
21:49.00 | russt | ok - I wonder if gnuwin32 has rsync in it |
21:49.16 | russt | cygwin might work too |
21:49.18 | russt | well* |
21:49.21 | russt | will* damnit |
21:50.03 | russt | ok jasonb thanks for your tips - I will probably eliminate the war file altogether. |
21:50.35 | jasonb | You're welcome. Yes, you'll be happier without the war file distraction. |
22:15.10 | *** join/#tomcat codeshepherd (n=codeshep@bb121-7-80-240.singnet.com.sg) |
22:21.04 | fallacy | jasonb: I tried out that http proxy servlet you showed me yesterday, didn't work very well since it doesn't replicate the response headers from the server being proxied to |
22:21.21 | fallacy | jasonb: know of any good http proxy servlets I could try by any chance? |
22:22.14 | jasonb | fallacy: Well, that's interesting. |
22:22.32 | jasonb | fallacy: I have more of them, but you probably won't like any of the others. I'll give you the links anyway.. |
22:22.58 | jasonb | http://frank.spieleck.de/servlets.jsp |
22:23.21 | jasonb | http://frank.spieleck.de/download/ProxyServlet.java |
22:23.37 | jasonb | It does not perform as well, and you'd need to modify the source a bit to get it to work, I'm sure. |
22:24.06 | jasonb | I was able to get it working, but eventually decided it wasn't worth putting my time into because it did not perform well enough. |
22:24.14 | jasonb | (for what I was wanting it for) |
22:24.28 | jasonb | But, it's an example of servlet source code. |
22:25.08 | jasonb | I think that's basically all I have. Everything else I found was so junky that it made these other two look great. :) |
22:25.50 | jasonb | Just so you know, it is high on my todo list to implement something for Tomcat that does a good job of request proxying. |
22:26.03 | jasonb | It would sure be nice if something like that was just part of Tomcat. |
22:26.31 | fallacy | yeah, its surprising that a mature one isn't available |
22:26.55 | fallacy | I also saw this: http://noodle.tigris.org/ |
22:30.42 | jasonb | That one is bad. |
22:30.54 | jasonb | It is very old and slow, and is unbuildable from source. |
22:31.12 | jasonb | (I have experience with it) |
22:33.18 | fallacy | ah |
22:34.59 | fallacy | looks like I'm SOL |
22:35.22 | jasonb | Well, you could modify the frank spieleck one. |
22:37.05 | fallacy | yeah, thats probably what I'll end up doing |
22:37.16 | jasonb | It's at least some source code to start with. :) |
22:37.30 | *** join/#tomcat evosh (n=jixjax@user-1121072.dsl.mindspring.com) |
22:37.33 | jasonb | Another idea: use commons-httpclient and write your own servlet that uses it. |
22:37.52 | jasonb | (that's not a wonderful option either, though) |
22:38.02 | fallacy | yeah :) |
22:38.58 | fallacy | it seems like a simple problem though |
22:42.08 | jasonb | Well, it's a commonly needed feature, I believe. It's also a commonly implemented thing.. an HTTP client, mainly. But, there are so many ways one can implement it, and each one must handle a myriad of failure cases. Plus, the features people need vary greatly. |
22:42.32 | jasonb | It would need to be very configurable. And, people would want it to perform really well. |
22:46.58 | evosh | Pfft! People and their needs... |
22:47.21 | evosh | For some reason my connection has been abysmal for the last 48 hours. |
22:48.05 | fallacy | jasonb: what configuration would be nice besides specifying the local mapping and the actual destination host to proxy the requests to? |
22:49.03 | fallacy | tough part is just managing a connection pool to the destination host |
22:52.16 | jasonb | fallacy: Many people would want to filter the response to replace some strings.. like to remap URLs to their own host instead of the destination host.. the features of mod_proxy_html are quite handy. |
22:52.51 | jasonb | fallacy: Also, others might want to be able to configure whether the headers must be proxied, whether there should be a thread pool at all, and other http client connection settings. |
22:53.25 | jasonb | fallacy: Also, request header filtering/munging. |
22:54.08 | jasonb | fallacy: Have a look at the Apache 2.x mod_proxy documentation pages and you'll see lots of config options. :) |
22:56.28 | fallacy | I see |
22:59.12 | jasonb | It's easy to write one that has few features, but it will be deemed unusable by a large number of users. |
23:03.05 | fallacy | yeah, like my situation now :) |
23:03.07 | fallacy | you're right |
23:14.22 | jasonb | s/number/percent/ |
23:18.03 | fallacy | im going to whip one up for me to use using commons-httpclient |
23:20.57 | jasonb | It should work well enough. But, don't expect lots of performance out of it. |
23:43.45 | *** join/#tomcat fzlogik (n=fuzelogi@extern-halls-hg-25.soton.ac.uk) |