It is interesting to see the discussion on "Avalon". Avalon itself is actually pretty small. However, when you add on Excalibur it becomes much larger. I'm never clear when the discussion is about Avalon whether the discussion is really about Avalon or Avalon + Excalibur.
Not that I'm against switching to another container, its just that I thought Avalon was originally born from Cocoon in the first place. What is ironic is things like the Source Resolver that used to be cocoon classes are now Excalibur classes. I think a major problem is that the "container" (i.e. Excalibur) has just gotten way too large. IMO it should be about managing the lifecycle and pooling of components and nothing else. It seems pretty obvious though, that there are two contrasting issues here: 1. Cocoon's charter is not to be a container. Having an internal container implementation violates this idea. 2. Cocoon is very vulnerable to container issues because it doesn't "own" the code. Furthermore, a container may not exist that supports Cocoon's needs. Personally, I think the path that has been proposed is probably as good as any other. Sure, it will have negative consequences, but so do all the other options. However, I would make sure that other available frameworks cannot be leveraged to some degree before doing the whole thing from scratch, but that is just me. Ralph -----Original Message----- From: Hamilton Verissimo de Oliveira (Engenharia - SPO) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 12:44 PM To: [EMAIL PROTECTED] Subject: Re: [RT] On building on stone -----Mensagem original----- De: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > IMHO the current perception that Cocoon is a "big thing" is largely due > to the complexity imposed by Avalon, Sorry. Can't agree with that. Avalon was born from Cocoon codebase. What was imposed to Cocoon? Its should be the opposite. > and this will go away with a > simpler container framework. We'll just have to adjust our user's > perceptions once this is realized ;-) Hey, wait a minute. You're about to create a container that will support _hot deployable dynamic polimorphism_ and this will be simpler than ECM? I'd like to see that. -- hammett
