RE: CVS / mod_webapp / web-connector sub-project
I think Dan is right on this one - improving the configuration of mod_jk is probably the most important thing, and merging with mod_webapp and porting it's protocol and config mechanism would be a good way to do that. I agree that integrating mod_webapp functionnalities is not a priority for the 3.x branch. We could add the autoconf stuff or may be also use APR which will hide all OS complexity. The problem today, is that there is 2 version of mod_jk : *) mod_jk in Tomcat 3.3 Latest code, maintainers, bugs fixed and Apache 1.3/2.0 support *) mod_jk in Tomcat 3.2.x The same code since 3.2, no much maintainers, some bugs fixed in 3.3 are not in 3.2, only Apache 1.3 support. If a user have problem using mod_jk against it's Tomcat 3.2.1 release (or upcoming Tomcat 3.2.2), we'll ask him to use the mod_jk from Tomcat 3.3 CVS ! Problems could be using Apache 2.0 or Apache restart needed after Tomcat shutdown/restart when using ajp13, . I think the best way to do that would be a revolution ( like jasper34 ), and when it's ready propose it as either a replacement for both mod_jk and mod_webapp, or as a top level project ( if enough people will contribute on it ). Combining mod_jk and mod_webapp is likely to result in something better than both, so the vote to replace mod_jk and mod_webapp will be a formality :-) I strongly think we must have the connectors in a separate project so I'll follow your proposal and start a revolution. ( making it a top level project now is not a good idea right now, neither to do the development in the main tree - there are just few big bugs to be fixed before a 3.3 beta. ) Yep, I'll keep maintain the code in 3.3 tree and in parallel start the proposed revolution : * native code extracted = connector * java code moved from tomcat core/utils = org.apache.connector P.S. It's fun beeing a "revolutionar" ! Let's go, there were not much revolution from France since 1789
RE: CVS / mod_webapp / web-connector sub-project
On Thu, 19 Apr 2001, GOMEZ Henri wrote: I think Dan is right on this one - improving the configuration of mod_jk is probably the most important thing, and merging with mod_webapp and porting it's protocol and config mechanism would be a good way to do that. I agree that integrating mod_webapp functionnalities is not a priority for the 3.x branch. We could add the autoconf stuff or may be also use APR which will hide all OS complexity. Well, it is a priority - but smaller than releasing 3.3 sooner and keeping it stable. That's true for many other things - we should be very conservative in adding any new feature or making any non-bug-fix change that can be done as a separate module. If you think in terms of modules everything is much simpler and safe. A revolution that implements a merge of the 2 connectors will be a module, same for a jasper merge, or for any new fancy features. The user can use the new module - and if we feel the new code is stable enough we can include it in a future release ( 3.3.1 ? ), or create a separate distribution for it. It'll be just like the "update" feature in many programs ( like xemacs, netbeans, mozilla ). The problem today, is that there is 2 version of mod_jk : *) mod_jk in Tomcat 3.3 Latest code, maintainers, bugs fixed and Apache 1.3/2.0 support *) mod_jk in Tomcat 3.2.x The same code since 3.2, no much maintainers, some bugs fixed in 3.3 are not in 3.2, only Apache 1.3 support. 3.2.3 is almost released. 3.3 is getting closer - we have quite a few bugs, but most of them are present in 3.2 also ( so no regression AFAIK, only "LATER" ). It is normal that the next release has more bug fixes than the previous one. I strongly think we must have the connectors in a separate project so I'll follow your proposal and start a revolution. Having it "separate" is good, the "project" part doesn't seem right for now. ( at least I would be very -1 on doing the merge of adding new features in the main tree for 3.3 - but if it is completed and works fine before the next release we should be able to include both modules ). * native code extracted = connector * java code moved from tomcat core/utils = org.apache.connector +1 Maybe httpserver ( to match the httpclient in commons ) ? ( I think it should be org.apache.tomcat. - we shouldn't add new org.apache namespaces ) Costin
Re: CVS / mod_webapp / web-connector sub-project
In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile -- specifically, mod_jk was built to handle a variety of protocols (ajp12, ajp13, etc.). So writing a protocol handler for the mod_webapp protocol would give a lot of benefits -- load-balancing, support for a variety of web servers, debugged C code. Pier had mentioned a while ago that the mod_jk code was completely incomprehensible. Gal Shachor basically wrote his own object system in C, which is very, very confusing at first. I've added a lot of comments in the 3.3 branch, particularly to common/jk_service.h, with the explicit goal of making it easier for people to write new protocol handlers and/or new web server plugins. One thing I can imagine being a problem right off the bat would be that the abstractions which allow mod_jk to deal with a variety of web servers may not support the fine-grained control over configuration which mod_webapp supports. Splitting off a connectors sub-project: I don't think I support this -- it was discussed on the list a few months ago, and my objections from then still hold. Sharing session-information around: feels way too complex -- I think there are better ways to get persistent sessions. Overloading the (already-complicated) web server/servlet container communication stream seems like asking for trouble we don't need. -Dan GOMEZ Henri wrote: Fine to see mod_webapp back to life :) 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- Dan Milstein // [EMAIL PROTECTED]
Re: CVS / mod_webapp / web-connector sub-project
Henri, I think Dan is right on this one - improving the configuration of mod_jk is probably the most important thing, and merging with mod_webapp and porting it's protocol and config mechanism would be a good way to do that. I think the best way to do that would be a revolution ( like jasper34 ), and when it's ready propose it as either a replacement for both mod_jk and mod_webapp, or as a top level project ( if enough people will contribute on it ). Combining mod_jk and mod_webapp is likely to result in something better than both, so the vote to replace mod_jk and mod_webapp will be a formality :-) ( making it a top level project now is not a good idea right now, neither to do the development in the main tree - there are just few big bugs to be fixed before a 3.3 beta. ) Costin P.S. It's fun beeing a "revolutionar" ! On Wed, 18 Apr 2001, Dan Milstein wrote: In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile -- specifically, mod_jk was built to handle a variety of protocols (ajp12, ajp13, etc.). So writing a protocol handler for the mod_webapp protocol would give a lot of benefits -- load-balancing, support for a variety of web servers, debugged C code. Pier had mentioned a while ago that the mod_jk code was completely incomprehensible. Gal Shachor basically wrote his own object system in C, which is very, very confusing at first. I've added a lot of comments in the 3.3 branch, particularly to common/jk_service.h, with the explicit goal of making it easier for people to write new protocol handlers and/or new web server plugins. One thing I can imagine being a problem right off the bat would be that the abstractions which allow mod_jk to deal with a variety of web servers may not support the fine-grained control over configuration which mod_webapp supports. Splitting off a connectors sub-project: I don't think I support this -- it was discussed on the list a few months ago, and my objections from then still hold. Sharing session-information around: feels way too complex -- I think there are better ways to get persistent sessions. Overloading the (already-complicated) web server/servlet container communication stream seems like asking for trouble we don't need. -Dan GOMEZ Henri wrote: Fine to see mod_webapp back to life :) 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: CVS / mod_webapp / web-connector sub-project
GOMEZ Henri at [EMAIL PROTECTED] wrote: Fine to see mod_webapp back to life :) Well, I don't really know how happy I am... 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). That's what was expected, I believe 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) Wait until a release is tagged... 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. And I'll continue to be silent on that... As I don't really want to start another flamewar... I've been thru enough already on that, and all I can say is that I'll let the people on this list (but me) decide... Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? Make a proposal... The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Probably what you want to see is something more like mod_backend... Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). I don't see this as a viable solution... Storing session data within the web server itself is tricky, and definitely not what I would like to see, but I live up the decision to the list... How do you approach the case where multiple web servers are a front end to multiple servlet containers? I still doubt that storing sessions in the server does the trick... What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) The only solution I see is to have sessions shared on the back of the servlet container, and do the web server do its job (without loading up with too much crap) Pier (off to bed...)
Re: CVS / mod_webapp / web-connector sub-project
Pier P. Fumagalli at [EMAIL PROTECTED] wrote: GOMEZ Henri at [EMAIL PROTECTED] wrote: Fine to see mod_webapp back to life :) Well, I don't really know how happy I am... That sounds not right... I'm happy to have something working, I'm not happy about how we ended up there... (yeah... That's more like it) Pier (off to bed - for real...)
RE: CVS / mod_webapp / web-connector sub-project
3) You still didn't tell us what you think into merging mod_webapp and mod_jk. And I'll continue to be silent on that... As I don't really want to start another flamewar... I've been thru enough already on that, and all I can say is that I'll let the people on this list (but me) decide... How could you be silent on that since you're the only developper on mod_webapp ? I didn't see why a flamewar must start here. What we're discussing here is technic not politic, and it's an open and honest thread. mod_jk is the de-facto standard to link a web server (not only Apache) to tomcat. mod_webapp is really new and having it incompatible with mod_jk will raise more questions and requests than necessary. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? Make a proposal... The proposal is simple. Just remove all connector stuff, both native and java code from tomcat 3.3/4.0 tree and move it to another sub-project. As I said it will remove connectors questions from Tomcat list. Merging mod_jk and mod_webapp will help people switching from Tomcat 3.2.x to Tomcat 4.0 without changing anything from there webserver side. Many sites will strongly require to have a AJP12/AJP13 connectors in Tomcat 4.0 since they may have mixed Tomcats systems 3.x and 4.0 and we just can't demand them to just do the 'big bang' and replace their running mod_jserv/mod_jk by mod_webapp. the ajp12/ajp13 integration in Tomcat 4.0 is a pragmatic and realist choice. What about VOTE like : [ ] I want to have a ajp12/ajp13 in Tomcat 4.0 ? [ ] I don't want to have a ajp12/ajp13 in Tomcat 4.0 ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Probably what you want to see is something more like mod_backend... What's mod_backend ? Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). I don't see this as a viable solution... Storing session data within the web server itself is tricky, and definitely not what I would like to see, but I live up the decision to the list... How do you approach the case where multiple web servers are a front end to multiple servlet containers? I still doubt that storing sessions in the server does the trick... What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) The only solution I see is to have sessions shared on the back of the servlet container, and do the web server do its job (without loading up with too much crap) Did there is a project somewhere to store the session outside the tomcat ? A persistant session storage hosted in a web server may be bad but I'm ready to try other solutions Henri (Going Bed)
Re: CVS / mod_webapp / web-connector sub-project
on 4/17/01 5:12 PM, "GOMEZ Henri" [EMAIL PROTECTED] wrote: mod_jk is the de-facto standard to link a web server (not only Apache) to tomcat. mod_webapp is really new and having it incompatible with mod_jk will raise more questions and requests than necessary. Huh? mod_jk is not 100% compatible with mod_jserv which was also a "de-facto standard". [ ] I want to have a ajp12/ajp13 in Tomcat 4.0 ? Is the requirements of the Servlet API technically feasible for allowing this to exist? What's mod_backend ? He spelled it wrong... http://www.google.com/search?hl=enlr=safe=offq=mod_backhand Did there is a project somewhere to store the session outside the tomcat ? People have been talking about it for about a year now. It has been as successful at starting as the commons and CJAN projects. A persistant session storage hosted in a web server may be bad but I'm ready to try other solutions www.spread.org Unfortunately, the license sucks balls and the authors (very smart people) are waffling on going to a better (ie: BSD) license. I tried talking some sense into them at ApacheCon and felt like I was talking to a brick wall. Sigh. Some people take longer than others to see the light... -jon
Re: CVS / mod_webapp / web-connector sub-project
On Tue, 17 Apr 2001, Jon Stevens wrote: on 4/17/01 5:12 PM, "GOMEZ Henri" [EMAIL PROTECTED] wrote: [snip] [ ] I want to have a ajp12/ajp13 in Tomcat 4.0 ? Is the requirements of the Servlet API technically feasible for allowing this to exist? There are some very significant technical challenges that would need to be overcome for this to work. They relate to the fact that the Apache+Tomcat combination, as a whole, needs to behave in a manner consistent with the spec. A sampling of the issues includes: * Filters - You can define filter mappings in your web.xml file that cover static content as well as dynamic content. To be compliant, Apache *must* forward the static requests mapped to such filters to Tomcat for processing. * Servlet Mappings - The current 3.x connectors don't pay attention to servlet mappings in web.xml either. * Security Constraints - Likewise, you can define Tomcat-level security constraints that cover static content as well. Tomcat 3.2 (at least) totally blows those off, because it ignores web.xml entirely. * Welcome Files - In servlet 2.3 these can be specified by partial paths like "../index.html" or "foo/index.jsp" as well as just filenames. * Configuration complexity - The above issues can often be dealt with by tediously configuring everything twice (once in web.xml and once in httpd.conf). A better approach would be to make ajp12/ajp13 auto-configure Apache from the web.xml settings -- but mod_webapp already does that, so why reinvent that again? Craig
Re: CVS / mod_webapp / web-connector sub-project
On Tue, 17 Apr 2001, Jon Stevens wrote: mod_jk is the de-facto standard to link a web server (not only Apache) to tomcat. mod_webapp is really new and having it incompatible with mod_jk will raise more questions and requests than necessary. Huh? mod_jk is not 100% compatible with mod_jserv which was also a "de-facto standard". mod_jk is based on mod_jserv code, and ajp12 is the first ( and default ) protocol. It adds support for multiple servers and multiple protocols. BTW, mod_jserv is still supported and can be used interchangeably with mod_jk for ajp12. [ ] I want to have a ajp12/ajp13 in Tomcat 4.0 ? Is the requirements of the Servlet API technically feasible for allowing this to exist? Probably not for ajp12, it's an old protocol. Mod_jk supports multiple protocols anyway. Costin
Re: CVS / mod_webapp / web-connector sub-project
On Tue, 17 Apr 2001, Craig R. McClanahan wrote: * Configuration complexity - The above issues can often be dealt with by tediously configuring everything twice (once in web.xml and once in httpd.conf). A better approach would be to make ajp12/ajp13 auto-configure Apache from the web.xml settings -- but mod_webapp already does that, so why reinvent that again? Reinvent ? The issue was porting the configuration mechanism into mod_jk/ajp13 - i.e. merge the 2 connectors. mod_jk supports multiple web servers, can be fine tuned ( if you want to), and it's much more stable and flexible ( and at least it was developed as an open source project - with quite a few developers contributing and tuning it). mod_webapp has the auto-config of webapps - easy to port. Costin
Re: CVS / mod_webapp / web-connector sub-project
Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Creating a new project with the connector is probably a too big overhead. Much better would be to start a revolution ( in proposals), use the current code as a starting point and merge ( or modularize ) features. When it's ready - it can be proposed as a replacement to both mod_jk and mod_webapp. I would go one step ahead - and do this for both C side and java side. There are quite a few optimizations you can do by keeping those in sync, and it's very likely the result will be faster and better than any of the current connectors ( at least mod_jk was never optimized seriously, most work was put into the core and infrastructure ). In 3.3 the connector is just a regular interceptor - when the revolution is ready it'll be just a matter of config change. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. I'm not sure it's the most important problem to solve - easier configuration is probably more usefull for more people. But if you need such thing - mod_jk is modular enough. Costin
