> -----Oorspronkelijk bericht----- > Van: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Verzonden: dinsdag 18 oktober 2005 10:18 > Aan: dev@cocoon.apache.org > Onderwerp: Re: Startable components > > Carsten Ziegeler wrote: > > Bart Molenkamp wrote: > > > >> Why are marker interfaces preferred over this configuration style? > These > >> interfaces introduce another dependency on Avalon. I think it is better > >> to not have these code dependencies, but to use configuration. This > >> makes it easier to host those components in other containers as well, > >> such as Spring. Same for the ThreadSafe marker interface, the > >> Initializable and the Disposable interfaces (configure a method to do > >> initialization/disposing of the object instead of implementing an > >> interface). > >> > >> And I thought that people here rather move away from Avalon's > >> interfaces. Then why introduce another dependency on it, when > >> configuration can do the same? > >> > >> > > Yes, I tend to agree with you. So let's forget about the new interface > > and use the preload flag. > > > > With 2.2 you can configure an init method, a dispose method, the type of > > the component (thread safe, poolable) in the cocoon.xconf and you don't > > have to use the interfaces anymore. Upto now we are just not using it. > > > > And I don't think we should be using it. As said in my previous post, > Avalon has always used interfaces to specify the lifecycle. Moving this > information in the configuration brings the responsibility of defining > the lifestyle to configuration writers that up to now never had to care > about it. Also, most of them don't understand all the details or > implications of these settings. > > That's the exact reason that led us to support automatic preloading with > maker interfaces. > > Other containers such as Spring chose another way by requiring > everything to be specified in the configuration file (autowiring not the > default and its use is not really encouraged [1]). These containers > bring a lot of interesting features which is why we integrate them in > Cocoon, but require configuration writers to know a lot more about the > details of components. > > Considering that many or our users aren't J2EE developers, my opinion is > that by default, system-level Cocoon components should be as simple to > configure as possible, i.e. people should only have to care about > settings, but not lifecycle or wiring. > > Sylvain
I understand that both the configuration and the marker interface options are working, great. But I'm still not satisfied by your answer, sorry. My points: 1. I don't see that much difference between a developer and a configuration writer. Knowing the configuration settings of a component can also require (deep) knowledge about the implementation. And, configuration writers don't need to write the configuration from scratch, the already configured defaults are sufficient. 2. To configure a component, knowledge about it is required anyways. Looking at the configuration of CForms for example, there is quite some configuration, but not much for a regular user to change (all those builders etc - which I think is great that it is configurable). For regular Cocoon users, I think the default configuration that comes with a Cocoon build is sufficient in many, many cases (again, I don't think users write configuration files from scratch). 3. There is a dependency on Avalon, a project that is closed, and this project wanting to move away from it (at least that is my impression). This doesn't encourage me to use the Avalon interfaces, it rather "scares" me to use them. Configuration gives me much more feeling that I'm not tied in to Avalon, and can migrate to another container with less effort. 4. The way I learned to write components is by looking at the sources of Cocoon. So shouldn't the code show how it is supposed to be (for new and/or recently updated components), instead of how it always was? Thanks, Bart.
