I keep having that feeling you don't even know what Avalon is. You just "don't like them" or something like that. Did you consider you could have something to learn "from them"?
Just asking! Have fun, Paulo Gaspar > -----Original Message----- > From: Remy Maucherat [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 21, 2002 5:07 PM > To: Tomcat Developers List > Subject: Re: Proposal draft for Tomcat 5.0 > > > Pier Fumagalli wrote: > > "Remy Maucherat" <[EMAIL PROTECTED]> wrote: > > > > > >>Nicola Ken Barozzi wrote: > >> > >>>Remy Maucherat wrote: > >>> > >>> > >>>>Hi, > >>>> > >>>>I'm committing a draft for a Tomcat 5 proposal. > >>>> > >>>>It is a draft, so it is not in final form yet (it needs feedback for > >>>>that). > >>>> > >>>>I'm attaching the document to the mail, in case people don't want to > >>>>checkout the repository. > >>> > >>> > >>>What about using Avalon as a framework? > >>>This way we would have a unified server environment, and > reusable server > >>>components. > >> > >>-1. > >>(I'm tired of replying to this) > >> > >>Avalon is the contrary of flexibility, so it will not be considered (at > >>least not by me). > > > > > > That's a JOKE right? > > Ok, so maybe my statement was too strong ;-) > > For all the things it gives you, Avalon is a framework, and makes you > feel like it. It imposes contracts between components / patterns, > packaging, etc. All things which aren't compatible with 5.0. And more > importantly, the API changes often, to the extent that all the projects > which use Avalon work off a specific snapshot, and don't upgrade > too often. > > Also, most of the utility provided by Avalon are available from the > commons without any string attached, and/or are of a better quality. > > There has been plenty of discussion on that with Paul, and during the > whole commons-logging incident, at which point I thought it would be > best if I didn't have anything to do with Avalon. > > OTOH, we could have optional Avalon wrappers again, as long as there is > someone to write them *and* maintain them when the API changes. So +0.1 > to work nice with Avalon, but -1 for basing the architecture on Avalon. > > Remy > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
