I encountered the following error when executing a Hadoop MapReduce job today:
Error running child : java.lang.NoSuchMethodError:
The problem was caused by clashing entries on my classpath. My jar had a dependency on Commons Codec 1.6, yet the Hadoop lib directory contained version 1.4 of the same jar (used by the Hadoop framework). This Hadoop library jar was taking precedence at runtime, hence the
The solution, as it turned out, is pretty simple — there’s a property you can set to make user classes take precedence:
mapreduce.task.classpath.user.precedence which should be set to
There’s even a convenience method on the
Job class in Cloudera’s distribution to set this for you:
Job job = Job.getInstance(conf);
I’m working currently on an application with an ExtJS based front-end, and wanted to share my experiences at using the Sencha SDK tools to create a production build. ExtJS is a fantastic framework, with a very well documented API. The same unfortunately can’t be said for the SDK tools (at the time of writing, anyway) so perhaps someone will find this useful.
Back in the ‘old days’ if you wanted to configure a message driven bean you’d need to write reams of accompanying XML configuration. Thankfully, EJB3 came along, and with it the wonderful world of annotations. Now all you need to do is annotate your implementation of the
MessageListener interface, pass it over to JBoss and have the application server take care of things for you.
On a recent project, I created a webpage in which a value could be dynamically updated based on a user’s action. Now, it should be obvious to the user that the value had changed, but I wanted to add a small visual cue to add to the aesthetics so I decided to look into CSS3 animations. Support, at time of writing, isn’t great it has to be said – but most modern browsers do support it, with the notable exception of Internet Explorer. The webkit-based browsers (Safari and Chrome) have offered support for a while, whilst Firefox has had support since v5, released back in June.
With the cloud becoming an ever pervasive term within the IT industry, this XKCD comic seemed too good not to share:
This comic is from XKCD and licensed under a Creative Commons Attribution-NonCommercial 2.5 License.
A few people have asked me this question recently, so I thought this might be a tip worth sharing more widely than just my office.
If you generate a Java client for a web service using a tool like
wsconsume you may be surprised to note that no setters are generated for any Collection properties.
This is actually by design, and is due to the implementation of JAXB. I quote from the JAXB2.1 specification:
Design Note – There is no setter method for a List property. The getter returns the List by reference. An item can be added to the List returned by the getter method using an appropriate method defined on
java.util.List. Rationale for this design in JAXB 1.0 was to enable the implementation to wrapper the list and be able to perform checks as content was added or removed from the List.
So now you know!
A colleague recently (and unknowingly) had their IDE set to convert line endings to Windows (cf Unix) format when saving a Java file. Now, that’s since been corrected but it’s left us in a position where if we compare (using ClearCase) the latest version of a number of files, with their predecessors, every line is showing as having changed.
The solution turns out to be a single click away – the ClearCase comparison tool includes a nifty button which will hide any changes that solely affect whitespace. And here it is, highlighted yellow in the following screenshot:
It’s function is not immediately obvious, probably hence why I’d not spotted it sooner. I believe the
b stands for
blank_ignore – the name of the corresponding flag in the
cleardiff command-line version of the tool.
JVM system properties can be a convenient and sensible way to manage certain elements of your application’s configuration; certainly a good alternative to hard-coding certain values. Accessing such properties with a call to
System.getProperty("propertyName") is easy and unobtrusive, and since system properties are given global JVM scope you needn’t worry about problems with multiple classloaders.
Sometimes you may come across a need to set system property values within JBoss (just as the
System.setProperty("propertyName", "propertyValue") method and the VM command line arguments do). Happily, JBoss 4 includes a system properties service which helps you do just that.
To make use of the service, just add an appropriate XML file to your deploy directory. You can either specify the properties right within the file, or reference an external config file. The latter option is likely preferable, certainly if there’s more than a few properties to reference. The advantage of this approach as well, is that if you run multiple JBoss instances on the same server, you can have each reference one single “master” config file.
Hello, and welcome to the Lansdown Tech blog. As all good programmers will appreciate, this seems an apt title for the first post on a blog caputring interesting thoughts, musings, and tips relating to software development. Watch this space! 🙂