Running with Wookie

When we first looked into getting involved with the Widget revolution we wanted scalable widgets that could enhance the student learning experience and be deployed on a range of different platforms.

Walking with Wookie

Er… thought you said Running with…

Well, when we first looked into getting involved with the Widget revolution we wanted scalable widgets that could enhance the student learning experience and be deployed on a range of different platforms. Indeed, we still do. We are in the process of deploying Moodle, hosted by the University of London Computing Centre (ULCC), as our institutional VLE, and were attracted to the potential of widgets as a way to enhance the VLE and be available on mobile devices. We realized that if widgets were to be part of our core offering, we’d need a widget server that could handle multi-thousands of hits in a short time interval, so began exploring Wookie with that in mind.

I proceeded to put a test platform together on our existing webserver and opted for the Wookie install that utilises Tomcat and MySQL so that we could potentially load-test the platform at a similar level to our existing web platforms.

I have to say the process wasn’t attractive or easy. “Dependency hell” took over fairly soon with trying to determine which JDK to run, out of the three that lived on our system (an Ubuntu derivative), making sure we had the right JDBC and that it could talk to MySQL (also having to be set up correctly). That said, much of this is really dependent on the platform you wish to run Wookie on, the variant or distro and so on. Having revisited the Wookie trunk in recent weeks I can say great strides have been made in only a year in making Wookie easier to install. You still really have to beware of the various Java JDK’s out there – stick with the Oracle one would seem to be safe advice.

The development team are fantastic, frenetic and focused – I cannot recall too many other software / platform development projects that I have been involved with that have released so many upgrades, patches and fixes over such a short period. Wookie itself is still a project under Apache incubation, in theory a kind of Beta state. This means you need to expect a certain amount of work to get the software going on a system of your own. In my struggles I was able to visit Paul and Scott (and also Scott’s interesting personal page ) in Bolton and get a couple of errors sorted out to enable our install to function. This actually fed back into the process at the time – a script hadn’t performed as it should, was corrected, and the nice new working version made its way back into the build. Just goes to show how fast communities can rectify problems!

Result – a working copy of Wookie on a server base.

Problems with the Server-based install

At some point I opted to patch our system (as you should, once everyone else has done it and found the bits that break!), ANT – an essential component climbed a couple of revision levels and promptly broke the Wookie install script. This is kind of expected behaviour when working at the beta end of things, but it came at a time when we needed to start working on our widgets: not good! The team have been working to sort out all sorts of similar issues throughout the year, but with increasing interest in developing our own widgets to deploy into our enhanced VLE platform (check out Mark Stubbs’ recent post Writing Widgets) we revisited a server-side copy of Wookie. ANT is still not working – what to do?

Running with Wookie – use the Wookie standalone install

[pullquote]Useful  links



Given that our project really needs to focus on the development of Widgets, a rethink was needed on applying efforts towards writing Widgets, and not messing with Wookie. Whilst visiting the developers, Scott and Paul, in Bolton about some issues regarding our server-based installation I noticed that the folks there are essentially all developing against local standalone copies of Wookie.

I decided to give it a try. Simply put, it’s the fastest and easiest way to get Wookie going. I have no stats to tell you how robust the standalone copy is when operated within a typical server situation, but thus far, for our tests, it has remained up and viable.

So – what are the crucial benefits of using the standalone copy?

Firstly, ease of install. It can be as quick as this:

[codesyntax lang=”bash” lines=”no”]

svn co
ant run


an example of a Running Wookie Instance
an example of a Running Wookie Instance in MSDOS cmd shell

Several lines of text later after SVN has copied you the latest trunk build of Wookie, and ant has performed a great many tasks including downloading IVY, Wookie will instantiate and start

logging stuff to the screen.


There are some pre-requisites here though:

  • An accessible JRE (Java Runtime Environment) on your machine
  • a copy of Apache ANT (for windows – you can check out WinANT which takes out some of the grief in getting this going and setting environment paths and so on, and has the added bonus that you can get an archived copy of WinANT 4.1 – the last 1.7.x release before ANT migrated to the 1.8 series that leaves your Wookie broken and downhearted).
  • Subversion
Wookie first menu
Wookie's first menu

Once it’s up and running you will have a nice fast localised copy of Wookie running with all the default settings (so the Admin user and password are java & java respectively).

You can fiddle with some settings in the config files that reside in the ‘root’ level of the trunk directory. Best place to get information on these is the wookie site.


Flushed with this success, I determined to remove the schizoid and out of date copy of Wookie we have running on the LRT server to see if a standalone copy might work better. The LRT server – like others at the MMU – is behind the MMU firewall. At the time I built it we were not allowed to be added to the bypass group that permits servers to communicate with the WWW without having to go via a proxy – which usually makes a mess of all sorts of things on a server level. So – the original install of Wookie had entries in the config to add the proxy in by hand – and – alas – down the line, it was just possibly getting in the way of examining accurate widget behaviour.

Nowadays the whole server is in the bypass group, so in theory a fresh install and a standalone server should have widgets that can communicate with resources out on the web without judicious proxy messing.

Wookie's Demo Widgets
Wookie's Demo Widgets

Et Voila – it works. We now have a ‘standalone copy’ running on a server hosting widgets that now actually tell me what the weather is in Manchester (and no, it’s actually sunny!).

