This is from a report for BuildIT
This year’s Component Based Software Engineering (CBSE) conference was held in Prague, at Charles University, in conjunction with the other CompArch conferences, Quality of Software Architectures (QoSA), International Symposium on Architecting Critical Systems (ISARCS) and the Workshop on Component-Oriented Programming (WOCOP).
I arrived in Prague early so registered to attend the WOCOP headed by Ralf Reussner and Ivica Crnkovic. At this workshop I was able to see many presentations about continuing work from other Ph.D. students and discuss it with them in the question sessions and breaks.
After the presentations we broke into groups to discuss topics of interest, our topic was discussing Services vs. Components. Our group, consisting of people from various fields (including embedded, performance prediction, security and software engineering) all saw these two concepts very differently. Therefore instead of presenting conclusions from our discussion, we enumerated the fundamental questions that we encountered when discussing these topics. I was elected to present our questions to the group which elicited much discussion, culminating in a great quote from Ralf, paraphrased as “If you ask a professor what a component is, they can answer. However each professor gives a different answer.”
The next few days CBSE, QoSA and ISARCS were held, and I attended relevant talks on my Ph.D. project, these included “Reliable Dynamic Reconfigurations in a Reflexive Component Model” by Leger et al. ,“Component Composition Using Feature Models” presented by Ralf Mitschke and “Automated Creation and Assessment of Component Adapters with Test Cases” presented by Oliver Hummel.
Opportunities where taken to discuss work and research outside the conference setting. I talked to the presenters Ralf Mitschke, Claas Wilke and Kerstin Falkowski at length about their work and how it relates to mine, and progress and problems they have encountered, as well as many other presenters.
I presented second to last on the last day. I spoke for about 18 minutes and had 12 minutes of questions. Many questions came from Kung-Kiu Lau, who presented on “(Behavioural) Design Patterns as Composition Operators”, and Kiev Gama who presented “A self-healing Component Sandbox for Untrustworthy Third Party Code execution”, both of whom I had discussed their work with earlier in the conference. The presentation went well and the feedback and questions where thoughtful and useful for future research.

First submitted issue and patch to Felix, it was just a bug I found in the framework package while I was using it in an embedded manner.



In OSGi Require-Bundle manifest header, never mix up "version" and "bundle-version".
I discovered some bundles do this, and Felix does not like it, here is what happens...

Require-Bundle: org.w3c.dom.smil;version="[1.0.0,1.1.0)";
This means 2 things, A) that the version range wont work, and B) that the bundle must have a property version which equals "[1.0.0,1.1.0)".

This means that bundles will not resolve with really weird errors, and nothing will work.

The better idea of course is never to use Require-Bundle, which is of course a static dependency and one that breaks all that modularity that OSGi gives you.

A lacking team member is not only a hindrance to progress, but is also a detriment. Not only are they unproductive, but what they produce must be more carefully analysed by better programmers consuming time and resources which could be better used.
--Joel on Software

Azureus was using a FEW custom logging frameworks mixed in with some Log4J, which was really annoying when trying to separate the project into bundles. So what did I do, I moved it over to the JDK logging package. Took me all weekend but I am finished.

To make it OSGi-y I also wrote a package that implements a service that inserts itself as a handler into the JDK logging service and then passes those LogRecords onto the OSGi logging service, so that any bundle wanting to listen to the Torrent bundles logs can listen to either the JDK logger, or the OSGi Logger service.

Next is removing the custom plugin framework, and all the ad-hoc stuff that is implemented around it to make it modular.

All the internal stuff that goes on inside Azureus can be greatly simplified with the use of OSGi. But the process of moving is difficult, and the tools from going from legacy to OSGi code is arduous. Refactoring tools need to be developed to help this process.

TLDR) I have been pulling apart the code of the Azureus Torrent Client to create a Torrent Bundle and Service in OSGi. It is more difficult than I first though it would be.
If you would like to see such a bundle, please let me know, this would encourage my efforts.

I have been working on it for a while now, and this is the first post that is describing my process, and the problems I faced.

I chose Azureus because it was my old client, it has alot of functionality that basic torrent clients dont, like selecting files within the torrent to download and others not to. And because I assumed moving it from the Azureus plugin model to OSGi would be trivial.

Here is what I learnt

First 1) No matter how modular you think your code is, forcing it into OSGi shows you all the dependencies errors caused by hacks.

This was obvious for Azureus when pulling out the SWT packages. I wanted a core package that depended on no external UI bundles, like SWT, or Apcahe CLI.
The problem is that some of Azureus's Table classes, that are abstract UI classes organizing information and handling the internationalization, depended on SWT listeners by using instance of a UI util to check weather it is SWT then adding the correct listener. This then caused a core dependency on SWT interface, SE 101 bad.


