avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: One Container Revisited
Date Mon, 01 Jul 2002 02:25:43 GMT

Stephen Haberman wrote:

>>If we had a default Tomcat, one just like the one now, everything
>>be fine.
>>Then, we could still have microTomcat
>>and embeddedTomcat
>>and a special cocoonTomcat
>>and a sandboxTomcat
>>and anything else we wanted, and the market would not see it as bad,
>>as a dilution of the brand.
>>The other Tomcats would probably be mostly ignored, but that is OK.
>If the other Tomcats would be mostly ignored, what's the point of
>spending precious volunteer developer time on them?

Bacause 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.

>>Just so long as there was one real banana. One Tomcat that always
>>the best, always was the default, etc. Just like the current Tomcat !
>Right...always worked, always the best...again why the need for others?
>I'm not familiar with the tomcat codebase, so perhaps they do have
>something like this, e.g. for prototyping future features or what not,
>but they hide it fairly well from the public. 

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.

>>So you can have your cake and eat it too. Just have a default
>>one with everything, that does everything, one that follows all the
>>rules. Lesser or special purpose containers wouldn't hurt a bit. You
>>might want to hide them from the main pages a bit, but that is a
>>different matter.
>>Because the only thing that is hurting Avalon right now is not knowing
>>which one to use, and not having one that is most perfect. Otherwise,
>>choice is not bad, just shows how powerful Avalon can be. Or at least
>>that is the way it seems to me.
>As a newbie, I'll certainly agree that there not being "the" Avalon
>container makes things confusing. And any movement to get to their being
>"the" Avalon container, I think is very awesome and I'm looking forward
>to the fruitions of all this discussion.

Even with the comments I've made above - I think this is possible by 
focussing on THE AVALON KERNEL and using that kernel as the source to 
run the container you need depending on the job you are doing and the 
needs that you have.

>But unless you have very valid, specific reasons for different container
>implementations, I don't see the point. I'll give you that Avalon is a
>different beast than the other Jakarta projects, but of all of the ones
>that I've looked at, none take the approach of multiple implementations
>of the same thing.

That's because we don't really know what the same thing is just yet. 
 Its comming together as we speak - but its becuase there are differnet 
ways of doing things that give us the perspective from which we can 
resolve the defintion of the "thing".

>I guess what I don't understand (and what you're going to have to
>explain to every other newbie early on, e.g. the front page of Avalon,
>if you want to avoid diluting Avalon's brand) is why you need separate
>container implementations? Assuming they all conform to the "spec,"
>what's the difference? 

I'll answer this from the point of view of Merlin/Phoenix.
Phoinix is like the current Tomcat - is the environment you would deploy 
a application in on a customer site - it takes effort to set-up, it very 
cool, very sophisticated, ans in effect the most mature and proven 
Avalon container in existance.  It also very heavy, very demanding with 
respect to setup and configuration, suck big time if you want to embed 
itinto something else.
Merlin - its like a single servlet execution engine - but runs 
components instead - can be executed as an ant task, as a main 
application, or as an embedded component - has lots of smart stuff so 
that you can run really complex applications with lots of inerconnected 
compoents with arbitary dependecy depth and you don't need to declare an 
assembly file or a configuration file - it just runs the sucker.
I use both Phoenix and Merlin - they are two very differnet 
propositions.  I use Phonix to run the server and inside the server I 
use Merlin as an embedded conment manager - and I also use Merlin in 
development just to run up a compent to test that its doing what it 
should be doing.  Setting up a test run in Phonix for a single component 
is a major PITA.

