Ugo Cei wrote: > > > Now, if we build the core on Spring now we have the same problem > > again. What if someone wants to use Avalon (uh!) for his > application? > > He'll instantiate some kind of Avalon container and maybe > bind it to the servlet context, so that any other component > that needs it can fetch it from there and do lookups etc. > > But that's not the point. The point is having components that > do not depend on the container. This means they are easier to > develop and easier to test. This also means that they might > be more easily moved from one container, but I sure hope this > is not going to happen *again*. > :) who knows - but agreed, the components should not depend on the container - but I would also like to have the possibility to use the container I want in my own blocks without loosing inter-block communications.
> > So, building an independent and *simple* core and making it > possible > > to use any container on the application level is imho a > very good way. > > In addition we could suggest to use Spring on the > application level, > > but we shouldn't enforce it. > > We should not make that easy. Doing that is just FS. I had the perception that this would be possible very easily - but perhaps I didn't listen very closely. Sure, you very easily hit the FS arena, that's why I think we should just use one container on the app level for Cocoon, but do not prevent people from using a different one in their apps. > We > shouldn't do anything that makes that *impossible*. As of > today, you can use Spring, PicoContainer, HiveMind, etc, from > within Cocoon without much of a hassle. Probably you cannon > host EJBs inside Cocoon, but hey, that's just a fucked-up > component model anyway. Yes, you can use all those containers today, but without any connection between ECM and them and that's imho bad. > > What we need to agree on is whether we will use Spring as a > starting point or not. I thought we had already agreed on > that at the GT but I was probably wrong. > I have nothing against at using Spring as a starting point, but there shouldn't be too much dependencies on Spring so we can remove them easily if we want to build our own core (and here I mean *if* not *when*). Carsten
