RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Mon, 7 May 2001, GOMEZ Henri wrote: [snip] In TC 4.0, I think about the excellent works from Bip Thelin (TC 4.x Clustering). What make it specific to TC 4.x ? Here lies the crux of the difficulties in sharing significant code (beyond the kind of stuff you suggested for toolbox). I will try to provide some objective answers to this question -- there's plenty of subjective answers already available :-). * Dependence on the internal architecture of Catalina (i.e. the internal representations of Session, Manager, and so on). As has been clearly documented, this architecture is based on very different principles than 3.3 -- trying to create adaptators across these world views seems pretty challenging, and it would slow down 4.0 development for no apparent gain. * Dependence on Java2 as a base platform. This is not just an issue of using the collections classes (although that's part of it). Consider a few other issues: - If you run Tomcat 4.0 under a security manager, you have to put privileged blocks around some code segments. In order to make Tomcat 3.x run under JDK 1.1, you have to layer all of that stuff into optional classes that are used only in a Java2 runtime -- in 4.0 you can just code them directly. - As Commons matures, I'm going to be proposing switching to the Commons version of many standard utility classes. Many/most of these have Java2 dependencies. The same is true for lots of other external packges we might want to reuse. - Performance tuning for Java2 JVMs (particularly HotSpot) focuses your attention on different areas than JDK 1.1. Trying to optimize for both increases the effort required, and could lead to conflicts where you want to do things differently on different platforms. Working around Java2 dependencies is possible, but (again) is a very substantial amount of work. Where's the benefit? In contrario, why mod_jk from TC 3.3 couldn't be used in TC 4.x ? That's more feasible, but it also has a different set of issues: * Configuring the current generation of web connectors causes 90% of the user gripes about Tomcat. Anyone who needs evidence should subscribe to TOMCAT-USER and start answering all the questions about configuring. * The design assumption of the current generation of web connectors is that Apache will serve the static content. Unless the sysadmin is VERY careful in their configuration, this leads to violations of the servlet spec when static content is protected by a security constraint (2.2 and 2.3) or when filters should be invoked on static content (2.3). These problems are fixable -- but it's just a lot more work than simply porting a connector. Also shareable are all objects related to HTTP (cookies, messages, headers, ). Having smaller CVS, will also encourage new commiters contributing in area where they could be more at ease. Per my previous post, consider Commons for stuff that is not Tomcat specific at all. There are some very interesting developments on this directions with mod_jk and jasper. Focusing in this kind of thing is quite productive and puts some of the 3.3 people cooperating in the development of the 4.x version and vice versa. +1 I strongly think that merging the best of 3.3 and 4.0 could make an incredible Tomcat 5.0. Having Costin and Craig in the same team may be a dream but frankly what a bright combinaison. That's the way things were when I joined Sun 14 months ago. Costin opted to switch to a different project. Let's start by sharing what could be done, it will help identify what's the core and what could be modules (in reference to Apache http server no politics here :). Using 4.0 Valves and 3.3 modules didn't seems incompatible. There is many modules in 3.3 which are not related to Request/Response... Trying to force one of the groups out of its way will just fragment this project and take the 3.3 people somewhere else (SourceForge or so). Not sure it will force people to go somewhere else. Some may be just tired of political problem and stop contributing to ASF. That will be bad news for both groups, and there will be no winner in that case, the looser will be the OpenSource spirit. Besides developers and their own itches, there is another group whose interests ought to be considered - USERS of Tomcat. If you don't have any, then it becomes a much less interesting project to work on. And we've done a pretty good job at confusing people about what the Tomcat road map is. If the user community were to abandon Tomcat, it wouldn't matter much what we do on the development side. There isn't any compelling benefit (to the user community) to have two active development branches, once the next generation branch matures. The 4.0 container code is pretty stable (letting us focus now on performance improvements and feature adds). We could have had mod_jk ported a
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Mon, 7 May 2001, Craig R. McClanahan wrote: There seems to be consensus growing around these three names. Does that meet with everyone's agreement? If so, I can create the new repositories and set up the permissions stuff later today. +1 ( Regarding the name for the third: +0.7 for tomcat-contrib +0.5 for tomcat-toolbox -0.1 for tomcat-modules -1 for tomcat-sandbox ) PS: Just a note on toolbox -- if the stuff that might go here is independent of Tomcat itself, you might think about making it a Commons package instead of a Tomcat package. You'll find several other useful goodies already there. I think something like the web-based build tool or various modules ( i.e. things that work as interceptor or valves - with most of the code common to 3.x and 4.x ) should be toolbox-based for now. For utils - commons is the target destination, but I personally don't have too much time to spend on it. Costin
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Mon, 7 May 2001, Craig R. McClanahan wrote: * Dependence on Java2 as a base platform. This is not just an issue of using the collections classes (although that's part of it). Consider a few other issues: Once again - there is no problem with using Java2 for tomcat modules in 3.x. Tomcat3.x already has java2 modules - and it allways had. The security manager, setting the thread class loader, etc - all those are Java2 features, and we allways had them. The only requirement is not having java2 in the core, and providing a functional servlet container that works on Java1.1. That's done, and there's no plan to change the existing modules (except fixing bugs), so the goal of supporting 1.1 in 3.x shouldn't be a concern for anyone writing new modules. Costin P.S: my latest hobby is J2ME - and if I'll be able to get this voted I would like to do some changes to make sure tomcat3.x works fine on j2me - there are few changes and few additional restrictions. If not - it'll be a private patch to tomcat. (Check ibutton.com and tini, it's cool.) But again, that doesn't affect in any way existing modules - just the core, and an additional set of modules that will be specialized for the device.
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
- Performance tuning for Java2 JVMs (particularly HotSpot) focuses your attention on different areas than JDK 1.1. Trying to optimize for both increases the effort required, and could lead to conflicts where you want to do things differently on different platforms. Well, tomcat3.x was never optimized for JDK1.1 ( or for any JVM for that matter ). Most optimizations are classical lazy evaluation, good memory management, avoid duplicated operations, etc - most of the stuff isn't even specific to java. The only important thing about Java2 and performance is the collections, weak references, etc - and the plan is to take full advantage of all those features in new modules ( after 3.3 is released ). As I said few times - the focus so far has been on core and modularity - not on individual modules ( few modules have been rewritten - for clarity mostly ). The only exception is the http module, which was slightly tuned ( mea cupla for that :-) Costin Working around Java2 dependencies is possible, but (again) is a very substantial amount of work. Where's the benefit? In contrario, why mod_jk from TC 3.3 couldn't be used in TC 4.x ? That's more feasible, but it also has a different set of issues: * Configuring the current generation of web connectors causes 90% of the user gripes about Tomcat. Anyone who needs evidence should subscribe to TOMCAT-USER and start answering all the questions about configuring. * The design assumption of the current generation of web connectors is that Apache will serve the static content. Unless the sysadmin is VERY careful in their configuration, this leads to violations of the servlet spec when static content is protected by a security constraint (2.2 and 2.3) or when filters should be invoked on static content (2.3). These problems are fixable -- but it's just a lot more work than simply porting a connector. Also shareable are all objects related to HTTP (cookies, messages, headers, ). Having smaller CVS, will also encourage new commiters contributing in area where they could be more at ease. Per my previous post, consider Commons for stuff that is not Tomcat specific at all. There are some very interesting developments on this directions with mod_jk and jasper. Focusing in this kind of thing is quite productive and puts some of the 3.3 people cooperating in the development of the 4.x version and vice versa. +1 I strongly think that merging the best of 3.3 and 4.0 could make an incredible Tomcat 5.0. Having Costin and Craig in the same team may be a dream but frankly what a bright combinaison. That's the way things were when I joined Sun 14 months ago. Costin opted to switch to a different project. Let's start by sharing what could be done, it will help identify what's the core and what could be modules (in reference to Apache http server no politics here :). Using 4.0 Valves and 3.3 modules didn't seems incompatible. There is many modules in 3.3 which are not related to Request/Response... Trying to force one of the groups out of its way will just fragment this project and take the 3.3 people somewhere else (SourceForge or so). Not sure it will force people to go somewhere else. Some may be just tired of political problem and stop contributing to ASF. That will be bad news for both groups, and there will be no winner in that case, the looser will be the OpenSource spirit. Besides developers and their own itches, there is another group whose interests ought to be considered - USERS of Tomcat. If you don't have any, then it becomes a much less interesting project to work on. And we've done a pretty good job at confusing people about what the Tomcat road map is. If the user community were to abandon Tomcat, it wouldn't matter much what we do on the development side. There isn't any compelling benefit (to the user community) to have two active development branches, once the next generation branch matures. The 4.0 container code is pretty stable (letting us focus now on performance improvements and feature adds). We could have had mod_jk ported a long time ago if someone wanted to work on it then (as they are apparently willing to now). In due time, the usual survival rules will tend to favor the solution that proves to be the best and everybody will work together again... until the next revolution. A sort of 'Software Darwinism' and species adaptability. Craig
Re: [PROPOSAL/VOTE] New Repositories for Collaborative Development
+1 for separate repository, but I preffer jakarta-tomcat-modules or some common repository. Reason: connector and jasper are just particular modules that could be used in multiple versions of tomcat ( like 3.2, 3.3, 4.0 or 4.1 ). There are other pieces that could be developed in the common repository. If you want, we can have all 3 ( connectors, jasper, modules ) - but I would really want a repository to replace the current /proposal and be usable in multiple tomcat versions. For example the JAAS auth, the logger ( that would be really needed in 3.2 for example ), and maybe even the build tool. Costin Over the last few weeks, there has been a lot of discussion on collaborative development, across the various Tomcat branches, on two major areas: * Web connectors * A new Jasper (the jasper34 proposal) and efforts have begun in the HEAD branch proposals directory of the jakarta-tomcat repository. I'd like to propose a slightly different approach -- create two new repositories (perhaps jakarta-tomcat-connectors and jakarta-tomcat-jasper) to be the homes of these development efforts, independent of any of the existing code bases. The reasoning for this approach is as follows: * Avoid any appearance of politics or attachment based on which repository the code is hosted in * Make it easier to enforce the technical separation of this code from any existing Tomcat base code (you have to declare external dependencies pretty directly) * Avoid the need for everyone working on these shared components to have *all* of the Tomcat code on all branches checked out all the time -- you can focus on the repository for your favorite Tomcat plus the common stuff you care about * Smaller CVS repositories means faster CVS checkouts for everyone on daedalus, on all projects Because these repositories would both be part of the overall Tomcat subproject, all existing and new Tomcat committers would have commit access to both of them, just as we all have access to jakarta-tomcat and jakarta-tomcat-4.0 today. Comments? Questions? Votes? Craig McClanahan
Re: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Fri, 4 May 2001 [EMAIL PROTECTED] wrote: +1 for separate repository, but I preffer jakarta-tomcat-modules or some common repository. Reason: connector and jasper are just particular modules that could be used in multiple versions of tomcat ( like 3.2, 3.3, 4.0 or 4.1 ). There are other pieces that could be developed in the common repository. If you mean 'modules' in the general sense of a shareable component (so that it would include interceptors for 3.2 and valves for 4.0, for example), I don't care much about the name, although your particular choice doesn't avoid the political appearances issue. If you mean 'modules' as in something that implements the 3.3 apis for modules, be my guest -- but that makes it pretty useless to many. (3.3 apis are irrelevant to anything I'm interested in, for example.) If you want, we can have all 3 ( connectors, jasper, modules ) - but I would really want a repository to replace the current /proposal and be usable in multiple tomcat versions. For example the JAAS auth, the logger ( that would be really needed in 3.2 for example ), and maybe even the build tool. I've said it before, and i'll say it again -- 3.2 is in maintenance mode, and doesn't need any further focus for enhancements. Time spent providing enhancements there would be better spent focusing on its replacement. Costin Craig
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
Over the last few weeks, there has been a lot of discussion on collaborative development, across the various Tomcat branches, on two major areas: +1 for the split. * Web connectors * A new Jasper (the jasper34 proposal) and efforts have begun in the HEAD branch proposals directory of the jakarta-tomcat repository. I'd like to propose a slightly different approach -- create two new repositories (perhaps jakarta-tomcat-connectors and jakarta-tomcat-jasper) to be the homes of these development efforts, independent of any of the existing code bases. The reasoning for this approach is as follows: Did these CVS will be like the jakarta-servletapi and jakarta-watchdog ? * Avoid any appearance of politics or attachment based on which repository the code is hosted in Yes, please. * Make it easier to enforce the technical separation of this code from any existing Tomcat base code (you have to declare external dependencies pretty directly) +1 * Avoid the need for everyone working on these shared components to have *all* of the Tomcat code on all branches checked out all the time -- you can focus on the repository for your favorite Tomcat plus the common stuff you care about Thanks, porting mod_jk native patches in all TC branch is really time consuming and subject to problems. * Smaller CVS repositories means faster CVS checkouts for everyone on daedalus, on all projects It was slow today... Because these repositories would both be part of the overall Tomcat subproject, all existing and new Tomcat committers would have commit access to both of them, just as we all have access to jakarta-tomcat and jakarta-tomcat-4.0 today. Comments? Questions? Votes? Again +1
RE: [PROPOSAL/VOTE] New Repositories for Collaborative Development
On Fri, 4 May 2001, GOMEZ Henri wrote: Did these CVS will be like the jakarta-servletapi and jakarta-watchdog ? The would be like jakarta-servletapi and jakarta-watchdog in the sense that whey would be separate CVS repositories (with a separate checkout). They would be unlike Watchdog (at least), because the committer list would be shared with jakarta-tomcat and jakarta-tomcat-4.0 -- all Tomcat committers have access to all Tomcat repositories. Several other projects are adopting this approach as well -- for example, Ant has split off the development of the Antidote GUI into its own CVS repository. Craig
Re: [PROPOSAL/VOTE] New Repositories for Collaborative Development
+1 Craig R. McClanahan wrote: Over the last few weeks, there has been a lot of discussion on collaborative development, across the various Tomcat branches, on two major areas: * Web connectors * A new Jasper (the jasper34 proposal) and efforts have begun in the HEAD branch proposals directory of the jakarta-tomcat repository. I'd like to propose a slightly different approach -- create two new repositories (perhaps jakarta-tomcat-connectors and jakarta-tomcat-jasper) to be the homes of these development efforts, independent of any of the existing code bases. The reasoning for this approach is as follows: * Avoid any appearance of politics or attachment based on which repository the code is hosted in * Make it easier to enforce the technical separation of this code from any existing Tomcat base code (you have to declare external dependencies pretty directly) * Avoid the need for everyone working on these shared components to have *all* of the Tomcat code on all branches checked out all the time -- you can focus on the repository for your favorite Tomcat plus the common stuff you care about * Smaller CVS repositories means faster CVS checkouts for everyone on daedalus, on all projects Because these repositories would both be part of the overall Tomcat subproject, all existing and new Tomcat committers would have commit access to both of them, just as we all have access to jakarta-tomcat and jakarta-tomcat-4.0 today. Comments? Questions? Votes? Craig McClanahan -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
