> There is only one person that gains from code that isn't componentized, > and that is the author. Ego drives open source, and pride is it's > currency. This is how it should be, but for everyone else, PITA.
There's not just ego. There is also need. Where there is need, ego should shut up. ** JMX and Avalon Framework *** > This is where I disagree with the XP rule that you don't plan for > re-use. You DO plan for re-use, and JMX and/or Avalon is the logical way > to do take Apache to the next level. Not JMX. (...) > If only I could figure out whether the JBOSS approach of JMX and hot > pluggability, or the Avalon approach was the better of the two. Or is > this another case of un-necessary confusion on my part? it is. JMX is a tool for communicating with an application, and especially a tool for communicating runtime management decisions. JBoss uses JMX as tool for runtime communication between application components. There is no design, no hierarchy, no control, no inversion of control, etc. It is, in a sense, a BigBallOfMud. When you re-add design, hierarchy, control and centralisation you either create a container-component hierarchy (Avalon ComponentManager concept), a registry (JNDI-style) or a complex 6th gen (or so) flow-based event system (ie SEDA). How easy is it to take an arbitrarily small piece of JBoss, stuff it in a jar, then re-use it? How easy is it doing the same for a piece of Excalibur? JMX is not a replacement for the stuff Avalon Framework does. It can be a useful tool for managing (in the sense of runtime interaction between person and machine) avalon-based components and applications, which is facilitated by Baxter. *** Avalon and the rest of the world *** > My 2c: You guys don't know how cool it is what you got. If it ever hit > you what the possibilities were, and all Apache projects were > componentized as a first step, you would be overwhelmed with the > potential, and so would the rest of Apache. yes. 'We' know. 'They' don't. Convicing 'them' that moving to embrace Avalon is a good thing is very hard. If you even try and mention something like this on the Tomcat list someone will jump on your neck because he will be very offended. try "this and this bit of tomcat needs refactoring so interface and implementation are split" and you'll likely get shot by some. If developers do not agree the patterns avalon promotes are a good thing, well, what's left to do? Show by example, probably. This sounds bitter, but I'm not. I understand that the mind shift towards the avalon concepts is as difficult as the one from procedural to OO for some. These concepts will make it elsewhere, eventually. > Why isn't Struts Avalonized? ego. Disbelief. Large-scale mind shift neccessary. large-scale code rewrite neccessary. Using avalon means quite a bit of refactoring in many places. Many people have an objection against this refactoring. This is a natural human reaction. What's the quote you used to have in your tagline again, pete? > etc. Duplication? It would be hard NOT to resolve the duplication > problems if Apache was Avalonized, because when you got to duplicate > functionality, there would be this elephant in the living room that had > to be dealt with before moving on. So MUCH duplication. Hell, it's not > duplication, it's out and out competition. My thing is better than your > thing. and certainly bigger! ;) Avalon was specifically conceived, a long time ago, to provide a common framework for all java projects to benefit from. However, the newer projects that got added didn't move over to avalon, or invest in avalon. So we have quite a few frameworks now, decoupled or not. --- I recognise your reaction as similar to mine when I got introduced to Avalon. I use parts of Avalon in all programming I do. When I'm not programming java, I at least use the underlying thought and design patterns if at all possible. I'd like to use parts of Avalon in all software. The world would be better if the java language was rewritten to support AOP, COP, IOC, etc much more directly. I see this, I believe this. Not everyone does, which is understandable. They'll come round. A we-are-the-borg attitude isn't going to help, so I'm rather quiet about this. "Quick, convert all your projects to avalon! The faster we get a solid COP framework in Jakarta the better of we will all be. Forget the days where programming for reuse was difficult. Forget code duplication, decoupling and packaging worries...now, Avalon will do all of that for you. Avalon is the next killer software design concept, like OOP was. Everyone should install and use it." I just don't think it'll work ;) cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
