avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Carapetyan <p...@datafundamentals.com>
Subject Re: One Container Revisited
Date Mon, 01 Jul 2002 03:16:35 GMT
Stephen McConnell wrote:

>> If the other Tomcats would be mostly ignored, what's the point of
>> spending precious volunteer developer time on them?
> Because the types of container that exist today are in general 
> addressing very differnent problmems.  Phoenix is an app-server that 
> runs an application where an application is defined as a package of 
> components, supporrting resources and assembly directives - Merlin is 
> a component runner that just runs up a component + all of its 
> dependents - greate for development and massively simplified 
> deployment. Fortress is focussed on simple components (relative to 
> dependencies) bu provides better support for stuff relating to pooled 
> components. All of the containers listed here represent end-points in 
> the deployment cycle - Merlin II is addressing the issue of a 
> container that is a component in another container's idea of the 
> word.  The point in spending the time is that we are sorting this 
> stuff out - what is container - what should a minimum container be - 
> how to seperate container operation form functionality - multiple 
> contains mean we have validation of differnent approaches based on 
> different objective.

And that paragraph just about says it all for me. Jeez Louise. Is this 
complexity for the sake of complexity or am I just going cookoo? I'll 
second Haberman's motion that good design means a second version is not 
warranted in most circumstances.

But wait, this next paragraph is even better.

> Thin what an improvement it would be if you could write an ant task 
> that automatically executed your single servlet class - did the 
> compilation of the JSPs, did the context management stuff - and 
> provided lots of debugging info - then imagine that Tomcat had another 
> tool - a tool to runup the entire packaged web app and let you 
> validate things in a context closer to deployment - then imagin a 
> third tool Tomcat itself where you run you web app in a mixed 
> environemt with other applications - and still as an ant task - still 
> wioth lots of debugging information - and then finally, imagine a the 
> final refernce Tomcat - the thing that runs your application out in a 
> customer environment.  Tomcat does not deliver this - Avalon can. 

You forgot to mention the new college degree program in Avalon. Complete 
with 17 courses of instruction, and four equal department heads to 
compete against each other on which one was the real path to the holy 
grail.  But it's a six year program, couldn't get it done in four.

The reason Avalon is complex is that committers get a great deal of 
personal satisfaction from making it complex. The only thing that could 
be better would be to make it even more complex. Wait ! Here's a new 
feature with 3 new permutations. Let's add that too! No, let's start a 
whole new container. That's the ticket! Or should it be 3, one for each 
permutation? Hmm.

Do one thing. Do it well. Avalon is about good engineering, not more 
engineering. There is a difference.

Really of course, it is all fine because every committer get's to do 
what he wants. Just thought a good rant would be in order.

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