Saturday, November 5, 2011

Memorial University CS Games Singles Fall 2011 Results

The Fall 2011 CS Singles programming competition took place last Friday night at Memorial University. Eighteen students took part, trying their skills against the algorithmic conundrums the programming competition committee prepare as their set of three problems.

After 150 minutes the competition time expired and the judges prepared the results.
Awaiting the results.
Competition Judges (Left to Right): Dr Craig, Dr Kolokolova, and Dr Wareham. 
The volume of submissions for this competition was impressively high, at the end though three students emerged with top results; in third place was Nathanel Woodfine, in second place was Adam Murphy, and finally in first was Robert Hamilton.
3rd: Nathanel Woodfine 2nd: Adam Murphy 1st: Robert Hamilton





















I'd like to thank all the students, volunteers, and the games committee again for making these CS games possible. I hope to see everyone again in the new year when we have the next singles competition.

Thursday, November 3, 2011

Creating your own Apache Karaf console command.

Have you ever wanted to create your own Apache Karaf console command but didn't know where to start? In this post I aim to show you how the critical code snippets required to create your own Apache Karaf console commands, complete with completer. Please note that the process for creating your own console command is well documented in the Apache Karaf documentation, however its nice to have a concrete example on hand.

The creation of a custom command can be boiled down to drafting a boiler plate pom file, extending OsgiCommandSupport, writing a command completer, and finally wiring it all together via blueprint. Don't worry about directory structure, or other boiler plate bits of code for now, a full source code demo will be included in Karaf starting on version 2.2.5.

The Pom File:

The critical bits you'll encounter in the pom file for making your own command will be the initial setup declarations:

  <groupId>org.apache.karaf.demos.command</groupId>
  <artifactId>shell-sample-commands</artifactId>
  <packaging>bundle</packaging>
  <version>2.2.5-SNAPSHOT</version>
  <name>your-commmand</name>

Adding in the dependency on the Karaf shell:


  <dependency>
    <groupId>org.apache.karaf.shell</groupId>
    <artifactId>org.apache.karaf.shell.console</artifactId>
  </dependency>

And finally configuring the maven bundle plugin to package the command:

  <plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <version>2.3.4</version>
      <configuration>
         <instructions>
            <Import-Package>
              org.apache.felix.service.command,
              org.apache.felix.gogo.commands,
              org.apache.karaf.shell.console,
              *
            </Import-Package>
         </instructions>
      </configuration>
  </plugin>

Extending OsgiCommandSupport:

The actual custom command logic is implemented in a class you write that extends OsgiCommandSupport. The annotations for 'command' and 'argument' is where you'll immediately need to pay attention. In the command annotation you setup your command scope and name (each scope can have several names associated via separate commands). In the argument annotation you describe the arguments that the command will expect. The doExecute() method is where you'll perform the action for the command, add any custom code you want to have performed here.

@Command(scope = "yourcommand", name = "hello", description="Says hello")
public class YourCommand extends OsgiCommandSupport {


    @Argument(index = 0, name = "arg", 
              description = "The command argument", 
              required = false, multiValued = false)
    String arg = null;


    @Override
    protected Object doExecute() throws Exception {
        System.out.println("Executing your Command Demo");
        return null;
    }
}

Command Completer:

Although not strictly required, the command completer is generally a good idea to include. The completers' job is to allow the user to tab complete the command, possibly showing input possibilities.

public class YourCompleter implements Completer {
 /**
* @param buffer it's the beginning string typed by the user
* @param cursor it's the position of the cursor
* @param candidates the list of completions proposed to the user
*/
 public int complete(String buffer, int cursor, List candidates) {
  StringsCompleter delegate = new StringsCompleter();
  delegate.getStrings().add("one");
  delegate.getStrings().add("two");
  delegate.getStrings().add("three");
  return delegate.complete(buffer, cursor, candidates);
 }
}

Wiring it together with Blueprint:

