avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Haberman" <steph...@chase3000.com>
Subject RE: One Container Revisited
Date Mon, 01 Jul 2002 01:14:04 GMT
> If we had a default Tomcat, one just like the one now, everything
would
> 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,
nor
> 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?

> Just so long as there was one real banana. One Tomcat that always
worked
> 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. 

> So you can have your cake and eat it too. Just have a default
container,
> 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.

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.

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? 

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
container).

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.

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:

http://jakarta.apache.org/avalon/excalibur/fortress/index.html

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)

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.

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. 

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 :-).

Thanks,
Stephen



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


Mime
View raw message