Archive for July, 2007

Spring Configurator

July 13, 2007

In Apache Cocoon we have several subprojects that can be used completely outside Cocoon scope. Roots of these subprojects are of course in Cocoon, we needed solutions for our own problems. Then it turned out that some pieces can be generalized and isolated from Cocoon’s code and concepts. One of such projects is Cocoon Spring Configurator. See it’s introduction page to get overall idea of what functionality it brings.

My own opinion is that Spring Configurator may be handy to everyone who develops nontrivial applications utilizing Spring framework. As the names suggests its main function is to deal with configuration of your apps and it does its job very well! I’ll show you an example of bean-map functionality that I like most.

It’s very common case that you have several implementations of some interface; each one identified by some name. I had such a case in Cocoon, recently. I wanted to let people define database connections as Spring beans so they could be used in every Cocoon component. I’ve created Spring bean with following property:

private Map springDataSources;

and configured it that way:

<beans xmlns=""
  <bean id="..." class="...">
    <property name="springDataSources">
      <configurator:bean-map type="javax.sql.DataSource"/>

I’ve cut down details that does not matter here. As you can see, Configurator takes a burden of creating Map of beans implementing javax.sql.DataSource interface that is passed to our bean. The key for every entry in the Map is bean id (but it can be something else, e.g. property of a bean).

Example above is not rocket science but I find bean-map functionality very handy. In a fact, Spring Configurator can do a lot of more but it’s not a point to replicate what’s already in the documentation. At the end, I advise you to take a look at this hidden treasure; it’s very light-weight and has small number of dependencies.


First results of GSoC work

July 7, 2007

Finally, besides discussing, I have done some real work as GSoC participant. I have successfully moved expression handling code to separate modules (api and impl) so they are not tied to template handling code. Next important thing was getting rid of Avalon dependencies. Believe me or not, but such a conversion is not that scary and if you grasp basic principles it’s really a matter of labour work.

If you want to check in detail what has been changed, check this issues:

  • COCOON-2082 – Get rid of Avalon dependencies in cocoon-expression-language code
  • COCOON-2081 – Move api and implementation of expression languages to separate module

I had to move tests too and it turned out to be much more difficult task mainly because Cocoon was lacking any up-to-date documentation on that subject. After figuring all out of details and getting tests back to the work I decided to share my experiences. Check this document to see how to write tests for Cocoon 2.2.
When it comes to documentation, it’s worth to mention other small addition: document describing how to configure logging in Cocoon 2.2. Thanks to Alex for bringing original information.