jump to navigation

Spring and PropertyPlaceholderConfigurers October 22, 2008

Posted by Phill in Spring.
Tags: , , , ,
comments closed

The project I’m currently working on is a fairly modular web app. We have an application context file for each module. This has worked pretty well so far. However, I ran into an issue today when I wanted to add a new module: I kept getting the issue ‘Could not resolve placeholder ‘(property name)’.

I thought this was a bit strange because I thought I’d set up the property configurer correctly, and the properties file was definitely in the right place.

It turns out (via a bit of Googling – see this thread) that you don’t need multiple PropertyPlaceholderConfigurers. If one is defined, it will load properties for the whole of your application context files (as long as they’re within the same overall context).

If you have multiple PropertyPlaceholderConfigurers defined, what will happen is that if one of them can’t find a specific property, it will treat it as a fatal exception. This is of course going to happen if your different configurers point to different properties files!

There are three solutions:

  • Set the “ignoreUnresolvablePlaceholders” attribute on all property placeholder;
  • Set the “placeholderPrefix” or “placeholderSuffix” properties individually for each one so they don’t all match ${…}
  • Use one property placeholder configurer and just point it to all your properties files.

I’ve gone with the last option at the moment – it’s the best solution for what we need at the moment.


Commons Digester October 23, 2007

Posted by Phill in General J2EE, Open Source.
Tags: , , ,
comments closed

Last week, I had to build a validation system for a legacy J2EE system (I’m not sure whether you can actually call any J2EE applications ‘legacy’, but it’s pretty old anyway – from before frameworks were popular).

I thought I’d model it on the Struts validation system: have an XML file containing all the different validators, and another XML file containing the actual validation that is to be performed on each field. Obviously it couldn’t be as comprehensive as the Struts validators (it was actually fairly basic in the end), but did require a moderate level of complexity in the XML configuration.

I don’t know about you, but I hate parsing XML – it’s just not particularly exciting! You feel like you have to spend ages with the nuts-and-bolts. Step up Commons Digester. This is an XML parser with a difference… you don’t actually ever need to deal with any XML (per se). It was originally built for the Struts framework, to parse the struts-config.xml file.

Its purpose is to create Java objects from an XML file. You specify a list of ‘rules’, and the XML document is then parsed and Java objects created as necessary. For example, if you have an element in the XML document: validators/validator, you could set up Digester to create a new object “com.test.Validator” whenever this particular construct was encountered.

There are some good examples on the documentation.

If you’re starting a new project and need to create Java objects based on an XML file, it’s definitely worth a look. It saved me a lot of hassle!