Gianugo Rabellino wrote: > > I'm definitely not a fan of constructor injection, exp. when we > consider how (way too) often we resorted to inheritance in Cocoon > components. Now, while interface injection is clearly out of fashion, > sticking with Avalon/Excalibur also means that it would be difficult > to get around the container (e.g., how do you release components with > your approach? I assume Excalibur still kinda needs that). > Yes, Excalibur still needs it - but it's easy. Bascially, you "emulate" the service() method on construction of the object and then you "emulate" the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor.
> >>But I think it can even get easier: >>1. Let's just assume that every component is ThreadSafe - unless >>otherwise stated - no need to declare the interface anymore. I think >>apart from the interpreter most components are threadsafe or poolable >>anyway. > > > Again, until Avalon is around I don't see how a marker interface can > really bug you... It's not the marker interfaces itself - it's just the amount of code I have to write. For example, the initializable interface is great - in other component frameworks you have to configure the init methode somehow which is imho too much work and makes configuration your application too complicated. > > >>2. Let's remove support for pooled components - yes, seriously. Fiddling >>with the pool sizes is really annoying. We have a working factory >>approach for sitemap components, so why not simply use it overall? And >>rewriting the remaining pooled components shouldn't be that hard. (I now >>that we are proxying pooled components to simplify the lookup, but you >>still have to configure pool sizes). > > > I'm also still not completely sold on factories. Indeed, they work and > they're a brilliant solution, but am I the only one smelling hack and > workaround? > Hmm, don't know :) I don't see a hack/workaround in using factories instead of using pooled components? If we would use other component containers we had to do this anyway. And yes, we have to/want to move away from Avalon - using constructor injection, removing pooling etc. makes this easier in smaller steps. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
