cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: recommended way to keep local config modifications separate from Cocoon distributions
Date Wed, 26 Sep 2007 20:27:50 GMT
Lars Huttar pisze:
> I appreciate the recommendation. I will be interested to look into
> Cocoon 2.2.
> However, production applications for our organization are running on
> Cocoon. Can I justify the risk of using an alpha version of Cocoon for
> production apps?

It's certainly not in alpha state, it has beta status for some time and there are people having
apps on top of 2.2. You can search archives of this list for people sharing their experiences.

> Is Cocoon 2.2 to be released soon? (I found a blog entry from Sylvain
> from March 2005 saying "it's very likely that the pressure will grow for
> a release in the coming months...")

That shows we are bad at informing about our work but this is really going to change because
we will
switch to new site publishing mechanisms that make it a hell easier to update Cocoon site
and keep
everything relevant.

The truth is that Reinhard Pötz is just about pushing Cocoon 2.2 RC2 and we are seriously
about releasing final 2.2 quite soon.

> Also, does Cocoon 2.2 have sufficient documentation (both in general,
> and regarding configuration handling)? Can you point me to documentation
> on configuration handling?

I recommend to start with this[1] tutorial that will give you basic idea of real blocks that
introduces. When it comes to configuration handling, there is no one big cocoon.xconf file
any more
and Cocoon's configuration is handled by Configuration[2] subproject (completely separate
Cocoon when it comes to dependencies). The most important part that makes real work of handling
configuration is Spring configurator[3].

Thanks to Spring Configurator you can alter any existing configuration file (Spring bean definition)
by using properties following some conventions. When it comes to extension points listing
some other
component (datasources, custom Forms widgets and so on) Spring Configurator offers very powerful
bean-map that allows to collect all beans implementing particular interface dynamically so
there is
no central point of configuration that would have to be altered when new implementation arises.



Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message