RE: mod_webapp, mod_jk etc.
Forgot to ask, would you be interested in instructions/simple shell script for building mod_jk as a statically linked Apache module? Yes, certainly. Instruction and better shell script :) But did mod_jk is really faster in statically mode rather in DSO ? Bojan Dan Milstein wrote: I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
RE: mod_webapp, mod_jk etc.
mod_jk should be compiled statically in Apache but nobody asked for that feature previously since mod_jk as still not the maturity of other well known modules like mod_index. A feature which may be added to mod_jk, but I'd like to see before autoconf stuff added :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 10:32 AM To: [EMAIL PROTECTED] Subject: Re: mod_webapp, mod_jk etc. Forgot to ask, would you be interested in instructions/simple shell script for building mod_jk as a statically linked Apache module? Bojan Dan Milstein wrote: I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: mod_webapp, mod_jk etc.
Forgot to ask, would you be interested in instructions/simple shell script for building mod_jk as a statically linked Apache module? Bojan Dan Milstein wrote: I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: mod_webapp, mod_jk etc.
I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: mod_webapp, mod_jk etc.
Beauty. I'm actually playing with 3.3 as well, because some of the features I like (eg. realm per host) are there as well. Bojan Dan Milstein wrote: I can't speak to mod_webapp, but a mod_jk response: - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; This was just added to the 3.3 branch (by Henri) for mod_jk -- if the Apache plugin detects a dead connection, it opens a new one (so you don't have to restart Apache when you restart Tomcat). Needs testing, but it's in there. -Dan -- Dan Milstein // [EMAIL PROTECTED]
mod_webapp, mod_jk etc.
I've posted a few messages about this to Tomcat User list, but since this is really development related, I'm posting this one here. Basically, mod_webapp packaged with Tomcat 4.0 b2 and b3 doesn't compile, so I switched back to the version from b1. I've noticed a few things: - I'm confused as to why mod_webapp (and mod_jk) aren't designed to be statically linked with Apache; after all this is a supported configuration of Apache, runs faster and it has a smaller memory footprint; I know that mod_jk works nicely when statically linked, I use it in my production environment; most other modules support this, including really big ones like mod_ssl, mod_php, mod_perl etc. - mod_webapp from T4b1 doesn't survive the second round of initialisation on Unix because it reports duplicate WebAppConnection entries (at least when statically linked, not sure if that affects the dynamically linked version); this can be easily fixed by using tricks from mod_ssl, where they use ap_global_ctx to store status of initialisation and check on it later - although I'm not Apache API proficient I think I could write that kind of code by stealing from mod_ssl when pushed in the right direction by developers of mod_webapp - even after changing the code of mod_webapp to survive the second round of initialisation (by removing the duplicate check of WebAppConnection and WebAppMount), it still fails when being used with error 'Cannot switch to passive mode'; part of the requested page appears but then there is the stack trace due to some null pointers in Catalina, probaly related to the fact that mod_webapp just died - I understand the need for the TCP connections to be persistent in mod_jk and mod_webapp, but I'm not sure why another connection wouldn't be attempted after the reuse of the previous connection fails; in production environments it is sometimes handy to restart Tomcat only, without touching Apache; also, if Tomcat dies and gets automatically restarted, the connections would still go through from Apache; Apache with mod_ssl might need a password at startup and automatic restart of it might not be possible; how difficult would it be to have functionality like that in mod_webapp/mod_jk? - once again, if I'm pushed in the right direction... As you're all aware, every developer is scratching his/hers own personal itch. Nothing new here. I just kind of like Catalina's features and I would really like it to work behind Apache... Bojan
Re: mod_webapp / mod_jk
Another point of mod_jk is for Dan and about the question of security and or ligth crypto support. ajp12/ajp13 didn't support ACL to accept/deny connections from a list of known host, and the protocol is in clear text. Costin suggest using SSH tunnels which be a fast work-around but I really like to have this ACL+CRYPTO included in mod_jk/ajp13. I agree that some form of authentication (and possibly encryption) are high-priority things to add to mod_jk / ajp13. Before I dive into that work, though, I want to be sure that there is a future for the code -- that's why I'm proposing using it in TC 4 as well as TC 3. In some previous discussions about extending ajp13, there had been hope that it could be done fairly easily, since there are typed packets, so new packet types could be added without breaking the protocol. Unfortunately, I don't think that's going to work -- the current code does read packet types, but if it sees an unknown packet type, it closes the connection down. This makes it impossible to send packets in an exploratory manner. Fortunately, the ACL's should be implementable without touching the packet types (I think you suggested this, Henri). We can just add a list of safe hosts to the configuration directives for TC, and it will only allow connections if they come from the specified hosts. I think this would still leave us open to IP address spoofing, but it would certainly be an improvement over what we've got now. For encryption, we would have to introduce new packet types. Personally, my feeling is that encryption of the stream between the Web Server and TC is much less important than authenticating connections. Especially given that SSH tunnels are not that hard to set up, I am reluctant to add the complexity of crypto code to ajp13. Finally, going ahead. I think it would be a good idea to introduce ajp14 (once the bulk of the work above has been completed). I would propose it as a slight variant on ajp13. Basically, the same protocol, with a few new packet types (we need something to handle 8K of header information), *and* with provision for handling unknown packet types more intelligently. I think this would give us a protocol which we could live with more easily over time. We could add new features, but it could still communicate with old web server plugin versions. -Dan -- Dan Milstein // [EMAIL PROTECTED]
RE: mod_webapp / mod_jk
I agree that some form of authentication (and possibly encryption) are high-priority things to add to mod_jk / ajp13. Before I dive into that work, though, I want to be sure that there is a future for the code -- that's why I'm proposing using it in TC 4 as well as TC 3. Fortunately, the ACL's should be implementable without touching the packet types (I think you suggested this, Henri). We can just add a list of safe hosts to the configuration directives for TC, and it will only allow connections if they come from the specified hosts. I think this would still leave us open to IP address spoofing, but it would certainly be an improvement over what we've got now. Yes something before the packet decoding. Like the host.allow/host.deny found on Linux Boxes. For encryption, we would have to introduce new packet types. Personally, my feeling is that encryption of the stream between the Web Server and TC is much less important than authenticating connections. Especially given that SSH tunnels are not that hard to set up, I am reluctant to add the complexity of crypto code to ajp13. May be we could find a not so hog crypto code. Finally, going ahead. I think it would be a good idea to introduce ajp14 (once the bulk of the work above has been completed). I would propose it as a slight variant on ajp13. Basically, the same protocol, with a few new packet types (we need something to handle 8K of header information), *and* with provision for handling unknown packet types more intelligently. I think this would give us a protocol which we could live with more easily over time. We could add new features, but it could still communicate with old web server plugin versions. +1 Only keep ajp13 for backward compatibily ?
RE: mod_webapp / mod_jk
I've builded the mod_webapp module and it fail when session are in use. May be related to cookies support. I could tell you more later after some capture with ethereal. Finally, someone actually trying it so we can fix the bugs :-) I'll try to fix whatever I can but we need a little more documentation on mod_webapp. I wonder if mod_webapp will support Load Balancing and Fault Tolerance. It's not clear in Directives. I've asked Pier to document what he has described to me informally as goals for the mod_webapp design, but this is definitely on the list of desireable things to support. Of course, getting the basic stuff working right first is important. Yep, but mod_jserv (and now mod_jk) ability to support fault/balancing was a big +1000 in my the decision using ApacheJServ 1.x and then to switch to Tomcat later. Did mod_webapp will support ACL/CRYPTO ? Even if crypto is not easily exportable even mod_ssl is such relaxed now that it could be used in Redhat Distributions (6.2/7.0) The code inside mod_webapp is layered, with precisely this type of use in mind. Nice to see that. I'll take more time to study mod_webapp. May be at some point it could reach Dan and Costin works on ajp13/14 evolutions. I'll try to make the ACL code for ajpxx portable to mod_webapp.
mod_webapp / mod_jk
Pier, I wanted to ask you some questions about mod_webapp, and how you might see it working with mod_jk. I seem to have become the default ajp13 / mod_jk expert, and people have been asking for various extensions. I'm reluctant to invest much work in mod_jk/ajp13, given that TC 4.0 is using mod_webapp. However, what would seem to make sense to me would be the following course of action: - Write connectors for TC 4.0 which talk ajp13, the mod_jk JNI protocol, and possibly ajp12. I would be very interested in doing this work. I believe it wouldn't take me very long, given that I could adapt the current 3.3 code wholesale (much of which I understand in detail). Then, TC 4.0 would suddenly be able to talk to all the web servers which mod_jk talks to: Apache 1.3, Apache 2.0, Netscape, IIS, AOLServer. This would be a huge win, and would (I believe) dramatically accelerate the adoption of TC 4. It would also provide a very smooth upgrade path to current users. The only disadvantage would be that we wouldn't see any of the advantages of mod_webapp. I've never seen a design doc for webapp, but my understanding is that one of its big advantages is that it will directly read the web.xml (and server.xml) files, which will greatly ease the configuration process. Could you possibly summarize some of its other features? The reason I ask is that I think the mod_jk C code (the various modules which plug into the web servers), is actually extremely well-written and flexible. It's totally undocumented, but, if necessary, I'd be willing to remedy that (I don't mind writing documentation). One of the best things about that C code is that it allows many different web servers to talk to many different protocols in a very clean way. So I wonder if it would be possible to make it to also talk whatever protocol you're developing as part of mod_webapp. This would mean basically merging mod_webapp into mod_jk (or merging mod_jk into mod_webapp, depending on your perspective ;-). What do you think of this course of action? I'm hoping that you and I can align our efforts so that we can take as much advantage of each other's work as possible. -Dan -- Dan Milstein // [EMAIL PROTECTED]
