tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: TC 6: What needs to be done?
Date Fri, 05 May 2006 15:21:00 GMT
On 5/5/06, Rainer Jung <> wrote:
> Hi,
> Remy started a thread talking about source tree reorg. It soon turned
> into a discussion about various integration questions.
> I would be interested in discussing a couple of questions concerning TC
> 6, most of them already came up during the last week. I hope it's not to
> much shortly before the weekend :)
> My focus is: do other commiters also think some of these things should
> be improved, and who would be willing to care about some of these topics.
> 1) Configuration Management
> ===========================
> My impreesion is, that to much configuration is hard-coded in RuleSet
> classes. Of course everyone can easily add properties to existing
> components, but adding subcomponents nedds changes in core RuleSet
> classes. Am I wrong? Should we change that to allow more complex
> subsystems handling their configuration rules independently of the core?
> One such example is the current stable clusster module.

IMO the entire server.xml and RuleSet should be deprecated, and replaced
with JMX. We could keep current server.xml around, for compat - but at
least not
extend it.

Even the very limited MLET syntax can support most of our needs.

RuleSets are just a way to set attributes ( == jmx setters ) and
define hierarchy
of componets ( == can be done based on JMX names, in a more dynamic way )

> 2) Deployer
> ===========
> Is it worth trying to implement a new deployer? I've no concrete design
> in my head now, but I had the impression, that although the current
> deployer works, there is an option that a redesign would make it more
> user friendly.
> 3) Manager
> ==========
> There is a lot of code duplication between the different Manager
> implementations. Some refactoring will help.
> 4) Core vs. Component Bundling, especially Cluster Module
> =========================================================
> What should be included in the core download. I'm not really talking
> about the code structure in subversion. It's the question of the right
> size of standard download. I think the current bundlings are OK, except
> that we have to decide how to handle the cluster modules. Any more
> module like things coming up?
> Concerning the cluster modules: I would propose to make both of them
> optional modules. For this to be easily usable one question will be,
> what the user has to do, to integrate his cluster download into the core
> distribution. At the moment, the cluster config for the stable version
> is already contained in server.xml. Here the discussion has a close
> relation to 1). I think it would help to be able to simply change the
> cluster module used via config/system property inside a core
> configuration and to configure the details of clustering itself inside a
> configuration object provided by the additional cluster module download.

+1 on making it optional. IMHO even things like JK could be an
optional component.

> 5) Default Cluster
> ==================
> Assuming that we will provide an easy way of switching between the
> implementations, we should decide on the default cluster module, when
> the time for the first 6.0 beta is coming closer. The main criterium
> then should be code stability for the new module.
> In every case we need to support usage of the old module with TC 6, so i
> think it needs to stay compatible. but we should clearly state, that the
> old module will no longer be actively developped and we should even
> deprecate it in TC 6, so we don't need to support it behind TC 6.
> 6) Timeline
> ===========
> How much we will change for TC 6 also depends on how much time we are
> willing to give it. Is there any time limit we should preserve, to
> deliver a JEE 5 web container not too far behind the standard approval?
> I assujme everyone wants TC 6 to show up before end of the year (beta),
> but how much earlier will it need to be available?

Not everything has to happen at once, and even less if we divert some optional
modules like cluster in separate components.

AFAIK the only requirement is the new API.

> 7) Build, Test
> ==============
> I think automated Gump builds should be helpful. Is there a need for
> more automted testing?
> Mnny questions, not so many opinions in this mail. But I think it's the
> right time to discuss about these topics to form a consensus about TC 6.
> - Rainer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
View raw message