Would it be suitable to focus on JEE 5 compliance in the short run for a soon to be released TC 6, then enhance the value adds of TC for a 6.1 release later this year?
>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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
