cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart Molenkamp" <b.molenk...@bizzdesign.nl>
Subject RE: Startable components
Date Tue, 18 Oct 2005 09:50:13 GMT


> -----Oorspronkelijk bericht-----
> Van: Sylvain Wallez [mailto:sylvain@apache.org]
> 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.


Mime
View raw message