Jabbering Giraffe

I’ve been looking quite extensively at the cocoon-spring-configurator, trying to work out how to make it fit into our preferred java webapp config scheme: context-params.

By default, cocoon-spring-configurator just reads Properties files. The complete list of property files that cocoon-spring-configurator picks up is extensive. If you want to see what’s happening, then add this to log4j.xml:

  <logger name="org.apache.cocoon.spring.configurator">
    <level value="DEBUG" />
  </logger>

But there’s one interesting bit in the docs:

9. If a property provider is configured in the application context, it is queried for a set of properties.

If you have special requirements for property handling, you can add a property provider bean which is a Spring managed bean conforming to the org.apache.cocoon.configuration.PropertyProvider interface. For example, if you want to store your configurations inside a database or configure them through a jndi context, you can provide these values through a custom implementation.

So this means that you:

1. Write a class that fetches properties from somewhere like (say) the ServletContext.
2. Add that class into Spring with the name org.apache.cocoon.configuration.PropertyProvider.

So I did that. The code itself is moderately simple:

public class ContextParamsProvider implements PropertyProvider, ServletContextAware {
    public Properties getProperties(Settings settings, String runningMode,
            String path) {
        Properties props = new Properties();
        EnumerationString en = servletContext.getInitParameterNames();
        while (en.hasMoreElements()) {
            String name = en.nextElement();
            String value = servletContext.getInitParameter(name);
            props.setProperty(name, value);
        }
        return props;
    }
}

This should mean that things like what email to send to can be completely external to the application.

dom Uncategorized cocoon, java, servlet

UrlEncodedQueryString represents a www-form-urlencoded query string in Java. I can’t tell you how many times I’ve needed this in the past. Perl has the lovely URI::QueryParam. In fact, I’ve got a fairly close cousin of this class in use at $WORK (though it uses google collections as I’m lazy).

Now it just needs to appear on a maven repository somewhere…

dom Uncategorized java

Whilst dragging myself through an issue for a client last night, I found another cocoon feature I wasn’t aware of: sitemap variables.

Of course, I’d seen Input Modules before, in fact I’ve written one. They’re nice and simple and look like this:

  <map:parameter name="contextPath" value="{request:servletPath}"/>

But then I came across this little line:

  <map:parameter name="email" value="${contact.email}" />

What the heck is that? I immediately jumped into the cocoon source code, thanks to Jukka Zitting. First, I saw _no_ examples of this syntax in any sitemap.xmap. Marvellous.

After a bit of digging, I ended up at VariableExpressionTokenizer (thanks to a comment). This revealed (in yet another comment) that strings of the form ${…} are handled using the new cocoon-expression-language.

… snip several hours of wasted time …

Now, at this point, I’ve gone down the garden path. I’ve spent quite a few hours debugging this and it’s completely in the wrong direction — it seems like cocoon has far too many ways of inserting variables into the sitemap.

Finally, I’ve managed to end up looking at AvalonUtils.replaceProperties() (which gets called from SitemapLanguage.build()). This gets passed in a Settings object (i.e. something you configured with the cocoon-spring-configurator). So any reference to ${something} will look it up directly in your configuration.

It’s actually slightly more generic than that. Looking through the code, AvalonUtils.replaceProperties() also gets called any time that an avalon component is set up. So, any older components can benefit from the new Settings as well.

Summary:

1. Create a property file in your block. e.g. src/main/resources/META-INF/cocoon/properties/app.properties.
2. Set a value in there. e.g. contact.email=dom@example.com
3. In src/main/resources/COB-INF/sitemap.xmap, you can now say ${contact.email} and the correct value will be substituted. e.g.

     <map:parameter name="email" value="${contact.email}" />

dom Uncategorized cocoon

I keep getting sent files, which are encoded in UTF-8, but include a BOM. Which is completely unnecessary. Thankfully, it’s pretty easy to remove with vim. Just load up the file and type in :set nobomb (docs for the bomb option) and save. Problem successfully defused!

dom Uncategorized tips, vim

I’ve just hit the “update everything” button in my Eclipse install. All seemed well until I restarted it and got a message about a shared library not being found. Looking in Console.app showed this lovely little line:

09/02/2009 14:33:07 [0x0-0x1ef1ef].org.eclipse.eclipse[43353] dlopen(../../../plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.100.v20080509-1800, 2): image not found

Fairy ’nuff. I had a quick grep in the eclipse folder and found that it’s referenced by eclipse.ini (in Eclipse.app/Contents/MacOS). Using the magic of vim’s filename completion (^X^F) I corrected it to the newly updated version:

--- eclipse.ini.orig	2009-02-09 14:39:16.000000000 +0000
+++ eclipse.ini	2009-02-09 14:39:19.000000000 +0000
@@ -1,5 +1,5 @@
 --launcher.library
-../../../plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.100.v20080509-1800
+../../../plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.101.R34x_v20080731
 -startup
 ../../../plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20080819.jar
 -showsplash

Now, eclipse starts again.

dom Uncategorized eclipse, java

A colleague was asking:

I’m trying to work out a technique for searching for an occurrence of a phrase in _all_ revisions of a specific file in a subversion repository. How can I do this?

Of course, in subversion, the answer is slow and complicated. But, you can use git (and git svn in particular) to achieve the answer fairly simply (and much more quickly).

First, you just clone the subversion repository into git. This takes a while, mostly because subversion isn’t that quick.

  git clone -s https://svn.example.com/proj

Then, you can wrap a little bit of shell scripting around git to get what you need.

  cd proj
  git branch -a | grep tags/ | while read tag
  do
    git --no-pager grep 'something' $tag -- some/file.txt
  done

So, we pull out a list of tags, and run git grep over each one.

There may well be a more effective way to do this, but hey, it took seconds to come up with. And it shows off the reason I like git — it’s so scriptable.

dom Uncategorized git