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