Now to bring all these components together we use Blueprint. Blueprint is a dependency injection framework that we like to use with OSGi in Karaf. In short the below xml handles the instantiation of objects and wiring them together.

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
    <command-bundle xmlns="http://karaf.apache.org/xmlns/shell/v1.0.0">
        <command name="yourcommand/hello">
            <action class="org.apache.karaf.demos.command.YourCommand"/>
            <completers>
                <ref component-id="yourCompleter"/>
                <null/>
            </completers>
        </command>
    </command-bundle>
    <bean id="yourCompleter" class="org.apache.karaf.shell.samples.YourCompleter"/>
</blueprint>

Build and Deploy Time!

Now that we have composed the components of a custom command, lets build the code and test it out.

To build the command just invoke:

mvn install

This will build the command bundle and make it available in your local m2 repo.

To deploy the command bundle issue the following command in a running instance of Karaf:

karaf@root> osgi:install -s \ mvn:org.apache.karaf.demos/org.apache.karaf.demos.command/2.2.5-SNAPSHOT

After installing the bundle it will become available on the console command line. Your custom command will now act like the other commands already deployed inside of Karaf.

karaf@root> yourcommand:hello 
Executing your Command Demo
karaf@root>

This demo will start appearing in Apache Karaf 2.2.5, so don't worry about piecing together the boiler plate code. I hope you found this short tutorial useful.

Tuesday, November 1, 2011

Apache Karaf Child Instances, what are they and why should I use them?

An often under used feature of Apache Karaf is its support for child instances. In this post I'll cover just what Karaf child instances are, and discuss some ways that you may use them.

Two child instances, Alpha and Beta,
created from base Karaf installation.
A Karaf child instance is a copy of Karaf that you can launch separately (its own system process) and deploy applications into. An instance does not contain the full copy of Karaf, but only a copy of the configuration files and data folder which contains all the runtime information, logs and temporary files. This concept is pretty neat in that you can deploy a Karaf distribution to your server, adjust your basic configuration, then spin up copies of this initial deployment for use - the ports used by these child instances are managed such that you don't have to manually set them as part of the setup process (much easier than trying to setup multiple separate installations on one machine). Each of the Karaf child instances will "live" in your KARAF_HOME/instances folder.

If the above description doesn't have you excited then don't worry, here are a couple of deployment scenarios that may help illustrate why using Karaf child instances can improve your Karaf experience.

Operating System level process isolation:

We've all encountered this - Suppose you have an application that is known to have less than desirable runtime characteristics (cores the system, or regularly encounters Out of Memory exceptions for example), it may be nice to have that application deployed in its own Karaf environment. If the process becomes unwieldily then the entire instance can be stopped, restarted, or else wise manipulated without affecting other applications deployed  in other Karaf child instances.

Failover protection:

Simple Master/Slave Failover.
I have to admit I like to use this setup when I need to have an extra level of assurance that my deployed application will be available. In this scenario two or more instances of Karaf are created on one server, with each instance making use of Karafs' JDBC lock mechanism to connect to local or remote DB. In this Master/Slave deployment if the instance acting as the Master was to become unavailable then an awaiting slave instance can spool up to take over (for faster switches I keep the slave instances hot loaded via container level locking).

Organizational Separation:

Keeping your user groups happy.
It's not uncommon for multiple departments or projects to reside upon the same server resource, it may be advantageous for the administrator to separate their Karaf deployments along these lines so that the operation of one group does not impact others. In example one may have an instance for supporting an application used by accounting, and another by marketing.

Clustering:

A more advanced concept is to create Karaf instances to join into a Cellar Cluster - Cellar being Apache Karaf's Hazelcast powered clustering solution. Creating Karaf child instances to join as cluster nodes allows for another degree of flexibility when allocating resources for Karaf deployments. Given a powerful server, an administrator may create child instances as required to add to the cluster. These additional cluster resources may be deallocated as required at a later time.

I hope that the above exploration of Karaf child instances helped clear up any general confusion about their purpose and perhaps provided some insight into how to improve your own Karaf deployments. For more information on Karaf child instances please visit the Karaf user guide Child Instance entry.