avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [OT] Jakarta: keeping track of it all
Date Thu, 02 May 2002 12:53:55 GMT
> 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,

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


- Leo

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message