cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Startable components
Date Tue, 18 Oct 2005 08:18:19 GMT
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

[1] 
http://static.springframework.org/spring/docs/1.2.x/reference/beans.html#beans-factory-autowire

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message