Saturday, 27 December 2008
Within Solstice we use a static implementation of the LogService interface which we can access through a static final variable and is made available in the core bundle which pretty much all other bundles import a package from. This implementation simply logs to System.out and is cunningly called SystemOutLogService. The reason it exists is just in case a LogService has not been registered with the container. To be honest, this seems pretty redundant since Solstice is an OSGi implementation (based on Equinox) and we're fully in control of what is in the distribution. Also, this doesn't seem very elegant.
In our recent release of AMF3 for OSGi I have assumed (and it is in the documentation) that a LogService will be available. At least one of the bundles tracks LogService implementations and then injects them were needed. However, OSGi is dynamic, so I can't assume that everyone will want to have a LogService implementation. So what is the solution?
One idea is to re-implement the SystemOutLogService, but I don't want there to be a core bundle that each of the bundles depends on (either explicitly, or implicitly through packages). Further more, I might as well just register my own implementation of LogService if I am going to do that - but then how do we make sure that other LogServices get priority? Well, this is possible by setting the OSGi service priority to a low number and then making sure we use the one with the highest priority. However, this is moot since I don't want to provide this functionality at all, or put any logic to handle the priority of LogService implementations in to my trackers.
So, we fall back to System.err by doing a null check on the injected LogService implementation. I'm not really happy with this either, but it is the default thing to do for Java as it is the only thing that can really be depended on to exist.
My feeling therefore, is that logging should be available at a more fundamental level, i.e. in the core specification. A logging API has been available in Java since 1.4, not that I have ever used it as I have generally used Log4j outside of OSGi. I don't think that LogService should be deprecated, but rather than having to look up a log service, you should be able to call a log method on the BundleContext which does something 'default' or delegates to any registered LogService implementations by priority. I guess that implies that a default LogService could be accessed from BundleContext instead, which further implies that LogService should become part of the core specification ... any thoughts on that out there?
By the way, we've created a Jira for Solstice, AMF3 for OSGi and any other open source projects, please feel free to create issues:
And finally ... anyone who's already downloaded the AMF3 for OSGi distribution already may have noticed that the source for the HTTP bundle was a copy of the Flex Remoting bundle. That's been fixed, please re-download it!
Tuesday, 16 December 2008
AMF3 for OSGi is a collection of bundles that adds AMF3 serialisation, AMF3 over HTTP and Flex Remoting of OSGi services capabilities to your OSGi applications.
Best of all, this is released with a LGPL license.
For the full details and downloads visit this page:
Sunday, 7 December 2008
Monday, 1 December 2008
Thanks to Matt at Arum for finishing it off by adding all the images - even I don't know what's in there! :)
Wednesday, 26 November 2008
I have also managed to create a set of bundles which allow Flex Remoting via AMF3 in a pure OSGi environment (i.e. no BlazeDS). However, they are not a replacement for BlazeDS, they are just something different and provide no "data services" to speak of, other than allowing developers to register their OSGi services and then access them from their Flex applications. A sample application will be provided. Once I get the thumbs up from the lawyers and my boss I intend to release them, so watch this space.
Since I couldn't sleep this evening (I have only been in my new house less then a month and things are still a little strange) I decided to see how Diablo III was progressing. I am really looking forward to this game. I noticed they had a Fansite Kit available for download, so I took a look. I didn't intend to build a fansite, I'm not a web designer, but I have been looking for an opportunity to play with Adobe's Cocomo SDK and see what it is about.
The result is the linked page. http://diabloiii.brindy.org.uk/
Cocomo is really simple and seems to be very comprehensive in the things it lets you do. My application is really just a simple Flex application with no server back end. All the server stuff is provided by the "connectnow" service at acrobat.com (http://connectnow.acrobat.com/).
The only things I don't like about it are the examples aren't really good examples of best practice approaches and even goes against some of the things Adobe says not to do (lots of containers within containers) and the other thing is to do with containers directly. Adobe seem to love them and seem to love inheritance as an approach to specialism. I prefer composition over inheritance, and while there's a bit of that in there too, what you end up with is a complicated mess of container hierarchy, models and so on.
But really, if you're used to Flex, this won't be a shock, so don't let it put you off!
I am thinking that Cocomo combined with the the Facebook API for Flex that I found here might be very interesting...
Friday, 17 October 2008
Firstly, I'm going presume that the reader is familiar with Eclipse IDE. If so, then the reader has already been using OSGi and probably doesn't even realise it.
The Eclipse IDE is constructed from Plugins. Plugins are effectively OSGi bundles with a bit extra (usually a plugin.xml, sometimes a little more).
Eclipse is built on top of Equinox which is an implementation of the OSGi specification and then goes on to extend it with the Plugin Registry.
At its core an OSGi bundle is a standard Java JAR file with some extra information in the MANIFEST.MF which describes the bundle to the OSGi platform it is deployed to. The manifest describes things like the bundle's name, version, what packages and/or other bundles it depends on, what packages it exposes, and probably a fair chunk of other stuff I haven't mentioned.
OSGi is a service oriented architecture. This is quite an important point to me as most people hear or read SOA and automatically assume Web Services. Well Web Services are just one type of SOA. The specification of OSGi is inherently, and by design, service oriented.
Like I said, bundles can declare what packages they expose, but more importantly they declare and/or register services.
A service is essentially a Java interface and can be implemented by one or more bundles. A bundle that needs to use a particular service looks it up (or "tracks" when services are registered/unregistered) and then decides which service to use either by taking the first one it finds, or by homing in on a service that meets a specific need by specifying some service properties.
The most important thing is that services are dynamic. They can come and go and this is a part of the specification and something that any one who writes bundles has to accept and deal with.
As a result, OSGi has a tightly defined classloader mechanism which manages version control. You can have two bundles installed on your OSGi platform that expose the different versions of the same package, then other bundles can be explicit about which package version they depend on or not.
The OSGi specification consists of a core specification and a service compendium. The core specification is enough to write modular Java applications and the service compendium details a selection of services that OSGi implementations will usually implement a common set of, if not all of. These include things like Logging, Declarative Services (services can be declared using XML), HTTP service (you can expose web resources from a compliant container, some even support JSPs!) and others. See this page for more information:
Finally, what I haven't mentioned is that OSGi has been around for nearly a decade. It was originally intended for use as a dynamic platform for embedded devices but IMHO is really starting to make its mark through use on the desktop and (enterprise) server areas, especially in the last couple of years.
When you get in to it, the power of OSGi is mind boggling. Yet OSGi is simple and logical, while remaining comprehensive. OSGi is the modularity that Java is missing.
I hope my brief description of OSGi does it justice. I deliberately wanted to keep it short and sweet and whet some appetites.
Monday, 6 October 2008
Talking abot technology is just too low level for that first business pre-sales pitch... but as Vince pointed out, and I have to agree, this is not the case with Flex.
Somehow Flex has a "coolness" about it that can sell itself. So while pitching yourself as RIA specialists, if you used Flex you would most likely mention it and mention Adobe and the majority of customers would probably feel pretty good about your pitch as a result.
This is pretty funny, because the Adobe marketing machine is pretty agressive, but apart from a few minor features I am yet to see something done in Flex that couldn't be done in GWT (or some other Ajax/RIA framework).
This raises question, "why am I using Flex?". The one thing it does have, which the other frameworks don't seem to, is modularity. I've mentioned this before, it gives Flex developers the ability to put big lumps of code in to different SWF files which are loaded as needed. We take advantage of that (and OSGi on the server) in Solstice to create our modular RIA platform.
Can't do that with GWT, it's an all or nothing approach. Want to add a new feature? Recompile you're whole application.
I just wish Adobe would see the value of OSGi and get on board. BlazeDS would be an awesome OSGi bundle.
Saturday, 27 September 2008
As a result I have embarked on a little side project... Music Brain. It has probably been done before, but it is really just a programming exercise for myself more than a serious project.
Problem: The new Metallica album, Death Magentic, was released recently and I want to know how "Metallica" it really it is. My gut feeling has a human is that it's pretty Metallica. :) But I got to wondering if a computer could make the same judgement?
Solution: Train a neural net with my library of Metallica tracks, except for the current album. Then run the new album through the neural net and see if the program agrees that this is a Metallica album. I will also run a few other band's tracks through the neural net after training has been completed and see what it "thinks" about them. Hopefully the program should be able to differentiate between existing Metallica tracks and other bands, while being able to identify new Metallica music.
Approach: Somehow I will have to extract the music from my music library and feed it in to the neural net. How many input nodes will I need? How can I extract the raw music?
Today's first steps were to read up on the WAV file format. It is a pretty straight forward format and using the information on this page I was able to create a "WAVIterator" class which takes an input stream and using the Iterator pattern allows me to pull "MusicSamples" out of a WAV file. In my API a "MusicSample" contains a one or more channels of data for a very small slice of time.
I have placed some restrictions on the files I am going to be able to parse in order to make life easier. Basically the WAV file must have been recored with 16 bits using PCM (Uncompressed) at 44100hz. I figured this is close to CD quality and good enough for the human ear so it would be good enough for this program.
The resulting test program was an interesting and humbling reminder about how slow using an unbuffered FileInputStream really is. My test code was taking nearly 100 seconds to parse the WAV file which was a little disappointing. So I decided to load the whole file in to memory first and use a ByteArrayInputStream instead. Wow! This reduced the parse time to just over 4 seconds, much more like it.
However there are a number of problems with this approach. Firstly, what if the file size is greater that Integer.MAX_VALUE? i.e. larger than the maximum size of a primitive array in Java. This is unlikely to happen since Integer.MAX_VALUE is 2^31 - 1, or 2147483647 (i.e. about 2gb), but that leads on to the next problem, you're soon going to run out of memory if you create 2gb byte arrays. It just isn't good practice to make the assumption that your files will be small enough and/or risk trying to allocate an array that big.
Of course, after a minute's pondering I remembered that there's a class just for this type of occasion; BufferedInputStream. So I replaced 9 or 10 lines of code and wrapped my FileInputStream in a BufferedInputStream and the performance was just as good. It feels good to get back to basics sometimes.
My next tasks will be to work out how to create a neural net in Java with appropriate inputs and outputs for my extracted music data. I don't really want to code a whole neural net, so I will probably use an existing framework... more next time.
Thursday, 11 September 2008
Thursday, 14 August 2008
Firstly (and most importantly) I got married and then had a two week honeymoon in the Maldives. It was lovely and I managed to avoid using computers for the whole time we were away. Bliss. I hate computers. :)
Secondly, I've been working hard on Arum's flagship product, Arum DataEye and I am happy to report that we successfully deployed v1.0 of the software to our first of many customers yesterday.
Arum DataEye is a near-real time, management information, dashboard and alerting system build on Solstice which, as readers will know, combines Flex and OSGi to enable rich modular Internet applications. As such, we can deploy new components for the dashboard as well as provide a dynamic integration layer simply by providing new bundles. This also means we can customise the application for a customer's specific needs without affecting the entire code base. Existing customers can rest assured that they'll receive the latest code as part of their support agreement without having to worry that another customer's specific requirements will affect their system.
For those interested in Solstice, an alpha version of Solstice can be downloaded from Arum's website and I'll be updating this in the next couple of weeks with the production version we deployed yesterday. I'll also be providing some much needed documentation and an example application for interested people to dissect.
My workload for the next few weeks mainly involves designing and implementing the integration bundles for our customer before we go live in October as well as making a concerted effort on the book I've been promising to write for a couple of months.
Tuesday, 20 May 2008
- If the services it depends on are not available (HttpService, LogService) then it continues to activate, when really it should throw an exception, or even better use a ServiceTracker to dynamically track the services.
- What if there's more than one HttpService?
- It requests a LogService then uses System.out
- It registers itself as a bundle listener before creating an instance of the ServiceRegistry. In the unlikely event that a bundle state changes while this bundle is activating you could get a NullPointerException in the
bundleChangedwhen trying to called the methods on the registry instance.
- Note the big block of code already commented out... that would stop any services which are already registered from being exposed as web services. Remember that OSGi is a very dynamic environment things can come and go as well as already be there when your bundles start.
- While not strictly required (I believe), during the stop() method it is good practice to call ungetService on any services references that have been acquired.
As for the rest of the code, I'm not qualified to comment as I don't know the inner workings of Axis2, so I'm just going to give it a try and see what happens. Watch this space.
Tuesday, 13 May 2008
var split:Array = someString.split(/\./);
which will of course split "someString" using "." as a delimeter. Of course, all that's really happening is that the regular expression is being converted to an object by the compiler, so the following is the same:
var regexp:RegExp = /\./;
var split:Array = someString.split(regexp);
This is superiour to Java's approach which allows you to specify a regular expression as a String when calling split, the problem being that the above regexp would look like this:
String regExp = "/\\./";
Note how I have to escape the escape character!
Of course, Java has a whole package for regular expression handling, but they all suffer the same problem of having to encode the regular expression in a string and thus having to escape the escape characters... which makes long regular expressions very complicated and as a result I suspect a lot of Java developers simply avoid using regular expressions for that reason. In my view inlining regular expressions is definately a candidate for being added to the core Java language.
Thursday, 1 May 2008
a completely module-based Java application server that is based on the new SpringSource Dynamic Module Kernel™ (dm-Kernel). The dm-Kernel harnesses the power of Spring, Apache Tomcat and OSGi-based technologies to give the platform incredible flexibility and resilience for both development and production.Effectively an OSGi container with some Spring stuff thrown in and another step in the right direction away from the J2EE world.
Referred to as S2AP, the SpringSource Application Platform announcement generated a fair amount of interest and discussion so I decided to cut to the chase and ask Rob Harrop of SpringSource to clarify a few issues.
Firstly, not being a lawyer or Open Source license expert I was a little confused about the implication of using GPL as the Open Source license for the server. Rob managed to clarify this succinctly:
A useful summary of what using GPL means. Next up, I was interested in what S2AP brings to the table if, like me, you're not a user of Spring and currently have no plans to be.
If you are running applications on the S2AP, then there are no requirements placed on you. If you distribute an application including S2AP or GPL components thereof, then you would either need to license your application under GPL or purchase a commercial license from us.
My interest is definately peaked now, so I think I will be checking it out in my next development lul or as a distraction from development grind. However, I had one outstanding question regarding a specific piece of functionality that I have been hoping someone would save me the bother of having to implement. It occurs to me that it would be very helpful if I can register a service with the OSGi context and some other bundle automatically makes that service available as a web service. Spring has some functionality enabled rapid development of WebServices, so I asked Rob if this is something that S2AP can help me out with.
S2AP contains a lot of additional benefits on top of plain OSGi. For starters, OSGi aside, its just a good, solid server platform. We have extensive serviceability features including active deadlock monitoring, detailed trace and first failure data capture. We have provisioning support that makes it easier to handle the installation of hundreds of bundles into your runtime environment. The pre-embedded Tomcat is plus point - that was a lot of work.
There a lot of under the hood tweaks, including resource loading support that works in standard libraries such as Jasper (JSP), load-time weaving support and advanced refresh that handles more module dependencies than those currently handled by the OSGi spec.
Publishing OSGi services as WebServices is on our roadmap, but it won't be available for 1.0 final.Fair enough. As it happens there is already a Knoplerfish bundle that can do this, but its implementation is not compatible with newer SOAP clients.
So in conclusion, it looks as though S2AP is worth keeping an eye on for the future of OSGi containers. If it lives up to its instant hype and the features described by Rob it is will be a robust platform for purist OSGi developers like myself, as well appealling to those already in the Spring camp.
For more information on S2AP, you can check out Rob's blog entry: Introducing the SpringSource Application Platform
Friday, 18 April 2008
Wednesday, 16 April 2008
Yes, Java is missing modularity, especially when compared to what the OSGi specification adds, but I like Java just the way it is. OSGi is a fantastic specification for enabling modularity on a great a programming language. If you "clutter" (for want of a better word) the core language with such things, it stifles creativity at the foundation level. So I will always vote to keep them seperate, but adoption of the specification by Sun is fantastic news for everyone.
I also think this is fantastic news because I see J2EE and RDMBS becoming obsolete eventually. My "dream architecture" is based on OSGi and OODBMS and some kind of open UI specification not implemented in the core language. Swing is cool, don't get me wrong, but again I'm all for seperating the core language from such things as UI.
As readers will probably know my current UI preference is Flex, which is obviously nothing to do with the core Java language, but it is highly compatible and an extremely productive environment for developing applications with a UI. Adobe are often criticised for not opening Flex in to an open specification, but I can understand why it isn't and the underlying programming language (ActionScript) actually is an open specification already.
Right now, for enterprise web based applications my technology choices would be:
- "Server enabled" Equinox
- Db4o for the database
- Flex for the user interface
For desktop applications I will still jump back to using Eclipse RCP, but AIR is becoming more attractive and I am heading to it as a preference because now that I am becoming more experienced with Flex I am finding it easier to build user interfaces with Flex than with Eclipse, even with my Eclipse SDK experience. A lot of that is down to the simplicity of the APIs and some of the language features (e.g. variable bindings). Also, the skinning you can do with Flex apps is very good indeed. My current favourite skin/theme is this:
How could you do that with Eclipse?
Still, with E4 on the horizon and the rumours I've been hearing and screenshots I've been seeing, Eclipse will continue to have a lot of attraction to a lot of people. I will be finding out more about it in detail on Friday.
Friday, 14 March 2008
What is the difference between OSGi and Eclipse?
OSGi is the foundation of the Eclipse platform. Eclipse is built on top of OSGi.
OSGi has the concept of "bundles" which are modular Java components. Eclipse takes that concept and extends it to what most developers know are "plugins". A plugin though is just a bundle with a plugin.xml file. The plugin.xml file tells Eclipse how to deal with that particular bundle and defines extensions and extension points, more concepts that build on OSGi, though OSGi is predominantly service oriented.
The high level stack for Eclipse is:
- Equinox (an implementation of OSGi)
- Eclipse (SWT, JFace, etc)
Solstice vs RCP
Eclipse is a great platform for building modular rich applications for the desktop and there is certainly progress towards being able to deliver these applications over the web (I'm talking specifically of RAP). My understanding though is that RAP isn't mature yet and personally I'm not keen on AJAX or in fact having any dependancy on browser technologies. I prefer cross-platform runtimes such as Java or Flash Player.
For me the advantage of using Flex (especially when used with Solstice) over Eclipse RCP are:
- Reduced footprint for installation of the software. Flash Player is small and the binaries for your application will be much smaller compared to Eclipse.
- Easier to deliver the software to the users. Flex applications are delievered via the web, whereas Eclipse requires some installation.
- Consistent platform for development.
- Flash Player is identical across all supported platforms and according to Adobe at least some version of Flash Player is now present on 98% of all computers with FlashPlayer 9 coming in around 90%-95%.
- SWT doesn't support all platforms in the same way.
- Eclipse UIs look native.
- Flex is easier to learn than RCP. I'm a software engineer / developer with more than 10 years experience (8 of that using Java) and found the learning curve for Eclipse to be very steep, but I persisted because Eclipse is "cool". Though I can create simple plugins quite quickly these days when I try and do something with Eclipse the complexity of the platform leaves me feeling unproductive. When I got my job with Arum I learnt Flex in a matter of weeks.
- Flex allows developers to be creative with the UI. This is a duel edged sword really. Eclipse has a constistent UI (subject to native look and feel), but I have seen some stuff done with Flex that I couldn't dream of doing in Eclipse. Either that or you have to install or develop entire new frameworks to achieve something relatively (e.g. GEF for graphical editing, but it can't even rotate a text label!). The other side of that sword is that the UIs I personally produce still look very developer oriented (like an Eclipse app) and you really need that creative flare to do the exciting things I seen done with Flex. My focus is on the Java/Server side of things anyway, so I'm not too worried about that aspect of things. My colleagues are much better at Flex UIs than I am.
Flex is great but I felt as though I was missing out on the modular power that OSGi and the Eclipse RCP gives developers, which was my starting point when putting together Solstice. Using the Equinox and BlazeDS I managed to put a Flex UI in front of an OSGi container in an afternoon and I just carried on from there.
Flex has the concept of modules, but mainly for the puropse of reducing perceived load times. It seemed obvious to me that the dynamic ability of the Flash platform could end up creating an alternative to RCP.
Solstice is a good step towards that. Developers can still use the OSGi and all those good things that go with it (component oriented, service oriented) without feeling as though the only option for a UI is the Eclipse RCP or HTML website exposed through the HttpService.
Tuesday, 11 March 2008
A view will appear that will attempt to render the current document as though it was a MediaWiki page.
Monday, 10 March 2008
Solstice is based on the following technology:
- Adobe Flex
- Eclipse Equinox
- Eclipse Equinox Servlet Bridge
- Apache Felix
Wednesday, 27 February 2008
This evening I'm tinkering with my "webwar" game again. I decided to use a ColumnChart instead of a form and labels (ahem, very developerish!) to show the status of "resources". The problem I was having was that my resources are expressed as properties on a single object:
public class Resources
public var earth:int = 0;
public var fire:int = 0;
public var metal:int = 0;
public var water:int = 0;
public var wood:int = 0;
The dataProvider for a ChartBase subclass has to implement the IList or ICollectionView interface which obviously Object does not. I played around with various bindings, setting the dataProvider on the ColumnSeries instead of the chart, with little success. Eventually I came up with this, which seems to work, but I'm not sure if it's the most appropriate method or not (will check with Vince tomorrow!)
So rather than setting the object as the dataProvider, I set this array collection as the dataProvider and bind the elements of the Resource object to my custom collection.
So apart from that, we're still doing some cool stuff with Flex and OSGi at work and we will have an alpha release of our Solstice framework this week! Promise.
Wednesday, 13 February 2008
Tuesday, 12 February 2008
As a result, we have combined OSGi, Flex and BlazeDS in order to develop a Modular RIA/RS (Rich Internet Application/Rich Server) Framework that we've called Solstice. An official announcment will be made before the end of this month, but I wanted to give a quick overview of what's going on in my head ahead of that announcement.
I had previously tried to achieve the same thing with GWT, but I had two main problems with GWT:
- lack of modularity
- lack of visuality
Although I'm not a Microsoft technology fan, I have to admit that I have always admired their approach to building UIs. That is, a developer literally builds the UI. Of course, they can add code on clicks and so on, but they know exactly what they are going to get as they are building it because they can see the graphical representation of it at build time, rather than runtime unlike GWT (and even Java) which is only recently starting to see fairly immature graphical builder tools being made available. However, throughout my career I have found Microsoft technology to be quite inaccessible and have never been lucky enough to be in a job where I can get my hands on the tools and have time to play with them at the same time.
All this changed when I joined Arum Systems' RIA team. My background is Java/J2EE of course, and they needed a strong developer with good Java experience and all the other "senior" stuff (aka "hardcore") to round off the team's skillset. Being "hardcore" I set about learning Flex, which was helped a lot by the fact that it is so easy to get your hands on, install and just get going with. I was very excited when I saw the visual nature of the Flex Builder tool, especially that it is part of the Eclipse IDE - I felt right at home from the outset.
I'm the first to admit, I'm no UI expert. Some of the Flash/Flex stuff out there is just amazing, but my focus really is software engineering and product development. I think this is why Eclipse RCP appealed to me - it removes the choices about the UI from the developer which is good and bad for many reasons. Ultimately, RCP and even plugin development appears to be a very niche/elite developer market because the learning curve is so steep and some of the architectural decisions made by the Eclipse team are questionable. Flex on the other hand is very easy to get in to whether you come from a web design background or a Java background. The learning curve is long, but shallow.
So, the business model for our new product calls for a lot of flexibility (no pun intended). We don't plan on mass selling a shrink wrapped product, instead we plan on targetting a selected group of new and existing customers with varying integration needs. One option was simply to "copy and paste" the product for each customer, but this seemed wasteful to me, so instead I drew on my experience of Eclipse plugin development, and more specifically my growing experience with OSGi, in order to propose an architecture that lets us build a product that is 80% complete for all customers, with only 20% left as integration consultancy.
Combining those concepts with Flex allows us to build modular ich internet applications and rich server applications. Combining these two key technologies in to the Solstice framework allows us to:
- extend our product quickly and easily for multiple customers without having to maintain multiple codebases
- maximsing profit by enabling re-use
- reduce time to market and costs for our customers
Solstice will be available by the end of this month as a fully open source framework. Documentation, examples and tutorials will be available and I am hoping to talk about it at Flex360 Europe in April.
Wednesday, 6 February 2008
The main thing I wanted to play with last night was the “graph” in the middle section, which is “SpringGraph” by Mark Shepherd (Flex Builder team). The graph uses a custom renderer in order to draw the pie charts and show a tool tip. I had started writing my own and realised this graph view had probably been in the past so did a quick Google and there was SpringGraph.
The pie charts are just drawn as “wedges” on a custom component created using a Drawing library from Ric Ewing updated for AS2 by Kevin Williams and now for Flex by me. You can get a copy of it using the link below.
My main change was to pass a graphics context in to each of the methods and a few other bits of tidying up. It's pretty cool and lets you easily draw polygons, stars, wedges and "gears". Very handy for weird shaped custom components. Just subclass Canvas and draw using this library. Flex is neat in that by default it only seems to detect mouse events over drawn areas making those weird shaped components feel as though they are really weirdly shaped rather than just a rectangle with a drawing in them.
Tuesday, 29 January 2008
For now though, just for fun, I decided it would be nice to be able to monitor our continuous integration environment (CruiseControl) in a slightly different way.
I got myself a USB experiment kit which has various inputs and outputs that can all be accessed via USB. Our CruiseControl runs on Linux, but exposes various ways of querying the status of the builds. I decided to run the hardware on the same Linux box, but use the XML for CCTray interface over HTTP, so in theory the USB kit could run anywhere - subject to an appropriate library being available for the OS.
The kit ships with a DLL for Windows but this wasn't going to be much use on Linux, so I downloaded the k8055 library for Linux which kindly replicates the DLL as a linux library.
My usual programming language is Java and that's what I wanted to work with for this project, so I decided to try out JNA which saves you the bother of writing JNI code - it simply wraps a shared object or DLL and maps it to an interface at runtime. Very handy!
In no time I had a Java program wrote which queried the XML from Cruise and was controlling the experiement kit.... a Cylon/Knight Rider display for when Cruise was building and a all lights flashing output for when the build was broken.
The only real problem I had was that when I first tried to run my code on Linux (I had it working on Windows in Eclipse IDE first using a stub for the interface which simulated the USB device), I got the following message:
symbol lookup error: /usr/lib/libk8055.so: undefined
The solution was simply to add "-shared" as a linker option for the shared library in k8055's Makefile, clean build and that was it!