coding (67)

Setup redmine / artifactory / hudson on fedora

Just a quick run through of what I’ve been doing for the last few days, namely setting up our build / development server.  It’s running Fedora, and the end goal was to have redmine, artifactory and hudson all on the same server, all running on port 80.  Once it’s installed and running we should be able to run automated builds (using hudson) when we commit to subversion and have those builds available from maven (using artifactory) for our Servicemix installation on another server.

It’s been a fun ride, redmine in particular was loads of fun to get going since I’ve never really setup a rails application before.  Anyway, on with the run through.  Please note that this is a very basic guide, and assumes you’re comfortable with the linux command line and so on, it’s not really for beginners.


Install fedora, ensure apache / mysql are installed and working, also install the latest JDK (guide here)  and ensure your JAVA_HOME environment variable is set correctly.


Download & install redmine following instructions here (for this example assume you installed redmine into /var/redmine).  You might have problems with bundler reporting some missing libraries, specifically ‘Rmagick’.  this should help with that.

Install passenger from here

make a symlink from a folder in your apache webroot to the ‘public’ folder of wherever you installed redmine:

ln -s /var/redmine/public /var/www/html/redmine

add an .htaccess file in the ‘public’ folder of redmine containing:

PassengerAppRoot /var/redmine #this should be the physical location of the redmine root directory on the filesystem
RailsBaseURI /redmine #this is the URI you want redmine to be accessible at, should match the symlink in /var/www/html/

Now in your web configuration folder (/etc/httpd/conf.d/) add a new ‘redmine.conf’ (or however you configure apache, it varies across versions of fedora I think) containing this:

Alias /redmine /var/www/html/redmine
<Directory /var/www/html/redmine>
 Options Indexes ExecCGI FollowSymLinks -MultiViews
 AllowOverride All
 Order Deny,Allow
 Deny from None
 Allow from All

Finally we need to set redmine to start in production mode.  Edit /var/redmine/config/environment.rb and uncomment or add the following line at the top:

ENV['RAILS_ENV'] ||= 'production'

And that should be it… restart apache and you should be able to access redmine at:



Download and install the ‘rpm installer’ for Artifactory using the instructions here

before setting up apache we need to change the port the ‘ajp’ connector runs on, as our hudson installation will steal this later.

edit the file: /opt/artifactory/tomcat/conf/server.xml and find the section that looks like this:

<Connector port="8009" protocol="AJP/1.3"
 maxThreads="500" minSpareThreads="20" maxSpareThreads="150"
 enableLookups="false" disableUploadTimeout="true"

change the connector port to “8010” and save the file

In the apache configuration, setup reverse proxying as follows (/etc/httpd/conf.d/artifactory.conf)

ProxyPreserveHost on
<Proxy *>
 Order deny,allow
 Allow from all
ProxyPass /artifactory ajp://localhost:8010/artifactory retry=0
ProxyPassReverse /artifactory/ http://YOURHOST/artifactory/
ProxyRequests Off

Start artifactory (/etc/init.d/artifactory start) and restart apache (/etc/init.d/httpd restart) and that’s it really.  Artifactory is now available at:



Download and install Hudson using the method described here

Create a proxy config file for apache (/etc/httpd/conf.d/hudson.conf) containing the following:

ProxyPreserveHost on
<Proxy *>
 Order deny,allow
 Allow from all
ProxyPass /hudson http://localhost:8080/hudson retry=0
ProxyPassReverse /hudson
ProxyRequests Off

Finally, we need to tell hudson that it’s running on /hudson otherwise all the css / js links break.

edit: /etc/sysconfig/hudson

and edit / change the following line (it’s near the bottom of the file):


Now start hudson (/etc/init.d/hudson start) restart apache and we’re done.  Hudson is now available at http://yourhost/hudson










Possible jNag resurrection

So, jNag was recently listed by ‘Computerworlduk’ as one of the top 16 mobile applications for IT professionals:

And this has given me some motivation to restart development…. I need some sort of project to work on since giving up facebook (I deactivated my account last week in the hope of spurring some productivity) and revisiting jNag might be just what I’m looking for.


Feel free to comment if you’d like to see development restarted, and even shout out some features you’d like to see added if you like.