Running with Wookie – Tips for maintaining a standalone install

The problem is, that we are running this is on an actual server. It’s designed to sit there without someone nurse-maiding an instance of a program running in a terminal or shell, any reboot, any premature death of that shell (like killing the SSH shell from my machine to the server in which I actually launched Wookie) is going to see Wookie die a death. On a reboot, it’s not going to come back alive.

The standalone doesn’t act like a standard daemon in Linux. Once you hit ant run – its going to run and stay resident in the shell window you typed that command in – logs to that window and no escape from it without killing wookie with a control-c.

So – how do we manage?

SCREEN is a wonderful tool that has, after some years, now wormed its way onto standard distros for *NIX and even MacOS X. It allows you to run virtual terminals that stay resident in memory, have full TTY access and a witty set of escape sequences that, at a base level, allow you to essentially kick a terminal into life, run a command and virtually exit the terminal. Next time you log in you can reuse the Screen command and attach to that very same terminal you left – and, barring a reboot of the box – it will still be there with your program running merrily away and not the least bit bothered that you wandered off and left it.

Check this command out:

[codesyntax lang=”bash” lines=”no” blockstate=”expanded”]

screen -S "wookie-running" -d -m ant run -Drun.args="initDB=false"


Woah neddy! thats a lot of arguments, here is an explanation:

  • screen – the command we need
  • -S “wookie-running” our instance of screen will have a nice english language name to allow us to refer to it by
  • -d -m as a couplet – these commands allow screen to do its stuff, run your command, and automatically come back out to the terminal you are currently in – auto-detaching itself in other words. The cunning part here is that your stuff is still running in the background in memory
  • all the rest is the standard wookie command to run without destroying our existing DB

You can nip back into your virtual terminal by the following command:

[codesyntax lang=”bash” lines=”no” blockstate=”expanded”]

screen -r wookie-running


except you need to swap wookie-running out to whatever name you used for the screen sessing with the -S command. Hey presto – you will shoot right into a log of log lines Wookie has been dutifully dumping to the Standard IO of the terminal.

Getting back out? A doddle, hold control A and hit c

This will take you back to your original terminal without killing the session. If you want to kill the session, hit control D, or control C to kill Wookie then then Control D to get out of the virtual screen.

You might take to this method of doing things, I’ll stick some links in to good resources relating to Screen as soon as possible, it is extremely powerful and indeed programmable too. I will leave you with one final very useful command in case you do decide to do a few screens:

How to see how many screens you have established:

[codesyntax lang=”bash” lines=”no” blockstate=”expanded”]

lrt ~ # screen -ls

There are screens on:

20486.wookie-running    (03/21/2011 10:58:06 PM)        (Detached)

17838.stats     (03/01/2011 10:25:58 AM)        (Detached)

15863.backup    (02/24/2011 09:30:26 AM)        (Detached)

3 Sockets in /var/run/screen/S-root.


Finally, we haven’t really solved the issue of making sure Wookie is running following a server reboot. This isn’t a massive problem, so for the moment I will just suggest that the screen command can be put into a standard init shell script. It must either be properly pathed, or execute a ‘cd’ command to the Wookie trunk before executing the screen portion. I will trial this shortly and put the additional steps into this article.

Lessons Learned

Really, if you are testing something, it’s not always best to go for the platform you think you will need to run it in anger. Luckily for us we had time to adapt, chuck out the stuff we didn’t need and came back to the problem from a fresh angle.

If running the server itself is your main angle (maybe you are a sysadmin), then invest some time on the Wookie pages and the email group finding out the best combination of dependencies – JDK, ANT, JDBC etc… really consider if you even need MySQL vs the built-in Derby engine. These choices may change depending on the extent of your target audience and the numbers of hits you expect Wookie to be able to cope with. If you expect to hang a major system off the back of this – remember – it’s in Beta/ Incubation, hiccups are going to happen from time to time despite best efforts of the developers.

If, on the other hand, you are really more interested in developing the widgets themselves, just go with the easiest option and use the Wookie standalone. It’s far less messy, and you can be up and running developing widgets within ten minutes or so.

Caveats and other Witty Considerations

I have used the term standalone here to indicate the difference in how the platform behaves, rather than the notion that you could use Wookie in this way off the net. When you type ant run, ANT is going to try to nip off and find updates to IVY, and it will fail miserably if you aren’t on the net, or are sitting behind a proxy and haven’t set the correct proxy variable. Here’s a couple of pointers:

Running ANT in offline mode

[codesyntax lang=”bash” lines=”no”]

ant run -Doffline="true"



Setting the Proxy variable for ANT (behind a proxy)

[codesyntax lang=”php” lines=”no”]

ant -run -autoproxy


Read a whole lot more about Ant and proxy here

Due Thanks to…

Scott, Ross, Paul and Co

Please dip in with comments, this post was put together over a few days including two great days at the Bolton CETIS Widget Bash, so most likely there are some lapses of concentration! Corrections gratefully received.

Now, give it a go, give the guys a go and get active. Get hold of Wookie, read about Widgets, grab some, play with them, join the mailing list [info further down the page].

Leave a Reply

Your email address will not be published. Required fields are marked *