RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. MT. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] JK and load-balanced POSTs
Joel Dice wrote: Attached is a patch against JK 1.2.5 to fix handling of POSTs for load-balanced workers. The problem it addresses occurs when an endpoint fails while mod_jk is trying to send it a POST request. When mod_jk gives up and attempts to use a different endpoint, the body of the POST is lost. Since the POST is not part of the new endpoint's state, mod_jk tries to re-read the data from the client, but the client has nothing more to say, so the read returns zero bytes. This empty post is sent on to the application server, confusing it. The patch fixes this problem by attaching the POST data to the request state (of type jk_ws_service_t) instead of the endpoint state (of type ajp_endpoint_t). Feedback is welcome. Hum it seems interesting... I'll study this one.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. Good resume Mladen. Many nice things was discussed on this thread : - adding load-balancing/fault-tolerant support for mod_proxy. A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users. So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty). - adding ajp_proxy support to mod_proxy. With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :) In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself. - creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind. - our actual lb/ft support (which should be more simple or better documented). - at a later time, dynamic topology (tomcat clusters state changes, application state in each tomcat, update of tomcat load level...) I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project. Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers. So what should we do now ? - An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2. - int ajp_open_connection(ajp_connection_t **, char *, apr_port_t) - int ajp_close_connection(ajp_connection_t *) - int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *); - int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *) All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers), apr_pool_t... Next advanced AJP functions will forward a complete Apache 2 request to a tomcat. Many objects part of the Ap2 request are allready available in the Basic AJP functions, ie for headers the apr_table_entry_t... We could then work on a mod_ajp prototype, using only env var for example, to redirect a request to the correct named ajp instance (don't speak about worker). With such simple prototype we could see which hooks should be implemented, probably only ap_hook_handler/ap_hook_post_config. Actually jk 1.2.x may implements too many hooks, I didn't see any Apache 2 modules with all of these : ap_hook_handler(jk_handler,NULL,NULL,APR_HOOK_MIDDLE);
Re: [PATCH] JK and load-balanced POSTs
Joel Dice wrote: Attached is a patch against JK 1.2.5 to fix handling of POSTs for load-balanced workers. The problem it addresses occurs when an endpoint fails while mod_jk is trying to send it a POST request. When mod_jk gives up and attempts to use a different endpoint, the body of the POST is lost. Since the POST is not part of the new endpoint's state, mod_jk tries to re-read the data from the client, but the client has nothing more to say, so the read returns zero bytes. This empty post is sent on to the application server, confusing it. The patch fixes this problem by attaching the POST data to the request state (of type jk_ws_service_t) instead of the endpoint state (of type ajp_endpoint_t). Feedback is welcome. Well in jk 1.2.6-dev it was fixed and there is repost data in service area. Thanks to check if it works for you with the latest jk in CVS... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] JK and load-balanced POSTs
Henri Gomez wrote: Thanks to check if it works for you with the latest jk in CVS... ... and I think we expect the new 1.2.6 release soon. So either wait for the new release - or even better: send feedback on the CVS as soon as possible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.6 release - any showstopper ?
Fix the latest Bill fix on lb cookies it seems there is nothing which prevent us from releasing jk 1.2.6. So if nobody reports a show stopper today, I'll start the jk 1.2.6 release tomorrow morning CET. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Make sense of course. And if proxy_loadbalance and proxy_sticky are somewhat configurable, it will be to the benefits all of Apache 2 users, dependless HTTP/FTP/AJP. BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? That would be up to proxy_ajp to decide, so yes. What happens is that when the config says ProxyPass /myApp ajp://VIRTUALNAME and the user requests the URL /myApp/index.jsp, proxy will give proxy_ajp an URL that looks like this: ajp://VIRTUALNAME/index.jsp It's up to proxy_ajp to understand what that means. Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. Proxy already loops around and tries again on connection failure to a different server in the backend. If proxy cannot handle a 503 or a 400, then it can be made to handle it - again it's a feature that would be really useful regardless of the protocol. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. I see in ap_proxy_http_handler() that DECLINED allows to try another. Is there somewhere an example of a configuration using it? The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. I don't follow - what does normalisation would lead to nowhere mean? HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. You are missing the purpose of mod_proxy. It is not an HTTP proxy only, but a general protocol proxy that can support both stateless and stateful backends. Proxy supports HTTP keepalives (via a mechanism that can be extended into a full pool), and it supports FTP (a stateful protocol). There is no reason why proxy could not support another stateful protocol like AJP. If httpd is to support another backend protocol, then the proxy frameowrk is the place to do it. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? Considering that httpd already has a framework to connect to various backend protocols (proxy and friends), and already has an established syntax within httpd, I don't see any point in replacing it with another external module like the existing mod_jk2. Are you willing to write the ftp module for mod_jk2? Again, application server != http server. Of course an http server is an application server. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. I think there is a fundamental misunderstanding as to the way proxy works. mod_proxy is a framework - the module is not useful on it's own without helper modules plugged into the back of it. Right now, there are helper modules to support HTTP/1.1, FTP and HTTP/1.1's CONNECT method. mod_proxy currently handles the connection to the backend, it then passes this connection to the protocol handler module for completion. This connection handling can easily be pulled out into a load balancing module, allowing connections to the backend to be reused for HTTP keepalives, FTP session continuation and a connection pool for AJP, or a proxy_sticky module, that is able to ensure the same requests go to the same server. The bottom line is that httpd has an established framework for supporting backend application server protocols like HTTP, FTP, and now AJP. So far I have seen no technical justification whatsoever for putting an AJP protocol module outside of this framework. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: I see in ap_proxy_http_handler() that DECLINED allows to try another. Is there somewhere an example of a configuration using it? ap_proxy_http_handler() is found in mod_proxy_http, which is the helper module that handles the HTTP protocol in the proxy framework. You will find a corresponding ap_proxy_ftp_handler() inside mod_proxy_ftp. mod_proxy tries each handler in turn until one of the handlers says I can serve this URL, I'll take it. ap_proxy_http_handler() will return DECLINED if the URL of the backend is not http: or https:, allowing mod_proxy_ftp, mod_proxy_connect or a potential mod_proxy_ajp to have a go at trying serve the URL. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. We already have a bunch of modules that can use WTF protocol you wish, but no one can configure or use it without reading 500 page book that doesn't even exists. - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done I'm sure it can, but like I said, you can mimic the mod_proxy inside jk2. It also can be done :) MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? Because the container already gives you an established configuration method, a standard set of documentation, and a standard expectation from end users on how it should work. Remember the end goal of the exercise is to produce software which solves a real world need of end users. One of the biggest real world end user needs is something simple and straightforward that lets me get the job done with the least amount of time wasted messing around. As a user, I would ask why is the config for mod_jk different for mod_proxy?, and in fact as a user that's the exact reason I don't bother to use mod_jk. The easiest way to make the config method for mod_proxy and mod_jk the same is to implement proxy_ajp. There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. Compromises like what? I see no reason why every single feature of mod_jk cannot be implemented in a proxy_ajp, or with the assitance of other potential modules with general application like proxy_loadbalancer. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. This is the precise goal of the proxy framework. mod_proxy_http communicates with an HTTP server, nothing less, nothing more. It doesn't cache, it doesn't do anything - that's the job of other httpd modules like mod_dir, mod_cache, etc. mod_proxy_ftp communicates with an FTP server, nothing less, nothing more. mod_proxy_ajp would communicate via AJP. Nothing less, nothing more. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: So, my question is. Why do we need again some container to accomplish that? Because the container already gives you an established configuration method, a standard set of documentation, and a standard expectation from end users on how it should work. That's all OK. Look at the mail archive and you will see that this is exactly the 'look and feel' that we wish to achieve. Compromises like what? AjpWorker and AjpBalancer for example, or do we need to mimic that inside the existing configuration directives? Well the, AjpWorker can be mapped to ProxyRemote if you change it to ProxyRemote. See my point? There is also a lot of extra params that we'll need to set for each particular worker or Remote. If you are will to support something like that, then we can speak on. I see no reason why every single feature of mod_jk cannot be implemented in a proxy_ajp, or with the assitance of other potential modules with general application like proxy_loadbalancer. Me neither. I really see no reason for that, except that we don't have neither proxy_ajp nor proxy_loadbalancer. I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. This is the precise goal of the proxy framework. Look, if others on the tomcat-dev are willing to write the proxy_ajp and proxy_loadbalancer, then OK. After all, I'm Borg, I will adapt :). I personally don't like the idea, and still think that we should first make something workable outside the Apache2 tree, at least for the reason to be able to make a release without waiting for the rest of the guys. Would it be possible to copy the entire mod_proxy inside j-t-c tree and then later merge it with the httpd tree when we reach some version 1.0? Regards, MT. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] JK and load-balanced POSTs
Thanks for the information, Henri and Rainer. I'll try the CVS version today. On Wed, 21 Jul 2004, Rainer Jung wrote: Henri Gomez wrote: Thanks to check if it works for you with the latest jk in CVS... ... and I think we expect the new 1.2.6 release soon. So either wait for the new release - or even better: send feedback on the CVS as soon as possible. - 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: Invitation to HTTPD commiters in tomcat-dev
One thing missing - the proposal to actually just use mod_proxy, with enhancements for load balancing, and with http as protocol ( i.e. drop Ajp ). That would be a real simplification on both sides ! The tiny performance benefit of a binary protocol is really not worth it. The 'http parsing' part is very small anyway. Most other problems can be solved with mod_proxy - including passing all auth headers and informations about original request in special headers, load balancing with all the flavors, etc. ( and security issues with the custom headers can be resolved as well ). I agree with Mladen that plugable protocol proved to be unnecesary, and it would be a bad idea for mod_proxy. Costin Henri Gomez wrote: Mladen Turk wrote: Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. Good resume Mladen. Many nice things was discussed on this thread : - adding load-balancing/fault-tolerant support for mod_proxy. A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users. So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty). - adding ajp_proxy support to mod_proxy. With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :) In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself. - creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind. - our actual lb/ft support (which should be more simple or better documented). - at a later time, dynamic topology (tomcat clusters state changes, application state in each tomcat, update of tomcat load level...) I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project. Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers. So what should we do now ? - An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2. - int ajp_open_connection(ajp_connection_t **, char *, apr_port_t) - int ajp_close_connection(ajp_connection_t *) - int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *); - int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *) All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers),
Re: Invitation to HTTPD commiters in tomcat-dev
- Original Message - From: Mladen Turk [EMAIL PROTECTED] I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). yes, but it is rocket science to actually get jk2 compiled and configured and to work properly. mod_proxy is part of the core, and takes about 5 seconds to setup. That is the biggest difference the current user base is experiencing today. I've been on three commercial projects where mod_jk2 has been dropped and replaced with mod_proxy, (and not on my recommendation). That alone speaks for itself. If the successor of jk2 can be as easy to configure and setup with apache, then go for it. Otherwise I humble suggestion would be to start looking that direction. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: AjpWorker and AjpBalancer for example, or do we need to mimic that inside the existing configuration directives? Well the, AjpWorker can be mapped to ProxyRemote if you change it to ProxyRemote. See my point? AjpBalancer could be applied to a theoretical proxy_balancer module (all modules can define their own config parameters, even the helper modules, the only guideline is that the config directives are named to give some indication of the scope they're valid for, so instead of a directive called Fred which doesn't mean anything to anybody, it should be ProxyAjpFred). What does AjpWorker do? (Is there docs for mod_jk anywhere, when I last looked I could not find any). There is also a lot of extra params that we'll need to set for each particular worker or Remote. If you are will to support something like that, then we can speak on. Quite willing - the extra params can be defined as valid for the proxy_ajp module only, or extra general parameters can be added to the proxy framework. The idea is that if some feature has general application to all the modules (such as load balancing) then the change should be made to proxy and be applied system wide. Me neither. I really see no reason for that, except that we don't have neither proxy_ajp nor proxy_loadbalancer. I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). Because of end user expectation. mod_proxy is currently the shipped with Apache option for backend protocol support. If suddenly mod_proxy and friends were turfed out and replaced with an entirely different module and different set of directives, people's reaction would be huh?. Look, if others on the tomcat-dev are willing to write the proxy_ajp and proxy_loadbalancer, then OK. After all, I'm Borg, I will adapt :). I personally don't like the idea, and still think that we should first make something workable outside the Apache2 tree, at least for the reason to be able to make a release without waiting for the rest of the guys. Would it be possible to copy the entire mod_proxy inside j-t-c tree and then later merge it with the httpd tree when we reach some version 1.0? You could do that - although if you make changes to mod_proxy itself (which you very likely will have to do to support some of the stuff, like the adding of new hooks, etc) it would be best if these were posted as they happened to the [EMAIL PROTECTED] list, then they could be applied to httpd v2.1-dev, with potential backports going to v2.0. Doing this in bite sized pieces as needed would be a lot easier to review than a single big merge at the end, although keeping a local copy for yourselves to try things out first will also make your lives easier. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Installation Problem
Good day, I am using IBServer on a Windows 2000 Box. Installed is apache 1.3.26, PHP 4.2 and I am trying to get Tomcat to work. Tomcat runs as a Windows Service with no errors. Apache runs fine with the jk_mod installed. My httpd.conf is listening for ports 80, 8080 and 8009 for processing JSP. The problem is I can never get JSP files on localhost or IP assigned for the server to run on outside the network. I keep getting prompted to save the JSP source in IE. I have set up 5 VirtualHosts for webspace off the server plus the main space and I am using just IP addresses. My goal is to have all 6 IP's able to server JSP or PHP. Listed below is the httpd.conf (with approprate IP's removed and such) ALso listed is the mod_jk.conf file. Thank you in advance for the help. Phil --- httpd.conf # # Based upon the NCSA server configuration files originally by Rob McCool. # # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See URL:http://www.apache.org/docs/ for detailed information about # the directives. # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # # After this file is processed, the server will look for and process # D:/IBserver/Apache/conf/srm.conf and then D:/IBserver/Apache/conf/access.conf # unless you have overridden these with ResourceConfig and/or # AccessConfig directives here. # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server process as a # whole (the 'global environment'). # 2. Directives that define the parameters of the 'main' or 'default' server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. # 3. Settings for virtual hosts, which allow Web requests to be sent to # different IP addresses or hostnames and have them handled by the # same Apache server process. # # Configuration and logfile names: If the filenames you specify for many # of the server's control files begin with / (or drive:/ for Win32), the # server will use that explicit path. If the filenames do *not* begin # with /, the value of ServerRoot is prepended -- so logs/foo.log # with ServerRoot set to /usr/local/apache will be interpreted by the # server as /usr/local/apache/logs/foo.log. # # NOTE: Where filenames are specified, you must use forward slashes # instead of backslashes (e.g., c:/apache instead of c:\apache). # If a drive letter is omitted, the drive on which Apache.exe is located # will be used by default. It is recommended that you always supply # an explicit drive letter in absolute paths, however, to avoid # confusion. # ### Section 1: Global Environment # # The directives in this section affect the overall operation of Apache, # such as the number of concurrent requests it can handle or where it # can find its configuration files. # # # ServerType is either inetd, or standalone. Inetd mode is only supported on # Unix platforms. # ServerType standalone # # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # ServerRoot D:/IBserver/Apache # # PidFile: The file in which the server should record its process # identification number when it starts. # PidFile logs/httpd.pid # # ScoreBoardFile: File used to store internal server process information. # Not all architectures require this. But if yours does (you'll know because # this file will be created when you run Apache) then you *must* ensure that # no two invocations of Apache share the same scoreboard file. # ScoreBoardFile logs/apache_runtime_status # # In the standard configuration, the server will process httpd.conf (this # file, specified by the -f command line option), srm.conf, and access.conf # in that order. The latter two files are now distributed empty, as it is # recommended that all directives be kept in a single file for simplicity. # The commented-out values below are the built-in defaults. You can have the # server ignore these files altogether by using /dev/null (for Unix) or # nul (for Win32) for the arguments to the directives. # #ResourceConfig conf/srm.conf #AccessConfig conf/access.conf # # Timeout: The number of seconds before receives and sends time out. # Timeout 300 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to Off to deactivate. # KeepAlive On # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: One thing missing - the proposal to actually just use mod_proxy, with enhancements for load balancing, and with http as protocol ( i.e. drop Ajp ). That would be a real simplification on both sides ! I also find HTTP to be more than adequate in most cases, but if there is a need for AJP and people are going to use it then I don't see why people can't build and contribute to an ajp module. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] JK and load-balanced POSTs
It looks like the CVS version works. Next time I'll try CVS before trying to fix a problem myself. :) Looking forward to 1.2.6! On Wed, 21 Jul 2004, Rainer Jung wrote: Henri Gomez wrote: Thanks to check if it works for you with the latest jk in CVS... ... and I think we expect the new 1.2.6 release soon. So either wait for the new release - or even better: send feedback on the CVS as soon as possible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Catrina Ring/Annons/Dagens Nyheter/SE är inte på kontoret.
Jag kommer att vara borta från kontoret fr.o.m. 2004-07-12 och kommer inte tillbaka förrän 2004-08-02. Jag kommer att svara på meddelandet när jag kommer tillbaka efter min semester den 24/7. Ha en trevlig sommar med mycket sol ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? I have tried the following in httpd.conf: +++ Location /examples/ ProxyPass http://pgtr0327.mch.fsc.net:8080/examples/ ProxyPassReverse http://pgtr0327.mch.fsc.net:8080/examples/ /Location +++ pgtr0327.mch.fsc.net:8080 is a normal tomcat and something so simple covers already some needs. Adding load balancing means that we have to define several Tomcats (only changing host and/or port) and use JSESSIONID to find the right Tomcat when getting a request in httpd. This could be done in a modified proxy_http.c Cheers Jean-Frederic - 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: Invitation to HTTPD commiters in tomcat-dev
But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info yes, this is what alot of users want Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:27 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - 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]
Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
ok, there are two very simple memory friendly ways to do sticky load balancing. And as a matter of fact, this is how some hardware loadbalancers do it. 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Filip - Original Message - From: Graham Leggett [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:34 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28875] - Multi-byte characters in default error page aren't printed out correctly.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28875. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28875 Multi-byte characters in default error page aren't printed out correctly. --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 16:19 --- I haven't been looking into this problem much and maybe I'm wrong somewhat. Regarding the latest patch, I'm wondering if there is any reason to drop setLocale() from that portion. Invocation of either setCharacterEncoding() or setContentType() that precedes setLocale() seems to prevent setLocale() from changing the character encoding for the request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? There is also a question of development cycle. Are we gonna develop sending patches or what... Suggestions? MT. smime.p7s Description: S/MIME cryptographic signature
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance load factor, not just sticky sessions and simple round robin. Also the JSESSIONID then does not to be harcoded, but rather configurable. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
I didn't say anything about just simple round robin the algorithm for distribution can be entirely separate from the stickiness as they are two separate things. The distribution algorithm, (round robin, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one server, I should go to that server again and again until that server fails or meets another criteria to not receive requests. Filip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 11:30 AM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Filip Hanik wrote: The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure. Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance load factor, not just sticky sessions and simple round robin. Also the JSESSIONID then does not to be harcoded, but rather configurable. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: I didn't say anything about just simple round robin the algorithm for distribution can be entirely separate from the stickiness as they are two separate things. The distribution algorithm, (round robin, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one server, I should go to that server again and again until that server fails or meets another criteria to not receive requests. Ok, just wanted to clear if we are going to make another compromise :), since sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Ok, just wanted to clear if we are going to make another compromise :), since sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. In theory sticky sessions shouldn't be tightly coupled like this - it should be a case of plan a) stick to the same server, else revert to plan b). In this case plan B could be simple DNS round robin, or it could be a load balancer, in other words another module entirely. This raises a question - what order do the modules run in? In theory the sticky module should run last, in other words a load balancer (or DNS round robin, or whatever) orders the IPs based on some criteria (load, or round robin, or whatever), and then the sticky module takes the sticky server identified by the cookie/parameter and moves that sticky IP on top of the list. I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: GL Mladen Turk wrote: Ok, just wanted to clear if we are going to make another compromise :), since sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. GL In theory sticky sessions shouldn't be tightly coupled like this - it GL should be a case of plan a) stick to the same server, else revert to GL plan b). GL In this case plan B could be simple DNS round robin, or it could be a GL load balancer, in other words another module entirely. GL This raises a question - what order do the modules run in? In theory the GL sticky module should run last, in other words a load balancer (or DNS GL round robin, or whatever) orders the IPs based on some criteria (load, GL or round robin, or whatever), and then the sticky module takes the GL sticky server identified by the cookie/parameter and moves that sticky GL IP on top of the list. GL I suppose in this case the load balancer would run HOOK_MIDDLE, and GL sticky would run HOOK_LAST. GL Regards, GL Graham GL -- -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-tomcat-catalina/jakarta-tomcat-catalina success
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-catalina contains errors. Project State : 'Success' Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [naming-resources.jar] identifier set to jar basename: [naming-resources] -DEBUG- Jar [servlets-default.jar] identifier set to jar basename: [servlets-default] -DEBUG- Jar [naming-common.jar] identifier set to jar basename: [naming-common] -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina] -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap] -DEBUG- Jar [servlets-common.jar] identifier set to jar basename: [servlets-common] -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker] -ERROR- Unhandled Property: tomcat33.home on: gump.model.builder.Ant instance at 0x40dcba8c -DEBUG- Dependency on javamail exists, no need to add for property mail.jar. -DEBUG- Dependency on jaf exists, no need to add for property activation.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xml-apis.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.home. -DEBUG- Dependency on jmx exists, no need to add for property jmxtools.jar. -DEBUG- Dependency on jndi exists, no need to add for property jndi.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -DEBUG- Dependency on javamail exists, no need to add for property mail.home. -DEBUG- Dependency on jaf exists, no need to add for property activation.home. -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/gump_work/build_jakarta-tomcat-catalina_jakarta-tomcat-catalina.html Work Name: build_jakarta-tomcat-catalina_jakarta-tomcat-catalina (Type: Build) State: Success Elapsed: 21 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Djtc.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors -Dmail.home=/usr/local/gump/packages/javamail-1.3 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040721.jar -Dcatalina.deploy=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build -Dxml-apis.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar -DxercesImpl.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar -Djsse.home=/usr/local/gump/packages/jsse1.0.3 -Djaas.jar=/usr/local/gump/packages/jaas1_0/lib/jaas.jar -Dcatalina.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build -Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-20040721.jar -Dmail.jar=/usr/local/gump/packages/javamail-1.3/mail.jar -Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar -Djndi.jar=/usr/local/gump/packages/jndi1_2_1/lib/jndi.jar
Re: [GUMP@brutus]: jakarta-tomcat-catalina/jakarta-tomcat-catalina success
/commons-beanutils-core.jar bao -Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20040721.jar bao -Dcommons-modeler.jar=/usr/local/gump/public/workspace/jakarta-commons/modeler/dist/commons-modeler-20040721.jar bao -Djasper.home=/usr/local/gump/public/workspace/jakarta-tomcat-jasper_tc5/jasper2 bao -Djndi.home=/usr/local/gump/packages/jndi1_2_1 bao -Dtomcat-coyote.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote bao -Dcommons-dbcp.jar=/usr/local/gump/public/workspace/jakarta-commons/dbcp/dist/commons-dbcp.jar bao -Dtomcat-util.jar=/usr/local/gump/public/workspace/jakarta-tomcat-connect[Working bao Directory: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina] bao CLASSPATH : bao /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/jaf-1.0.1/activation.jar:/usr/local/gump/packages/javamail-1.3/mail.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxtools.jar:/usr/local/gump/packages/jsse1.0.3/lib/jcert.jar:/usr/local/gump/packages/jsse1.0.3/lib/jnet.jar:/usr/local/gump/packages/jsse1.0.3/lib/jsse.jar:/usr/local/gump/public/workspace/jakarta-to! mcat-conn bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/balancer/WEB-INF bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/balancer/WEB-INF/classes bao build-static: bao [copy] Copying 20 files to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/balancer bao build-main: bao [javac] Compiling 14 source files to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/balancer/WEB-INF/classes bao [javac] This version of java does not support the bao classic compiler; upgrading to modern bao dist-prepare: bao dist: bao [jar] Building jar: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/dist/balancer.war bao webdav: bao build-prepare: bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/webdav bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/webdav/WEB-INF bao build-static: bao [copy] Copying 4 files to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/build/webdav bao build-main: bao dist-prepare: bao dist: bao [jar] Building jar: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/webapps/dist/webdav.war bao build: bao dist: bao deploy: bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/webapps bao [copy] Copying 189 files to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/webapps bao [copy] Copied 36 empty directories to 1 empty bao directory under bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/webapps bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/webapps bao [copy] Copying 1 file to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/webapps bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/webapps/admin bao [copy] Copying 120 files to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/webapps/admin bao [copy] Copied 29 empty directories to 11 empty bao directories under bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/webapps/admin bao [copy] Copying 1 file to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/webapps bao [mkdir] Created dir: bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/webapps/manager bao [copy] Copying 31 files to bao /usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/webapps/manager bao BUILD SUCCESSFUL bao Total time: 20 seconds bao - bao To subscribe to this information via syndicated feeds: bao RSS: bao http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/rss.xml bao Atom: bao http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/atom.xml bao -- bao Gump E-mail Identifier (within run) #36. bao Produced by Gump 2.1.0-alpha-0002. bao [Run (20040721 08
[GUMP@brutus]: jakarta-tomcat-5/jakarta-tomcat-5 success
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-5 contains errors. Project State : 'Success' Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [naming-resources.jar] identifier set to jar basename: [naming-resources] -DEBUG- Jar [servlets-default.jar] identifier set to jar basename: [servlets-default] -DEBUG- Jar [naming-common.jar] identifier set to jar basename: [naming-common] -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina] -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap] -DEBUG- Jar [servlets-common.jar] identifier set to jar basename: [servlets-common] -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker] -ERROR- Unhandled Property: tomcat33.home on: gump.model.builder.Ant instance at 0x40fb648c -DEBUG- Dependency on javamail exists, no need to add for property mail.jar. -DEBUG- Dependency on jaf exists, no need to add for property activation.jar. -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xml-apis.jar. -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -DEBUG- Dependency on commons-el exists, no need to add for property commons-el.jar. -DEBUG- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.home. -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmx-tools.jar. -DEBUG- Dependency on jndi exists, no need to add for property jndi.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home. -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -DEBUG- Dependency on javamail exists, no need to add for property mail.home. -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. -DEBUG- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. -DEBUG- Dependency on jaf exists, no need to add for property activation.home. -DEBUG- Dependency on commons-modeler exists, no need to add for property commons-modeler.home. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. -DEBUG- Dependency on jakarta-struts exists, no need to add for property struts.home. The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Success Elapsed: 2 mins 21 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20040721.jar -Dmail.home=/usr/local/gump/packages/javamail-1.3 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040721.jar -Dxml-apis.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar -DxercesImpl.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar -Dstruts.home=/usr/local/gump/public/workspace/jakarta-struts/dist -Djsse.home=/usr/local
DO NOT REPLY [Bug 30236] New: - host-independent URI-to-worker mappings do not work with isapi_redirect.dll
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30236 host-independent URI-to-worker mappings do not work with isapi_redirect.dll Summary: host-independent URI-to-worker mappings do not work with isapi_redirect.dll Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Native:Integration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The URI handed to map_uri_to_worker() in jk_isapi_plugin.c always contains the host and port screwing up virtual host-independent URI-to-worker mappings. I did a little digging and discovered that this has apparently been broken since revision 1.19 (i.e. 1.18 contains code that makes sense). The apparent fix is attached. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 30236] New: - host-independent URI-to-worker mappings do not work with isapi_redirect.dll
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: bao DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG bao RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT bao http://issues.apache.org/bugzilla/show_bug.cgi?id=30236. bao ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND bao INSERTED IN THE BUG DATABASE. bao http://issues.apache.org/bugzilla/show_bug.cgi?id=30236 bao host-independent URI-to-worker mappings do not work with isapi_redirect.dll baoSummary: host-independent URI-to-worker mappings do not work with bao isapi_redirect.dll baoProduct: Tomcat 5 baoVersion: 5.0.25 bao Platform: PC bao OS/Version: Windows NT/2K bao Status: NEW bao Severity: Major bao Priority: Other bao Component: Native:Integration bao AssignedTo: [EMAIL PROTECTED] bao ReportedBy: [EMAIL PROTECTED] bao The URI handed to map_uri_to_worker() in jk_isapi_plugin.c always contains the bao host and port screwing up virtual host-independent URI-to-worker mappings. bao I did a little digging and discovered that this has apparently been broken since bao revision 1.19 (i.e. 1.18 contains code that makes sense). The apparent fix is bao attached. bao - bao To unsubscribe, e-mail: [EMAIL PROTECTED] bao For additional commands, e-mail: bao [EMAIL PROTECTED] -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30236] - host-independent URI-to-worker mappings do not work with isapi_redirect.dll
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30236 host-independent URI-to-worker mappings do not work with isapi_redirect.dll --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 17:31 --- Created an attachment (id=12184) Proposed fix (merged into 1.22 from 1.18) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30236] - host-independent URI-to-worker mappings do not work with isapi_redirect.dll
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30236 host-independent URI-to-worker mappings do not work with isapi_redirect.dll --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 17:33 --- Just to add an example: /examples/*=ajp13 will no longer work with the current code but /fullhostname/examples/*=ajp13 does. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30238] New: - isapi_install.vbs has hard-wired references throughout to isapi_redirector.dll
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30238. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30238 isapi_install.vbs has hard-wired references throughout to isapi_redirector.dll Summary: isapi_install.vbs has hard-wired references throughout to isapi_redirector.dll Product: Tomcat 5 Version: 5.0.25 Platform: PC OS/Version: All Status: NEW Severity: Major Priority: Other Component: Native:Packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] isapi_install.vbs has hard-wired references throughout to isapi_redirector.dll. Unfortunately, the default name of the DLL and that used throughout all the documentation bundled and otherwise is isapi_redirect.dll. This leads to *very* confusing failures to load the connector into IIS. Once this apparent typo is corrected (via a simple replace all), this script works great -- and should also be noted in the documentation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. In theory sticky sessions shouldn't be tightly coupled like this - it should be a case of plan a) stick to the same server, else revert to plan b). Yes, but why would you wish to separate those? The stickiness is the part of load balancer, and merely flags the connection to a particular remote so that the load balancer can skip the Remote selection, cause it already selected the Remote in some previous transaction. Something different is the way the load balancer selects the Remote, and that can be separated if the separation is needed at all, but I doubt that. I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) MT. smime.p7s Description: S/MIME cryptographic signature
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: MT Graham Leggett wrote: sticky sessions are tightly coupled with the load balancer itself and the way it decides the client route. In theory sticky sessions shouldn't be tightly coupled like this - it should be a case of plan a) stick to the same server, else revert to plan b). MT Yes, but why would you wish to separate those? MT The stickiness is the part of load balancer, and merely flags the connection MT to a particular remote so that the load balancer can skip the Remote MT selection, cause it already selected the Remote in some previous MT transaction. MT Something different is the way the load balancer selects the Remote, and MT that can be separated if the separation is needed at all, but I doubt that. I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. MT I'm not that familiar with mod_proxy code, so please no hooks, not jet :) MT MT. -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30239] New: - Connector documentation is not up-to-date for IIS 6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30239 Connector documentation is not up-to-date for IIS 6 Summary: Connector documentation is not up-to-date for IIS 6 Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Native:Packaging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The IIS portion of the Tomcat connector documentation makes no mention of the extra steps required to get the connectors working with IIS 6. These are clearly documented elsewhere on the web (http://www.rit.edu/~ack5504/tomcat-iis6-howto/tomcat-iis6-howto.html amongst other places), so there is little reason not to incorporate this information. Not bundling this information leaves most people attempting this configuration completely lost -- and they just give up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30239] - Connector documentation is not up-to-date for IIS 6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30239 Connector documentation is not up-to-date for IIS 6 [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Major - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS-Tomcat connector bugs
I have been pounding my head into the wall trying to get
isapi_redirect.dll working on IIS 6.0.
There are 3 bugs here with isapi_redirect and its docs as they stand
today -- only one directly of Microsoft's making, it appears:
*1) The URI handed to map_uri_to_worker() in jk_isapi_plugin.c always
contains the host and port screwing up virtual host-independent
URI-to-worker mappings.*
I did a little digging and discovered that this has apparently been
broken since revision 1.19 (i.e. 1.18 worked). The apparent fix is as
follows:
--- jk_isapi_plugin.orig.c 2004-02-24 01:45:50.0 -0600
+++ jk_isapi_plugin.c 2004-07-21 12:11:50.0 -0500
@@ -718,14 +718,13 @@
jk_log(logger, JK_LOG_DEBUG,
In HttpFilterProc Virtual Host redirection
of %s\n,
snuri);
-} else {
- strncpy(snuri, uri, sizeof(snuri));
- }
+worker = map_uri_to_worker(uw_map, snuri, logger);
+}
if (!worker) {
jk_log(logger, JK_LOG_DEBUG,
In HttpFilterProc test Default redirection
of %s\n,
uri);
-worker = map_uri_to_worker(uw_map, snuri, logger);
+worker = map_uri_to_worker(uw_map, uri, logger);
}
if (worker) {
I have filed this as bug 30236
http://issues.apache.org/bugzilla/show_bug.cgi?id=30236.
Just to add an example:
/examples/*=ajp13
will no longer work with the current code but
/fullhostname/examples/*=ajp13
does.
*2) isapi_install.vbs has hard-wired references throughout to
isapi_redirector.dll. Unfortunately, the default name of the DLL and
that used throughout all the documentation bundled and otherwise is
isapi_redirect.dll.*
This leads to *very* confusing failures to load the connector into IIS.
Once this apparent typo is corrected, this script works great.
I have filed this as bug 30238
http://issues.apache.org/bugzilla/show_bug.cgi?id=30238.
*3) Connector documentation is not up-to-date for IIS 6 Changes*
The IIS portion of the Tomcat connector documentation makes no mention
of the extra steps required to get the connectors working with IIS 6.
These are clearly documented elsewhere on the web
(http://www.rit.edu/~ack5504/tomcat-iis6-howto/tomcat-iis6-howto.html
http://www.rit.edu/%7Eack5504/tomcat-iis6-howto/tomcat-iis6-howto.html
amongst other places), so there is little reason not to incorporate this
information. Not bundling this information leaves most people
attempting this configuration completely lost -- and they just give up.
I have filed this as bug 30239
http://issues.apache.org/bugzilla/show_bug.cgi?id=30239.
That's it for the moment
--
Jess Holle
Re: IIS-Tomcat connector bugs
Dobry den,
nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu
NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat
nemusite.
Antispamovy filter Oddych.sk
Nedoruceny mail:
JH I have been pounding my head into the wall trying to get
JH isapi_redirect.dll working on IIS 6.0.
JH There are 3 bugs here with isapi_redirect and its docs as they stand
JH today -- only one directly of Microsoft's making, it appears:
JH *1) The URI handed to map_uri_to_worker() in jk_isapi_plugin.c always
JH contains the host and port screwing up virtual host-independent
JH URI-to-worker mappings.*
JH I did a little digging and discovered that this has apparently been
JH broken since revision 1.19 (i.e. 1.18 worked). The apparent fix is as
JH follows:
JH --- jk_isapi_plugin.orig.c 2004-02-24 01:45:50.0 -0600
JH +++ jk_isapi_plugin.c 2004-07-21 12:11:50.0 -0500
JH @@ -718,14 +718,13 @@
JH jk_log(logger, JK_LOG_DEBUG,
JH In HttpFilterProc Virtual Host redirection
JH of %s\n,
JH snuri);
JH -} else {
JH - strncpy(snuri, uri, sizeof(snuri));
JH - }
JH +worker = map_uri_to_worker(uw_map, snuri, logger);
JH +}
JH if (!worker) {
JH jk_log(logger, JK_LOG_DEBUG,
JH In HttpFilterProc test Default redirection
JH of %s\n,
JH uri);
JH -worker = map_uri_to_worker(uw_map, snuri, logger);
JH +worker = map_uri_to_worker(uw_map, uri, logger);
JH }
JH if (worker) {
JH I have filed this as bug 30236
JH http://issues.apache.org/bugzilla/show_bug.cgi?id=30236.
JH Just to add an example:
JH /examples/*=ajp13
JH will no longer work with the current code but
JH /fullhostname/examples/*=ajp13
JH does.
JH *2) isapi_install.vbs has hard-wired references throughout to
JH isapi_redirector.dll. Unfortunately, the default name of the DLL and
JH that used throughout all the documentation bundled and otherwise is
JH isapi_redirect.dll.*
JH This leads to *very* confusing failures to load the connector into IIS.
JH Once this apparent typo is corrected, this script works great.
JH I have filed this as bug 30238
JH http://issues.apache.org/bugzilla/show_bug.cgi?id=30238.
JH *3) Connector documentation is not up-to-date for IIS 6 Changes*
JH The IIS portion of the Tomcat connector documentation makes no mention
JH of the extra steps required to get the connectors working with IIS 6.
JH These are clearly documented elsewhere on the web
JH (http://www.rit.edu/~ack5504/tomcat-iis6-howto/tomcat-iis6-howto.html
JH http://www.rit.edu/%7Eack5504/tomcat-iis6-howto/tomcat-iis6-howto.html
JH amongst other places), so there is little reason not to incorporate this
JH information. Not bundling this information leaves most people
JH attempting this configuration completely lost -- and they just give up.
JH I have filed this as bug 30239
JH http://issues.apache.org/bugzilla/show_bug.cgi?id=30239.
JH That's it for the moment
JH --
JH Jess Holle
-=x=-
Skontrolované antivírovým programom NOD32
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. I would probably use the stickiness long before I started messing around with load balancing. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk iishowto.xml
yoavs 2004/07/21 11:06:13 Modified:webapps/docs changelog.xml jk/xdocs/jk iishowto.xml Log: Addressed Bugzilla 30239, out-of-date docs for IIS how-to. Revision ChangesPath 1.71 +26 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70 retrieving revision 1.71 diff -u -r1.70 -r1.71 --- changelog.xml 17 Jun 2004 01:26:20 - 1.70 +++ changelog.xml 21 Jul 2004 18:06:13 - 1.71 @@ -14,13 +14,38 @@ body +section name=Tomcat 5.0.28 (yoavs) + subsection name=General +changelog + fix +bug30239/bug: Updated IIS how-to to link to Wiki page with instrutions for IIS 5 and IIS 6 configurations. (yoavs) + /fix +/changelog + /subsection + + subsection name=Catalina + /subsection + + subsection name=Coyote + /subsection + + subsection name=Jasper + /subsection + + subsection name=Cluster + /subsection + + subsection name=Webapps + /subsection +/section + section name=Tomcat 5.0.27 (yoavs) subsection name=General changelog updateUpdated dependencies on commons-dbcp (to 1.2.1), commons-pool (to 1.2), and commons-logging (to 1.0.4). (yoavs) /update fix -bug29368/bug: Replaced references to xmlParserAPIs.jar with xml-apis.jar, as the former is now deprecated in Xerces. Users wishing to use old versions of Xerces that don't have xml-apis.jar can still do so without a problem. Users wishing to build tomcat using xmlParserAPIs.jar instead of xml-apis.jar can also do so with a trivial edit in the build.xml file. +bug29368/bug: Replaced references to xmlParserAPIs.jar with xml-apis.jar, as the former is now deprecated in Xerces. Users wishing to use old versions of Xerces that don't have xml-apis.jar can still do so without a problem. Users wishing to build tomcat using xmlParserAPIs.jar instead of xml-apis.jar can also do so with a trivial edit in the build.xml file. (yoavs) /fix /changelog /subsection 1.7 +11 -3 jakarta-tomcat-connectors/jk/xdocs/jk/iishowto.xml Index: iishowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/iishowto.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- iishowto.xml 4 Mar 2004 04:46:34 - 1.6 +++ iishowto.xml 21 Jul 2004 18:06:13 - 1.7 @@ -19,6 +19,7 @@ titleIIS HowTo/title author email=[EMAIL PROTECTED]Henri Gomez/author author email=[EMAIL PROTECTED]Gal Shachor/author +author email=[EMAIL PROTECTED]Yoav Shapira/author date$Date$/date /properties @@ -71,10 +72,10 @@ WinNT4.0-i386 SP4/SP5/SP6a (should be able to work with other service packs), Win2K and WinXP and Win98 /li li -IIS4.0 and PWS4.0 +IIS4.0 and PWS4.0 (numerous people have working IIS 5 and IIS 6 configurations) /li li -Tomcat 3.2.x, Tomcat 3.3.x, Tomcat 4.0.x, Tomcat 4.1.x and Tomcat 5 +Tomcat 3.2 and later, Tomcat 4.x and Tomcat 5 /li /ul /p @@ -85,6 +86,13 @@ /p /subsection +subsection name=IIS 5 and 6 Notes +p +There are extra steps you need to take for configuring Tomcat with IIS 5 and 6. Please see the appropriate links from +a href=http://wiki.apache.org/jakarta-tomcat/Tomcat_2fLinks;Tomcat Useful Links/a. +/p +/subsection + subsection name=Who support ajp protocols ? p The ajp12 protocol is only available in Tomcat 3.2.x and 3.3.x. @@ -92,7 +100,7 @@ p The bajp12/b has been bdeprecated/b with Tomcat 3.3.x and you should use instead -bajp13/b which is the only ajp protocol known by Tomcat 4.0.x, 4.1.x and 5. +bajp13/b which is the only ajp protocol known by Tomcat 4.x and 5. /p p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30239] - Connector documentation is not up-to-date for IIS 6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30239 Connector documentation is not up-to-date for IIS 6 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:07 --- - Added link to this IIS how-to document in Wiki pages - Updated JK IIS how-to page with section on IIS 5 and 6 which points readers to the wiki page with the many how-to links and references. (These changes will be visible next time the docs site is updated, and of course in the next releases). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk iishowto.xml
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: yao yoavs 2004/07/21 11:06:13 yao Modified:webapps/docs changelog.xml yaojk/xdocs/jk iishowto.xml yao Log: yao Addressed Bugzilla 30239, out-of-date docs for IIS how-to. yao Revision ChangesPath yao 1.71 +26 -1 yao jakarta-tomcat-catalina/webapps/docs/changelog.xml yao Index: changelog.xml yao yao === yao RCS file: yao /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v yao retrieving revision 1.70 yao retrieving revision 1.71 yao diff -u -r1.70 -r1.71 yao --- changelog.xml17 Jun 2004 01:26:20 - 1.70 yao +++ changelog.xml21 Jul 2004 18:06:13 - 1.71 yao @@ -14,13 +14,38 @@ yaobody yao +section name=Tomcat 5.0.28 (yoavs) yao + subsection name=General yao +changelog yao + fix yao +bug30239/bug: Updated IIS how-to to link to yao Wiki page with instrutions for IIS 5 and IIS 6 configurations. yao (yoavs) yao + /fix yao +/changelog yao + /subsection yao + yao + subsection name=Catalina yao + /subsection yao + yao + subsection name=Coyote yao + /subsection yao + yao + subsection name=Jasper yao + /subsection yao + yao + subsection name=Cluster yao + /subsection yao + yao + subsection name=Webapps yao + /subsection yao +/section yao + yaosection name=Tomcat 5.0.27 (yoavs) yao subsection name=General yaochangelog yao updateUpdated dependencies on commons-dbcp (to yao 1.2.1), commons-pool (to 1.2), and commons-logging (to 1.0.4). yao (yoavs) yao /update yao fix yao -bug29368/bug: Replaced references to yao xmlParserAPIs.jar with xml-apis.jar, as the former is now yao deprecated in Xerces. Users wishing to use old versions of yao Xerces that don't have xml-apis.jar can still do so without a yao problem. Users wishing to build tomcat using xmlParserAPIs.jar yao instead of xml-apis.jar can also do so with a trivial edit in the yao build.xml file. yao +bug29368/bug: Replaced references to yao xmlParserAPIs.jar with xml-apis.jar, as the former is now yao deprecated in Xerces. Users wishing to use old versions of yao Xerces that don't have xml-apis.jar can still do so without a yao problem. Users wishing to build tomcat using xmlParserAPIs.jar yao instead of xml-apis.jar can also do so with a trivial edit in the yao build.xml file. (yoavs) yao /fix yao/changelog yao /subsection yao 1.7 +11 -3 yao jakarta-tomcat-connectors/jk/xdocs/jk/iishowto.xml yao Index: iishowto.xml yao yao === yao RCS file: yao /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/iishowto.xml,v yao retrieving revision 1.6 yao retrieving revision 1.7 yao diff -u -r1.6 -r1.7 yao --- iishowto.xml 4 Mar 2004 04:46:34 - 1.6 yao +++ iishowto.xml 21 Jul 2004 18:06:13 - 1.7 yao @@ -19,6 +19,7 @@ yaotitleIIS HowTo/title yaoauthor email=[EMAIL PROTECTED]Henri Gomez/author yaoauthor email=[EMAIL PROTECTED]Gal Shachor/author yao +author email=[EMAIL PROTECTED]Yoav Shapira/author yaodate$Date$/date yao/properties yao @@ -71,10 +72,10 @@ yaoWinNT4.0-i386 SP4/SP5/SP6a (should be able to work with yao other service packs), Win2K and WinXP and Win98 yao/li yaoli yao -IIS4.0 and PWS4.0 yao +IIS4.0 and PWS4.0 (numerous people have working IIS 5 and IIS 6 configurations) yao/li yaoli yao -Tomcat 3.2.x, Tomcat 3.3.x, Tomcat 4.0.x, Tomcat 4.1.x and Tomcat 5 yao +Tomcat 3.2 and later, Tomcat 4.x and Tomcat 5 yao/li yao/ul yao/p yao @@ -85,6 +86,13 @@ yao/p yao/subsection yao +subsection name=IIS 5 and 6 Notes yao +p yao +There are extra steps you need to take for configuring yao Tomcat with IIS 5 and 6. Please see the appropriate links from yao +a yao href=http://wiki.apache.org/jakarta-tomcat/Tomcat_2fLinks;Tomcat yao Useful Links/a. yao +/p yao +/subsection yao + yaosubsection name=Who support ajp protocols ? yaop yaoThe ajp12 protocol is only available in Tomcat 3.2.x and 3.3.x. yao @@ -92,7 +100,7 @@ yaop yaoThe bajp12/b has been bdeprecated/b with Tomcat yao 3.3.x and you should use instead yao -bajp13/b which is the only ajp protocol known by Tomcat 4.0.x, 4.1.x and 5. yao +bajp13/b which is the only ajp protocol known by Tomcat 4.x and 5. yao/p yaop yao - yao To unsubscribe, e-mail: [EMAIL PROTECTED] yao For additional commands, e-mail: yao [EMAIL
DO NOT REPLY [Bug 30238] - isapi_install.vbs has hard-wired references throughout to isapi_redirector.dll
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30238. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30238 isapi_install.vbs has hard-wired references throughout to isapi_redirector.dll [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:12 --- Replace isapi_redirector.dll with isapi_redirect.dll in isapi_install.vbs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/iis isapi_install.vbs
yoavs 2004/07/21 11:11:05 Modified:webapps/docs changelog.xml jk/native/iis isapi_install.vbs Log: Addressed Bugzilla 30238. Revision ChangesPath 1.72 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.71 retrieving revision 1.72 diff -u -r1.71 -r1.72 --- changelog.xml 21 Jul 2004 18:06:13 - 1.71 +++ changelog.xml 21 Jul 2004 18:11:05 - 1.72 @@ -20,6 +20,9 @@ fix bug30239/bug: Updated IIS how-to to link to Wiki page with instrutions for IIS 5 and IIS 6 configurations. (yoavs) /fix + fix +bug30238/bug: Replaced isapi_redirector.dll isapi_redirect.dll in installation script for consistency. (yoavs) + /fix /changelog /subsection 1.5 +3 -3 jakarta-tomcat-connectors/jk/native/iis/isapi_install.vbs Index: isapi_install.vbs === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/isapi_install.vbs,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- isapi_install.vbs 27 Feb 2004 16:07:39 - 1.4 +++ isapi_install.vbs 21 Jul 2004 18:11:05 - 1.5 @@ -47,7 +47,7 @@ serverName = args(0) filterDir = args(1) filterName = jakarta -filterLib = \isapi_redirector.dll +filterLib = \isapi_redirect.dll workerFile = args(2) mountFile = args(3) logFile = args(4) @@ -161,7 +161,7 @@ on error goto 0 info Updating Registry -shell.RegWrite regRoot + extension_uri, /jakarta/isapi_redirector.dll +shell.RegWrite regRoot + extension_uri, /jakarta/isapi_redirect.dll shell.RegWrite regRoot + log_file, logFile shell.RegWrite regRoot + log_level, logLevel shell.RegWrite regRoot + worker_file, workerFile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) So, where do you see a lb code in the mod_proxy tree. Do you have some ideas where will it fit? It would be also good if you could make some p-code of the mod_proxy or some data flow diagram. Also do you need our support on coding? It would be perhaps better that you write the function prototypes that need some lb behavior returnig somethig like not_implemented or just mark some /* TODO: ...*/ in the code. MT. smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 22695] - TC 5.0.9 Exception During Startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=22695. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=22695 TC 5.0.9 Exception During Startup --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:15 --- Can you please post steps and a WAR we can use to reproduce this exception? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23802] - Bug Workaround: Custom 401 error page fails WWW-Authenticate header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=23802. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=23802 Bug Workaround: Custom 401 error page fails WWW-Authenticate header [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:16 --- I guess the answer to my question is no, so I'm closing this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21564] - CoyoteConnector binds to all hosts even when a specific host (incorrect) is specified
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=21564. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21564 CoyoteConnector binds to all hosts even when a specific host (incorrect) is specified [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:28 --- Assuming you're talking about IntrospectionUtils#convert (the only place that deals with InetAddress in that class): it doesn't just swallow a bad host name. In that case result would be null and the convert method would throw an IllegalArgumentException. It's not IntrospectionUtils' role to further examine the InetAddress itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22679] - how to access ssl session ID out of tomcat to prevent session hijacking
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=22679. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=22679 how to access ssl session ID out of tomcat to prevent session hijacking --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:29 --- Please suggest text in patch diff format for RFE: enhance the SSL ho wto description at the above URL with a section on how to do this. and we'll consider adding it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29258] - Tomcat 5.0.24+ jmx.jar may not be in CLASSPATH
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29258 Tomcat 5.0.24+ jmx.jar may not be in CLASSPATH [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:34 --- Tomcat requires a JDK that understands Jar Class Path directives, which your kaffe 1.1.5 apparently doesn't. If your JDK doesn't understand these directives, you may have to manually modify a number of things, not just catalina.sh, as you undoubtedly know by now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30198] - Duplicated attributes in connector tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30198. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30198 Duplicated attributes in connector tag [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:34 --- The writer writes all the attributes, this is not a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26890] - Multipart/Form-Data Unexpected End Of Part
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26890. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26890 Multipart/Form-Data Unexpected End Of Part [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:37 --- No answer in two months, closing item. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26229] - request.getRemoteUser() = null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26229. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26229 request.getRemoteUser() = null [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 18:42 --- Yup, you need to turn that off. In Tomcat 5, it's called clientAuth instead of tomcatAuthentication, and the Connector and SSL documentation pages have been updated to reflect the attribute name change. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Filip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 1:12 PM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) So, where do you see a lb code in the mod_proxy tree. Do you have some ideas where will it fit? It would be also good if you could make some p-code of the mod_proxy or some data flow diagram. Also do you need our support on coding? It would be perhaps better that you write the function prototypes that need some lb behavior returnig somethig like not_implemented or just mark some /* TODO: ...*/ in the code. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Dobry den, nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat nemusite. Antispamovy filter Oddych.sk Nedoruceny mail: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. FHD cool, and then have the server just try them in that order? FHD ie, if the sticky server went down, it just takes the next one FHD from the FHD list (and that list should be ordered well since it comes from the LB algorithm) FHD correct assumption? FHD Filip FHD - Original Message - FHD From: Mladen Turk [EMAIL PROTECTED] FHD To: 'Tomcat Developers List' [EMAIL PROTECTED] FHD Sent: Wednesday, July 21, 2004 1:12 PM FHD Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev FHD Graham Leggett wrote: Yes, but why would you wish to separate those? Because they are two separate behaviours that could quite easily be used independantly of each other. FHD OK, it makes sense. I'm not that familiar with mod_proxy code, so please no hooks, not jet :) I am familiar with the code, so don't be afraid of the hooks, as I'm quite willing to tell you where things go :) FHD So, where do you see a lb code in the mod_proxy tree. Do you have some ideas FHD where will it fit? FHD It would be also good if you could make some p-code of the mod_proxy or some FHD data flow diagram. FHD Also do you need our support on coding? FHD It would be perhaps better that you write the function prototypes that need FHD some lb behavior returnig somethig like not_implemented or just mark some /* FHD TODO: ...*/ in the code. FHD MT. FHD - FHD To unsubscribe, e-mail: [EMAIL PROTECTED] FHD For additional commands, e-mail: FHD [EMAIL PROTECTED] -=x=- Skontrolované antivírovým programom NOD32 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
luehe 2004/07/21 11:54:18
Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Log:
Added setJspReloadCount method
Revision ChangesPath
1.37 +10 -0
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- JspServlet.java 16 Apr 2004 23:01:29 - 1.36
+++ JspServlet.java 21 Jul 2004 18:54:18 - 1.37
@@ -100,6 +100,16 @@
/**
+ * Resets the JSP reload counter.
+ *
+ * @param count Value to which to reset the JSP reload counter
+ */
+public void setJspReloadCount(int count) {
+this.rctxt.setJspReloadCount(count);
+}
+
+
+/**
* Gets the number of JSPs that have been reloaded.
*
* pThis info may be used for monitoring purposes.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Dobry den,
nizsie uvedeny mail NEBOL DORUCENY. Dopiste, prosim, k predmetu mailu
NIE SPAM a znova ho poslite. V buducich mailoch uz NIE SPAM pisat
nemusite.
Antispamovy filter Oddych.sk
Nedoruceny mail:
lao luehe 2004/07/21 11:54:18
lao Modified:jasper2/src/share/org/apache/jasper/servlet JspServlet.java
lao Log:
lao Added setJspReloadCount method
lao Revision ChangesPath
lao 1.37 +10 -0
lao jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
lao Index: JspServlet.java
lao
lao ===
lao RCS file:
lao
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
lao retrieving revision 1.36
lao retrieving revision 1.37
lao diff -u -r1.36 -r1.37
lao --- JspServlet.java 16 Apr 2004 23:01:29 - 1.36
lao +++ JspServlet.java 21 Jul 2004 18:54:18 - 1.37
lao @@ -100,6 +100,16 @@
lao/**
lao + * Resets the JSP reload counter.
lao + *
lao + * @param count Value to which to reset the JSP reload counter
lao + */
lao +public void setJspReloadCount(int count) {
lao +this.rctxt.setJspReloadCount(count);
lao +}
lao +
lao +
lao +/**
lao * Gets the number of JSPs that have been reloaded.
lao *
lao * pThis info may be used for monitoring purposes.
lao -
lao To unsubscribe, e-mail: [EMAIL PROTECTED]
lao For additional commands, e-mail:
lao [EMAIL PROTECTED]
-=x=-
Skontrolované antivírovým programom NOD32
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Think that it should return 'Server Busy' in case the sticky is not available, cause you may be in the middle of transaction while the other server might have no clue about that. MT. smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 30241] New: - Enhance build script to use branch argument when checking out files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30241. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30241 Enhance build script to use branch argument when checking out files Summary: Enhance build script to use branch argument when checking out files Product: Tomcat 5 Version: 5.0.25 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] With the TOMCAT_5_0 branch now effective, the build files need to be modified so that when they check out from CVS they use a branch directive. The default should of course be HEAD. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21564] - CoyoteConnector binds to all hosts even when a specific host (incorrect) is specified
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=21564. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=21564 CoyoteConnector binds to all hosts even when a specific host (incorrect) is specified --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 19:10 --- In Tomcat 4, it was swallowed. To the point we had to subclass the Protocol class to block this case. Its a critical problem for a production server with multiple virtual hosts. granted its a typo, but still. I will check with the latest in 4 series, and with tomcat 5. If its still there with Tomcat 4, is it likely to get fixed. With or without a patch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
really, so then there is no fail over. cause that is what fail over does, redirects you to another server. and with session replication in place, you should be good to go FIlip - Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 2:00 PM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev Filip Hanik wrote: I suppose in this case the load balancer would run HOOK_MIDDLE, and sticky would run HOOK_LAST. cool, and then have the server just try them in that order? ie, if the sticky server went down, it just takes the next one from the list (and that list should be ordered well since it comes from the LB algorithm) correct assumption? Think that it should return 'Server Busy' in case the sticky is not available, cause you may be in the middle of transaction while the other server might have no clue about that. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config globalresources.xml
yoavs 2004/07/21 12:24:00 Modified:webapps/docs changelog.xml jndi-resources-howto.xml webapps/docs/config globalresources.xml Log: Addressed Bugzilla 29584, cleaning up JNDI documentation. Revision ChangesPath 1.73 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.72 retrieving revision 1.73 diff -u -r1.72 -r1.73 --- changelog.xml 21 Jul 2004 18:11:05 - 1.72 +++ changelog.xml 21 Jul 2004 19:24:00 - 1.73 @@ -23,6 +23,9 @@ fix bug30238/bug: Replaced isapi_redirector.dll isapi_redirect.dll in installation script for consistency. (yoavs) /fix + fix +bug29584/bug: Enhanced and clarified JNDI documentation. (yoavs) + /fix /changelog /subsection 1.6 +57 -12jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml Index: jndi-resources-howto.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/jndi-resources-howto.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- jndi-resources-howto.xml 9 Aug 2003 18:59:22 - 1.5 +++ jndi-resources-howto.xml 21 Jul 2004 19:24:00 - 1.6 @@ -7,8 +7,9 @@ project; properties -author email=[EMAIL PROTECTED]Craig R. McClanahan/author -titleJNDI Resources HOW-TO/title + author email=[EMAIL PROTECTED]Craig R. McClanahan/author + author email=[EMAIL PROTECTED]Yoav Shapira/author + titleJNDI Resources HOW-TO/title /properties body @@ -17,10 +18,42 @@ section name=Introduction pTomcat 5 provides a JNDI strongInitialContext/strong implementation -instance to web applications running under it, in a manner that is compatible -with those provided by a a href=http://java.sun.com/j2ee;Java2 Enterprise -Edition/a application server. Entries in this codeInitialContext/code -are configured in the code$CATALINA_HOME/conf/server.xml/code file, and +instance for each web application running under it, in a manner that is +compatible with those provided by a +a href=http://java.sun.com/j2ee;Java2 Enterprise Edition/a application +server. + +The J2EE standard provides a standard set of elements in +the code/WEB-INF/web.xml/code file to reference resources; resources +referenced in these elements must be defined in an application-server-specific configuration. +/p + +pFor Tomcat 5, these entries in per-web-application +codeInitialContext/code are configured in the +codestronglt;Contextgt;/strong/code or +codestronglt;DefaultContextgt;/strong/code +elements of the +a href=config/server.htmlcodestronglt;Servergt;/strong/code/a +element. + +The codestronglt;Contextgt;/strong/code element can be specified +in either code$CATALINA_HOME/conf/server.xml/code or, preferably, +the per-web-application context XML file. + +codestronglt;DefaultContextgt;/strong/code must be specified in +code$CATALINA_HOME/conf/server.xml/code. +/p + +pTomcat 5 maintains a separate namespace of global resources for the +entire server. These are configured in the +a href=config/globalresources.html +codestronglt;GlobalNameingResourcesgt;/strong/code/a element of +code$CATALINA_HOME/conf/server.xml/code. You may expose these resources to +web applications by using +codestronglt;ResourceLinkgt;/strong/code elements. +/p + +pThe resources defined in these elements may be referenced by the following elements in the web application deployment descriptor (code/WEB-INF/web.xml/code) of your web application:/p ul @@ -39,10 +72,11 @@ pThe codeInitialContext/code is configured as a web application is initially deployed, and is made available to web application components (for -read-only access). All configured entries and resources will be placed in +read-only access). All configured entries and resources are placed in the codejava:comp/env/code portion of the JNDI namespace, so a typical access to a resource - in this case, to a JDBC codeDataSource/code - would look something like this:/p + source // Obtain our environment naming context Context initCtx = new InitialContext(); @@ -75,8 +109,9 @@ section name=Configuring JNDI Resources pEach available JNDI Resource is configured based on inclusion of the -following elements in the code$CATALINA_HOME/conf/server.xml/code -file:/p +following elements in the codestronglt;Contextgt;/strong/code or +codestronglt;DefaultContextgt;/strong/code elements:/p + ul lia href=config/context.html#Environment
DO NOT REPLY [Bug 29584] - JNDI documentation could be more clear
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29584. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29584 JNDI documentation could be more clear [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-07-21 19:25 --- Fixed patches applied. Thank you for your contribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