Note: I doubt I’ll be doing any work on the IOS version of jNag.  I don’t have an apple development platform at the moment, and don’t see me getting one for the foreseeable future (unless I switch jobs and get a new Air as part of my package.  Well, I can dream!) so any future development work will more than likely be android only.

FUSE ESB Development: the build environment

The first thing we need to do when starting to work with fuse ESB is set up our build environment.  For this we’ll be using Eclipse, with the FUSE IDE plugin and maven. I’ll also cover downloading and installing Servicemix, and then generating our first FUSE project.

I’ll be using a windows box for the majority of this tutorial, but it should be fairly straightforward to get this working on your favoured flavour of *nix if you’re so inclined.

There’s a lot to get through here so lets get started.


Download the latest version of maven from here:

Extract the downloaded zip somewhere sensible (I use c:\program files\maven)

To make sure we can use maven from the command line we need to add it to our ‘Path’ environment variable.  On windows 7  you can do this by right clicking ‘Computer’, selecting ‘advanced system properties’ then click the ‘environment variables’ button.  Once the box opens scroll down until you find ‘Path’ under system variables, click edit and add ‘c:\program files\maven\bin’ to your string.

That’s maven setup, lets move onto something a little more challenging.

JDK installation

Before we can install our FUSE products we need to grab the Java Development Kit (JDK) and ensure that Eclipse and servicemix know where to find it by setting our ‘JAVA_HOME’ environment variable.

grab the JDK from here: and run the installer.

Once it’s installed you need to go back into the ‘Environment variables’ box we were in during the Maven installation and add a new variable called ‘JAVA_HOME’ pointing at the Directory your just installed the JDK into (by default it should be something like ‘C:\Program Files\Java\jdk1.6.0_25’).


Download Eclipse Helios from here:

Personally I’ve had no problems using the later ‘Indigo’ version of eclipse, but FUSE recommend Helios for working with their IDE so we’ll stick with that.  Run the installer as usual.  Once it’s installed we need to get the FUSE IDE plugin.

Go here: to download it.  You need to register as part of the ‘Fuse community’, then add the update site listed on that page to your eclipse installation to add the IDE plugin.

Once that’s done the final part of the Eclipse installation is to make Eclipse use our previously installed maven repository rather than the one that comes bundled with Eclipse.  In the Eclipse main menu open ‘Window’->’Preferences’.  Then select ‘Maven’->’Installations’.  Click ‘Add’ and browse to your maven directory (in my case it’s ‘c:\program files\maven’).  Click OK and you’re done.


For our ServiceMix installation I’m going to use the packages provided by FuseSource as ‘Fuse ESB#.  You can get the latest version from here:

Download the latest Zip file and extract it somewhere obvious (c:\servicemix for example).

And…that’s pretty much it, you should now be able to start Servicemix from the command line by changing to the servicemix directory and running the command ‘bin\servicemix.bat‘.  If everything goes well you should see something like this:

Generating our first project

Now everything’s setup lets try generating and deploying a simple test project.

To generate our project structure we can use the maven archetype generator as follows:

First create a new, empty directory where we’ll be working (I’m using c:\testproject)

Next run the command ‘mvn archetype:generate‘. this will prompt maven to download the latest list of archetypes and display them as a huge list.  Luckily we can filter this list if we know the name of the archetype we want. Type ‘karaf-blueprint-archetype‘ to return our filtered list, which should have 1 entry.  press 1 to select this entry and then from the list of versions that follows select the latest one (at time of writing this is 2.2.7).

You’ll now be prompted for some information about the project, use the following (or replace with your own values as required):

Once you’ve entered the details a simple ‘Y’ will confirm them and generate our project.

Import project into eclipse

The next stage is to import our project into Eclipse.  In the Eclipse main menu select ‘File’->’Import’, then from the import box scroll down and select ‘Maven’->’Existing Maven Projects’.

In the Import window browse to the location of your test project (notice maven has generated it in a subdirectory of our root directory) as shown:

Click ‘Finish’ to import the project.  You may get a ‘NullPointerException’ here for some reason, but the project should still import.

Configure a ‘Hello World’ Route

Now let’s make our project actually do something.

