Tuesday, 31 January 2012

Last October I wrote a blog entitled Autowiring Property Values into Spring Beans describing how to use Spring’s @Value annotation to inject property values into your beans from both a property file and Java system properties. Last week, I came across this little gotcha whilst helping out on another project....

Thursday, 26 January 2012

One of the handy things about using Maven is that, by default, the names of the artifacts it creates include the current version number from the POM's version tag. It doesn’t matter what type of artifact it is, whether it’s a JAR, WAR or EAR you generally end up with something like this:

my_module-1.2.3-RELEASE.jar

And this is all usually fine when you’re dealing with a project that’s built solely using Maven. It does, however, become a little more inconvenient if you’re developing JAR files with Maven, but your WAR file is developed using Ant.

The story I used was Pete’s Perfect Pizza about a small high street pizza company that grows into an international business. The idea was that the fictitious programmer of the piece, our hero, is an absolute beginner and jumps straight in and choosing XML without considering any other design options.

Thursday, 19 January 2012

I recently wrote a new module for incorporation into a couple of our web-applications. Everything seemed perfect - the hoards of unit tests passed, the integration tests succeeded and everything seemed hunky-dory. The module was added to the web-apps POM files and the source code amended to use the new functionality. The web-app was deployed and then

Tuesday, 17 January 2012

I’ve seen a couple of projects in the last few months that have needed to cache data between requests. The developers, not wanting to write their own caching module, decided that Apache Commons JCS fitted the bill and added it to their Maven POM using the latest version:

Thursday, 12 January 2012

If you remember from my previous blogs, I’m covering different approaches to parsing XML messages using the outrageously corny scenario of Pete’s Perfect Pizza, the pizza company with big ideas. In this story, you are an employee of Pete’s and have been asked to implement a system for sending orders from the front desk to the kitchen and you came up with the idea of using XML. You’ve just got your SAX Parser working, but Pete’s going global, opening kitchens around the world taking orders using the Internet.

But, hang on a minute... didn’t I say this in my last blog? Déjà vu? Today’s blog is the alternative reality version of my JAXB blog as the scenario remains the same, but the solution changes. Instead of demonstrating JAXB, I’ll be investigating XMLBeans.

Tuesday, 10 January 2012

If you remember from my previous blogs, I’m covering different approaches to parsing XML messages using the outrageously corny scenario of Pete’s Perfect Pizza, the pizza company with big ideas. In this story, you are an employee of Pete’s and have been asked to implement a system for sending orders from the front desk to the kitchen and you came up with the idea of using XML. You’ve just got your SAX Parser working, but Pete’s going global, opening kitchens around the world taking orders using the Internet. He’s hired some consultants who’ve come up with a plan for extending your cosy XML message and they’ve specified it using a schema. They’ve also enhanced your message by adding in one of there own customer schemas. The result is that the following XSD files land in your inbox and you need to get busy...

Thursday, 5 January 2012

My last blog introduced the idea that there are different ways to approach XML parsing and highlighted the point that XML is NOT A STRING; rather it’s an object oriented document model that can be represented using a string. Today’s blog continues this discussion using my Pete’s Perfect Pizza scenario. If you remember, Pete’s just popped his head around the door

Tuesday, 3 January 2012

XML has been around a long time: from memory, I’d guess that it’s about 12-14 years old by now; it’s a mature product with, in computing terms, a long history. So, is there anything new that I could possibly add to this subject? How you approach XML is really down to you and your situation, with the emphasis being on situation. At one extreme, you may be involved in a cosy ‘in-house’ project, where one in-house system has to talk to another. At the other extreme, you’re in a situation where you’re handed an XML schema that will, one day, comprise the conversation between your system and some other system in a far away country written by a different set of developers.