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 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
