> From: Michael Nash [mailto:[EMAIL PROTECTED]]
>
> No question that the one-size-fits-all container would
> *internally* be quite complex. But then again a J2EE server
> is a pretty complex beast, and most people don't ever want to
> see the insides of it...
And that is why I figured that three containers sharing a common
core set of libraries would be easier to maintain and understand,
than three superimposed containers controlled by a massively
complex configuration (turn feature foo on? yes/no? Witness EJB
deployment
descriptors and configs.).
Granted, the user would not have to understand it, but I fear that
we do not have the capability to build and maintain such a beast.
Keeping *both* sides (container writer / container user) simple is
another goal... Too much complexity in the container -> crap container
-> implosion.
I agree that the above argument may sound like a non-argument ("we can't
do that because, well, we can't do such things") and I have no proof
that
three containers with common core set of libraries is simpler, it is
just what I as an Avalon developer suspect.
If anyone fancies trying it though...
/LS
> Leo:
>
> At the risk of sticking my oar into the moving waters :-)....
As far as oars are concerned, I'm +1 on water.
(Seems vastly preferable to any other place you can stick it. :))
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
