On 5/5/06, Rainer Jung <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