If you open up your project structure, you should see something like this:

There’s a few files and folders here to take note of, and we’ll go into these in more detail in further installments of this series, but for now let’s just jump in and start hacking around.

First of all we can remove the sample java beans that Maven gives us, so delete the two files under your java class path.  In my case this is ‘test-project\src\main\java\uk\co\tall-paul’.

We can also get rid of the sample camel context (in the file ‘my-service.xml’) and replace it with our own.  So remove that file and create a new one in the same place called ‘hello-world.xml’ containing the following:

<blueprint xmlns="" 
	<camelContext id="hello-world-context" xmlns="">
	<route id="hello-world-route">
		<from uri="timer:test?period=5000"/>
		<log message="hello world!"/>
		<to uri="mock:result"/>

For more info on what that xml actually does have a look at the camel website, and specifically the information abou the various components which you can find here:

This simple route basically uses a timer to fire off a message every 5 seconds, then logs ‘hello world’ to the console.

Build the Project

To build the project we can run maven from the command line or from within eclipse.

From the command line, navigate to the project folder (c:\testproject\test-project) and run the command ‘mvn clean install‘ (you can find more information about various maven commands here: , but really ‘mvn clean install’ is all you’ll need for now).  If all goes well you should (eventually) see something like the following:

From Eclipse you can do pretty much the same thing by right clicking on your project and selecting ‘Run as’->’Maven install’ as shown here:

Our project has now been compiled and installed into our maven repository, which you can see if you browse to the location of the repository (by default this is at c:\users\YOURUSERNAME\.m2\repository):

Deploy the project into servicemix

Thanks to the integration of maven into servicemix, deploying our project is trivial using the ‘install’ command withing servicemix.

From your servicemix consolerun the following command:

install mvn:\\test-project\1.0-SNAPSHOT

Hopefully you should be given a bundle ID, something like ‘bundle ID: 200’.  Now type the following command (substituting the bundle ID you were given for the 200 shown here)

start 200

And that should be it.  As long as you didn’t see any error messages, your bundle should now be running.  To see the output from our route type the following commands (the first clears the log file for clarity, the second displays the current log)


after a few seconds you should see something like this:

You can see that every 5 seconds our timer is going off and logging our message to the console. You can also see here the name of the component the message originated from (remember we put ‘test’ as the first parameter for our timer component) and the route in which the message is running (here it’s ‘hello-world=route’), which indicates the importance of naming your routes and components sensibly.


Hopefully this brief tutorial has shown how easy it is to get up and running with Fuse ESB development.  Next time we’ll look at how to use the environment we’ve set up here to do some real integration work.

Magento: Extending the API (v2)

Update:  I’ve fixed a couple of issues with the code in this post, based on the comments in this post on the magento forums.

One of the nice features of Magento is the extensive SOAP api it provides for integrating magento with your own or third party applications.  However, when it comes to extending that API the documentation is pretty sparse.  I’ve spent the last few days struggling to get to grips with this and, after spending some time debugging in the Varien autoloader class I’ve finally got it working.

Settings in WordPress plugins

I’ve rewritten my facebook helper for wordpress to make it a bit cleaner and as an example use case for the jQuery facebook helper I wrote last week.  I’ve also delved into the wordpress code a little more and added an option to set the facebook app_id from the wordpress admin page rather than having to set it directly in the code.  So lets take a look at that:

First we need to tell wordpress where our setting is going to be displayed in the admin interface:

            'Post to Facebook',