Second 2) Before OSGi people solved the problems it addresses in a custom manner, making it difficult to learn and build extensions for those models.

Azureus uses its own plugin model to create and deploy plugins, for this it then creates its own class loader, its own life cycle handlers, update managers, version comparitors, a way of creating and inserting plugins, and a whole lot of code that replicates functionality.

This model does not easily break down into OSGi modules which I thought it would.
It is not an easy process taking legacy code and moving it to OSGi bundles.
Dependencies on the plugin model is tight.

A side project that I would like to see is a set of refactoring tools to break legacy java code into OSGi bundles. If they exist please contact me, anything that would help. One such project I tried was Barrio plugin for Eclipse, this is beta and did not work, for unknown reasons.

 public static String toString(EObject eobject)
 {
  StringBuffer sb = new StringBuffer();
  EClass eClass = eobject.eClass();

  for (int i = 0, size = eClass.getFeatureCount(); i < size; ++i)
  {
   // Ignore derived features.
   //
   EStructuralFeature feature = eClass.getEStructuralFeature(i);
   if (!feature.isDerived())
   {
    sb.append(feature.getName() + ": ");
    Object obj = eobject.eGet(feature);
    if(obj == null) {
     sb.append("null"); 
    }
    else if(obj instanceof EObject)
    {
     sb.append(toString((EObject)obj));
    }
    else if(obj instanceof List)
    {
     List list = (List)obj;
     for(Object object : list)
     {
      if(object instanceof EObject)
      {
       sb.append(toString((EObject)object));
      }
      else
      {
       sb.append(object.toString());
      }
      sb.append(", ");
     }
    }
    else
    {
     sb.append(obj.toString());
    }
    sb.append("; ");
   }
  }
  return sb.toString();
 }

Problem: Want a multitouch for fun!!

Background: I started to build one a while back trying to use a wiimote for the camera. This seemed like a good idea as the wiimote does all its computation on the device, meaning that the computer would have more free CPU as it has to do no image processing. However the wiimote is far to insensitive for FTIR, it responds best to direct light from a IR source.
This setback made me rethink the problem. For a few months.
Some PhD students, from FlipMu and studying at the music school in Victoria University (Wellington, New Zealand), came and gave a talk on their uses of multitouch surfaces creating musical instruments. These guys inspired me to finish the project, and I had a little money that was doing nothing so I started the project back up.

Solution: Build it!

Step 1) The first step is to get the necessary parts together.
Camera: I am going to use the PS3 Eye Cam because it can do 120 frames per second, and that is impressive. I am using a 950nm filter that has been taxed from another project.
Display: I am using an old laptop that I ripped apart and turned (which I had a lot of help with) the LCD display into a flat unit.
Touch: 1cm thick Plexiglas that I bought as an off cut very cheap. This is backed by 2 layers of 3mm Plexiglas to hold the LCD in place.
Light: 8 950nm IR 1.5V at 100mA LED's.
Method: FTIR seems to be the only way for an LCD multitouch screen to work.
Unit: Initially I am building a testing rig, this way I can test different methods and find the optimum method and strategy before putting all the work into a proper case.

Step 2) Unit: Build experimental unit, cut grind and make Plexiglas layers. This step took significantly longer than it took you to read that sentence.

Step 3) Electronics: Solder up LED's, extract laptop LCD and parts, remove IR filter from PS3 eye (the best instruction videos are here). This is another step that took longer than it seems.

Step 4) Put Together: So put the unit together and experiment.






Experimentation) Increase LED Count: Initial Experiments show that I need more LEDs. At high frame rates in the Eye Cam the exposure is not enough to see the blobs. So the first step is to increase the LED amount, I am thinking of increasing it to 30.
LED Efficacy: Maximising the effect of the LEDs by placeing them inside the surface, correct angle, liberal use of reflective tape, all to hopefully greatly increasing the efficacy of the LEDs.
Complaint Surface: I have no surface over the Plexiglas for prtection or increasing the FTIR effect. I am going to experiment with different layers of silicone. I have read it is difficult to keep the surface see though with a coat of silicone.

Future) Programming: What I really want is a nice interface between a multitouch screen and the OS. I do not want a custom multitouch OS, because then the technology will always stay niche. I want an interface that can replace the keyboard and mouse while staying fully functional.
The end goal of which is a full media center, probably XBMC, fully interactive with a multitouch display, for selecting movies and music.


Links: Jeff Han: for Multitouch renasonce
Jonny Chung Lee: for Wiimote experiments