Il giorno 16/ott/04, alle 13:28, Carsten Ziegeler ha scritto:
For a long time I was against writing our own container as I saw it simply as a waist of time/resources. But after just talking five minutes with Pier at the GT, I changed my opinion :) (Sometimes Pier can be really convincing).
Pier should have spent another five minutes trying to convince me ;-).
For a long time we use Avalon as the core container and this forces users to use this container for their applications as well. Sure it is possible to use Spring, it might be possible to use others as well, but it's not that easy and straight forward.
Sigh, I though I had shown in my presentation that it is quite easy and straightforward indeed :(.
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*.
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. 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.
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.
Ugo
-- Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