function tpfb_setting_section_callback_function() {
        echo "'Tall' Paul's Facebook plugin.  Publishing a post will also post it on your facebook wall. <br/> To use the plugin, you need to createa  facebook app<br/>See <a href=''>this post</a> for details";

In this example we’re adding a new section to the already existing ‘writing’ settings page.  Since I only have one setting (the app_id) it would be overkill to create a whole new page in the setting sinterface for it.  There’s four parameters for the ‘add_settings_section’ function, but they’re fairly straightforward.  The first is an identifier for your section, which can be anything but you’ll use it later so make it sensible.  The second is the title that will appear for this settings section (we’ll see what this looks like later).  Third is a callback function which will be called when this section is ‘placed’ on the page.  This is generally used to add some introducrtory or descriptive text at the top of your section, so people know what it’s for as you can see from my example.  Finally we have the identifier for the ‘page’ that we want the section to appear in.  Here we’re using the pre-existing ‘writing’ page, rather than creating our own.

With our section setup, we now need to add a setting to it.   For my plugin, I only need one setting (the facebook ‘app_id’) so here we go:

add_settings_field('tpfp_appid','Facebook App ID','tpfb_app_id_display','writing','tpfb_setting_section');

The ‘add_settings_field’ function actually places our setting on the admin page (although we control how the field appears using a callback function as we’ll see shortly),  it has 5 parameters, but the first 4 are logically similar to those we’ve seen for ‘add_settings_section’: an identifier for this field, a title to display next to the field, a callback function (which we’ll look at in a minute, because here the callback is used to display the field itself) and then the page for the field to appear on.  Finally, we also have a 5th parameter which refers back to our section identifier so the setting appears in our created section.

If you run the code as it is at this point, you’ll see a new section in the ‘writing’ page, but no setting will appear in it…because we haven’t told wordpress how to display this field.  To do that, we make use of the callback function we declared in ‘add_settings_field’:

function tpfb_app_id_display(){
        $option = get_option('tpfb_appid');
        echo "<input id='tfpb_appid' name='tpfb_appid' size='40' type='text' value='$option' />";    

There’s only really 2 things to note here.  The first is how we get the current saved state of our setting back from wordpress usingthe ‘get_option’ function, with the identifier of the setting (as used in ‘add_settings_field’) as a parameter. Secondly we can see how we actually get an input for this setting placed on the admin page… we simply echo it directly to the page from this callback function.  There’s a lot of flexibility over how you want your settings to appear inherent in this method, since you have total control over this stage of the page construction.

And that’s almost everything.  There’s a couple of final steps required.  First, for each setting we’ve added we need to ‘register’ it with wordpress.  This instructs wordpress to save these settings along with everything else when the page is submitted.  This is incredibly straightforward:


You should be able to tell what those parameters refer to now…the first is your page identifier, and second is the identifier of the new setting.

Finally, how do we get wordpress to include all this code when building its admin pages?  Simple, we use the ‘hook’ system to plug our code into the correct place in wordpress.  First we wrap all our code so far in one function:

function tpfb_settings_api_init() {
  //all your code here
  function tpfb_setting_section_callback_function(){}

//don't forget to close the wrapping function!

and then we add an ‘action’ to hook into WordPress’ admin page initialisation:

add_action('admin_init', 'tpfb_settings_api_init');

And that’s it!  here’s how it looks in the admin interface:

You can find the code for this article as part of my facebook plugin for wordpress which you can download here:


Job Hunting!

Thought I might as well post something here, you never know who reads these things…

I am currently on the hunt for a job.  Ideally something in PHP / Web development that pays around £30k (or slightly less for the right role) and is based somewhere near Manchester (UK).  Working from home would be nice though if you’re based on the other side of the world.

email me for a CV if you have any opportunities that might fit the bill.

Self signed SSL certificates in phonegap (android)

So this week I ran into a wonderful problem while working on jNag, namely how to connect to servers over SSL using phonegap (which jNag relies heavily on).

Phonegap is a wrapper around Android’s native webview class so (I thought!) the answer lay in somehow getting the webview to accept a self signed certificate.

jNag 0.78 released

This release includes the ‘schedule reCheck’ functionality, as well as myriad bug fixes / changes including:

  • a rather nasty bug that occured when first entering settings
  • changes in the way problems are handled
  • better error messages
  • dialogs now close when hitting ‘commit’

Hit the jump for a screenshot and the download link

jNag: schedule recheck

I finally got round to adding the ‘schedule recheck’ functionality for hosts and services which has been on the ‘roadmap’ for a couple of weeks.  This means you can now fix a problem and then immediately schedule a recheck to make the flashing ‘problem’ indicator go away.  hit the read more to see a screenshot:

jNag 0.77 (re)released

So, once again my numptyness strikes…

The package for 0.77 included the wrong html file.

Here’s a reuploaded package with the correct file, and a new ‘returndata.php’