>If you guys really want to do multiple containers, I'd encourage them to
>be separate projects...e.g. on sourceforge or the like. I'm just
>thinking that if the containers are in fact different enough to warrant
>their own implementations of the spec, whatever features they add should
>be targeted to their own user community, not all of Avalon in general
>(as that's when you get the newbie-confusing lack of "a" Avalon

Personally, I would like to see a general collapsing of the existing 
container, evolution of the next few months of a container framework, 
container services, and container tools, and then, if necessary the 
reemegence of specific containers.  But as a result of that process - it 
will not matter which container you use because they will all play together.

>I just got through the "Developing with Avalon" doc and am understanding
>the framework and the basic idea of what containers should do. Read in
>config info and handle the boiler-plate instantiation of components when
>you request implementations for a given role.
>I haven't gotten to working with any given container implementation, so
>please excuse my ignorance if it's blatant.

Based on popular demand, I'll be uploading the pieces of a new container 
model that's focusing on the container framework/.service/tools 
seperation sometime in the next couple of days.  It's no where near 
complete - but it's solidly based on a common container abstration - 
containerkit.  If your interested in this topic it would be really great 
if you could go though even the javadoc - are the APIs making sence - 
does the documentation hand together - are there things in the code that 
break SOC - etc, etc. All of this is really valuable stuff.  Also, the 
containerkit package in Excalibur is a checkout target - it includes 
runnable demos and shows the current logic from kernel -> container -> 

>I did catch a tidbit that Fortress is a container for servlets? I've
>wanted to read up on Fortress, but the link is broken:
>Also, my initial reaction is that I don't know why a servlet environment
>warrants an entirely different container implementation? Again, I don't
>know anything about Fortress, but I would think if you really did have
>some differences in the servlet environment, they should be handled by a
>thin wrapper to "the" Avalon container. (Maybe you're already moving in
>this direction, I don't know)

I agree - it just that in getting down to "the Avalon container" what 
your realling getting down to is a container framework - and that's the 
thing that is still in development - and bnelieve me its not a totally 
stable target.

>Avalon is great, but I think you guys are getting a little overzealous
>with this spec, reference implementation, various specialized
>implementations thing. It works for Java specs...J2EE and what not where
>entire corporations devote lots of resources to various
>implementations...and even then, specializations are frowned upon as
>everything should be standard to the spec to prevent vendor lock in.

Problem is that we don't have the spec yet - and its not totally simple 
becuae the container "standard" spec effect the interpritation of what 
is component and that expands the issue and excalates dramatically the 
number of emails. :-)

>Corporations have the motive of making their implementation exactly
>standards complaint while being the fastest/most robust/easiest. Though
>really, they all want to be fastest, they all want to be the most
>robust, the all want to be the easiest. You don't see one corporation
>with multiple implementations, each striving for a different goal; they
>devote their resources to making their _single_ implementation achieve
>all of the goals. 

Via a formal spec - we don't have that formal spec.

>And this is what I think "the" Avalon container should do. Spend the
>resources striving towards achieving all of the goals, not splintering
>off various implementations focused on specific issues that just
>fragment the user community.
>As an open source Jakarta project, from a newbie's standpoint, I'd
>rather see all of your tremendous skill going towards keeping "the"
>Avalon container just that..."the" Avalon container that's robust enough
>that there is no need for specializations.
>Someone made the point that you guys discuss a lot more than other
>Jakarta projects because it's more theoretical work and comes down to
>little code in the end, just very well-designed APIs. So I can
>understand if you're looking for more code to write, but keep it
>experimental and away from the public's eyes until something ferments
>enough to become apart of "the" Avalon container.
>Anyway, I don't say too much as most of the time I am barely able to
>follow the discussions (due both to time and experience), but the
>multiple Tomcats argument just didn't make any sense to me (still a
>newbie :-).

I really appreciate the time you put into you message and the concerns 
you have expressed.  In principal I agree with the intention of what 
your saying - and in practice I think the "one solution" philiosophy is 
achievable - but its still early - stuff is cooking - experiments are 
ongoing - considation is already in progress - solution are comming - 
the holy grail is in sight!  

Cheers, Steve.

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


Stephen J. McConnell

digital products for a global economy

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