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
