Remote services

Recently I experimented with OSGi remote services using Apache Aries (blueprint services) with either Apache Tuscany or Apache CXF to provide the remoting capability.

I was trying to find the simplest and most flexible way to do this:

There are two OSGi runtimes (R1 and R2),  a bundle in R1 is using a service supplied by a bundle in R2.

For those of you who don't want to do a lot of reading the short summary is:

• The simplest way to do this is Apache CXF
• The most flexible way to do this is to use Apache Tuscany

Let's start with a few words about CXF. The part you need to do this is Distributed OSGi . There are very good samples with the project and I only encountered two issues with achieving what I wanted to. The first of these is that the multi-bundle distribution doesn't run on Equinox so you have to use the single bundle distribution or use Felix. I elected to use the single bundle distribution on Equinox.
The second issue was that I had a web bundle in one framework and had some problems with conflicts on http port which I didn't properly resolve. I found that I could work around them by configuring the http port to anything except 8080, for example:

org.osgi.service.http.port=6969

in the Equinox config.ini file. If you are trying to debug an application which uses CXF it is also worth understanding that the consumer runtime (R1)  registers a proxy service based on the WSDL produced from the provider (R2) runtime - this proxy service is not registered until something in R1 tries to use it.

Apache Tuscany  provides the same functionality as CXF and a lot more besides. I wanted to use Tuscany because I want to get onto the other things I can do with it later, for example Tuscany supports other component models (eg EJB) and other bindings (JMS, JCA, json-rpc and so on).  I used a sample banking application (developed by Graham Charters et al. for the 2010 OSGi Community Event), the code for the application and all of the SCA configuration is checked in here. The application had already been run on IBM's WebSphere Application Server so all I had to do was figure out how to do it on a pure open source stack. How hard could it be?
The application itself and the SCA configuration are both very simple. The picture below shows the relationships between  bundles and how the bundles are distributed between OSGi runtimes. The API bundle is, of course, installed in both runtimes.

As usual with Apache Aries samples,  I have tried to make it as simple as possible to run. If you want to run this sample you will currently (it is not released) need to check out and build Aries, then from the ~/samples-sandbox/bank directory just use 'mvn clean install' to build the sample.


To run the sample, change directory to bank-assembly/target and run:

sh runclient.sh - to start the client runtime (Runtime 1)
sh runserver.sh - to start the server runtime (Runtime 2)

(apologies - I don't have equivalent .bat files)

You can check that the server is producing WSDL by navigating to:

http://localhost:8081/creditcheck?wsdl

http://localhost:8081/lineofcredit?wsdl

http://localhost:8081/chequing?wsdl

And that the client is running navigating to:

http://127.0.0.1:9090/bank/index.html

That all looks wonderfully simple - and it is. So why did I imply this was hard?

Tuscany is a big project and I just wanted to use a bit of it - all of the difficulties I had were connected with putting together an OSGi Tuscany runtime that had what I needed. Of course, if I had used a commercial application server (like IBM's WAS) someone would have done all this for me and there would have been no pain at all.

If you look at the bank-assembly/pom.xml you will see that I am actually downloading an entire Tuscany distro, unpacking it and then using the Equinox config file to pull in the bundles that I need for the OSGi runtime.
Finding the correct bundles would have been very difficult without the help of the Tuscany team - they told me what I'd need.

This solution is far from ideal. A slightly better solution would be to specify the list of bundles that I need in the pom.xml and have Maven get them for me as we do in all the other Aries samples. The reason that I can't do this is that Tuscany found that many of the OSGi bundles they wanted didn't exist or were badly put together - so they have fixed them - which is great! But they have fixed them in the Tuscany distro only - which is slightly less great from the point of view of a consumer. It would have been nice if they had followed the ServiceMix model and simply made the fixed bundles available.

The best solution (which we don't have at all yet) would be to have a proper bundle repository somewhere and use a resolver to go to it and get the OSGi bundles I needed - whatever they might be. One day there will be such a repository - but it's going to take some effort to build :-) Until then hacking-it-up is the only way.

The other thing that I hope will happen sometime soon is for Apache Tuscany to be able to work with the recently implemented Aries Application model. As it stands, I don't use the Aries Application model in the Bank sample, it is just a set of OSGi bundles. 

In summary, I like Tuscany and I'll go on to try and use other bindings with OSGi applications. The fact that it wasn't easy to pull together the right OSGi platform says more about where we are with OSGi today than about Tuscany. For wide scale enterprise OSGi adoption to happen we need a bundle repository. Tuscany have implemented a workaround (which I don't like), ServiceMix have implemented a work around which is much better - but the right answer is a bundle repository and as soon as possible, yesterday even.

Oracle meet IBM at the LJCOpenConference

The LJC Open Conference last Saturday was the best! We had 75 people and a packed agenda with talks ranging from the "Java Roadmap" through to "The Diabolical Developer". Martijn Verburg, captured below, was the diabolical developer:

And he was, in fact, awesome...and very diabolical.

Steve Elliot from Oracle and Steve Poole IBM answered questions on their future together in Java:

It's still early days and the LJC organisers clearly thought it was prudent to separate the Steves with Martijn and Ben - although I'm not sure if they were worried about them getting too friendly or the reverse. Nice touch to have coordinated the names though - if you want become a contribute to the OpenJDK being called 'Steve' looks like a good first step.

Igor - have you watered the brains today, Igor?

In his keynote at ApacheCon 2010, Dana Blankenhorn noticed 'middle aged men dressed like college students' and then went on to liken us to the Knights of the Round Table.

I won't dispute the Camelot analogy - but I do want to take issue with  'middle aged men'. Middled aged is probably justifiable on average but it ignores the fact that there were a reasonable percentage of both old and young - and - no kidding - some of us are even female.

The youth were brought in by a wonderful organisation that I knew little about till earlier year - the Apache TAC . The TAC enables great programmers early in their career who are  unlikely to be able to get employers to sponsor their travel and even more unlikely to be able to pay for themselves get a chance to come along and participate. This is great for them but it's also very necessary for the future of the ASF a good dose of wild youth counters the tendency of these organisations to turn crumbly and nostalgic.

After the conference a few of us (including Igor of the blog title)  had to hang out in Atlanta for the weekend and ended up in Blind Willies, Atlanta's finest blues bar. We, Igor and I, danced till the early hours to the music of House Rocker Johnson. So in future I would like to suggest another question on the TAC form:

• Are you prepared to dance like nobody is watching?

Anyone who can't commit (without a reasonable excuse) should be consigned to the 'encroaching middle age bucket' and discarded.

By the way - for those of you who are almost certainly too young to recognise it - the title quote is a reference to 'The Monster Mash' from the 1969 Bonzo Dog album 'Tadpoles'.  I like the idea that younger delegates might inject a bit of life into the proceedings and don't intend to extend the analogy any further than that :-)

ApacheCon Atlanta

So that was my first ApacheCon - if you don't count the one in Dublin at which I drank far too much Guiness and decided on a career change which took me on a slightly circuitous route through  PHP  and back to Apache again.

It was a pretty amazing conference all round - great to meet Lin Sun, Jarek Gawor, Kevan Miller and others from IBM. Also great to meet new Apache people  - and catch up with the ones I already knew.

AWESOME that IBM is a gold sponsor of the ASF - well done whoever made that happen!

As usual I learned a lot about technology - Kevan had a nice slide explaining which other Apache projects are used in Geronimo - I had no idea.  I do like this philosophy - no need to re-invent wheels when there are Apache projects which provide spokes, hubs, rims and tyres.

Send your developers to JAX!

Last month I, and a number of developers from IBM's Hursley labs, went to JAX London; I'm delighted to say that we were a gold sponsor this year. I was going to write about the conference before but sadly I didn't get to see (m)any of the sessions because I was responsible for  the IBM demo area and spent most of my time talking to people about what IBM does with OSGi.

In between talking to people, my view of the conference was mainly looking at the other sponsor's stands. So, here are some observations based on what I saw:

1. This is a great UK conference to sponsor if you want to reach Java developers.
2. The busiest stands were the ones that had tools demos and/or were able to sell interesting stories about  work that they were involved in - or they were hiring :-)

If you are going to sponsor a developer conference, which I strongly recommend,  send your developers to run the stand....or at least your tech sales people. Don't send the salesmen. Seriously, no-one will walk away from this conference with a bunch of orders - you won't close a sale here. The aim is inspire people with a vision of how working with you and your products will make their life easier, more profitable and more fun (in a tech sort of way) - that message will get back to the people with hard cash. Trust me.

Here's my favourite image  from the conference - taken at about 19:00 by a slightly wobbly photographer - I have appropriated the Microsft stand - which was looking a little lonely.

By the way, I am a recovering Windows user - I've been free for nearly three years now, so it took me several beers to get this close....

Testing bundles with PAX Exam

For integration testing OSGi bundles there is pretty much only one option - it's PAX Exam.  This week, as part of preparing a talk for ApacheCon I decided I wanted to have a simple 'HelloWorld' test showing the use of PAX Exam. It was all pretty straightforward - except for one thing that took hours to resolve - I thought the one thing might be worth mentioning.

I use Maven to build with, the application I was trying to write a test for was a stand alone version of this OSGi Blueprint Hello World sample. The application is pretty trivial and so is the test case. I used Craig Walls' tutorial to get me started.


So, what was the problem? This was what happened when I ran 'mvn install' in my test project in an attempt to run my test case:

I had no idea why anything was looking for com/sun/jdmk/jmxtools/1.2.1/jmxtools-1.2.1.jar, it certainly wasn't something I'd specified as a dependency in the project pom. Eventually, after much searching around, I looked at the Apache Aries default-parent pom and noted that some 'exclusions' had been added to the pax-logging section. I copied the same exclusions into my test project's pom and everything just worked.  The relevant sections of the pom are highlighted below:

Hope this helps - apart from that small problem I really like PAX Exam :-)

GOAT (Graphical OSGi Analysis Tools) is one of the Apache Aries samples. It's not released code but can be found in SVN and is easily built. Check building Aries to see how.

When you have built the project, navigate to the samples/goat/goat-assembly/target directory and run the sample by typing:

java -jar osgi-3.5.0.v20090520.jar -console

Have a look at the bundles (using 'ss'), you should see several 'goat' bundles active. Now, so that you can look at it later, install the Aries JDBC blog sample into the same framework. You should be able to do this just by copying the samples/blog/blog-jdbc-eba/target/*.eba into the goat-assembly/target/load directory.

Check that the blog sample is running by navigating to http://localhost:8080/org.apache.aries.samples.blog.web/, you should see this:

Click on 'Create Author' and create an author.

Now, in a different browser window, navigate to http://127.0.0.1:8080/org.apache.aries.samples.goat.web/web/. You should see this:

Not very exciting. Click on the drop-down beside 'DummyProvider' and select 'BundleContextModel', then click 'Use Provider'. Wait a few seconds while the screen builds itself, it should look like this:

On the left hand side you'll the same list of bundles as you saw with 'ss' from the command line, in the right hand area you can see each bundle drawn as an oblong shape. Since we are displaying all the bundles in the platform this is probably a bit too much information. Hit the 'Hide all' button at the top to get rid of them.

Use the slider to move down the list of bundles on the left until you get to the blog sample bundles. Click on 'show' for each blog sample bundle, grab the bundles and move them around to get to this:

Now you can see the four bundles that comprise the Blog sample and you can see a bit of information about how they are related to each other. Try clicking on the 'twisties' to expand information about packages and services.

This is really prototype code, we wrote it to get round the problem of using a mixture of the OSGi console and slides to explain how the blog sample works. GOAT works by having an OSGi bundle in the framework which spits out information to a web front end which we deal with in JavaScript - that's what allows you to move bundles around. Even though it's at the prototype stage at the moment I think it's worth mentioning in a post. I haven't found anything similar, Knopflerfish do have a graphical display but it's static - you can't grab things and move them around.

Running the Aries samples on Apache Geronimo

The Aries samples, which demonstrate the use of Enterprise OSGi components, also run on Apache Geronimo.

To run the samples, get the Geronimo V3-M1 release from here. Either the one based on Tomcat or Jetty will do.

Extract it and change directory to geronimo-jetty8-javaee6-3.0-M1 (or geronimo-tomcat7-javaee6-3.0-M1)

I found it useful to change the default http port from 8080 to something else (I have too many things that use 8080). To do this, edit the file ./var/config/config-substitutions.properties.


 Grab these pre-reqs (may not be needed in the next Geronimo release):

• tranql-connector-derby-embed-xa-1.6.rar
• aries-datasource.xml

 And the two versions of the Aries blog sample:

• org.apache.aries.samples.blog.jdbc.eba-0.2-incubating.eba
• org.apache.aries.samples.blog.jpa.eba-0.2-incubating.eba 

Start the Geronimo server,

./bin/geronimo run

to run in the foreground. In a different window, from the same directory, deploy the pre-reqs:

./bin/deploy -u system -p manager deploy tranql-connector-derby-embed-xa-1.6.rar aries-datasource.xml


Then deploy one or other version of the blog sample (but not both :-))

./bin/deploy -u system -p manager deploy org.apache.aries.samples.blog.jdbc.eba-0.2-incubating.eba

Navigate to http://localhost:XXXX/blog where XXXX is your HTTP port and check that the blog is running.

Navigate to http://localhost:XXXX/console and log in, uid 'system' , pwd 'manager'. Use the menu under Applications-> System Modules to start, stop, uninstall the blog sample.

More extensive documentation can be found here.

SVN Git shootout at the Apache Retreat

Apache Retreat, Hursley September 2010

Photo credit: Rainer Jung

Apache Aries JPA samples

There are two things that I almost always get caught by when developing samples for Apache Aries which use the JPA capabilities. The first is to do with datasources, the second is to do with enhancing persistence entities.

I get caught out because these two things would normally be provided by a JEE compliant container - something like the WebSphere App server - so,  as an application developer I would not normally have to think too much about them. However, all of the Aries samples need to be able to run in an OSGi platform built up using a set of readily available open source bundles so we need to find ways to do things that an app server would normally do for us.

Datasources

If you look at the source for the Apache Aries blog sample  you will find that the JPA persistence bundle depends on being able to use two other bundles. The relationships are like this:

On the left, shown in yellow, is the blog-jpa-persistence bundle. This is part of the blog sample application. Inside that bundle there are two important xml files, one with blueprint configuration, the other with persistence information. Configuration in these two files points to things supplied by the other two bundles.

The middle (green) and right hand side bundles (mauve) are both providing function that would normally be part of  an app server. The green one (transaction-wrappers) is available as part of Aries, it's a really simple implementation of function to enlist a data source. This is provided in Aries as a convenience for people writing samples. The 'datasource' bundle is something that needs to be  provided by the application developer but is not part of the application, there is no Java code to write - just a little blueprint which points to your database. For an example - look at the blueprint configuration in the blog sample data source. If you were using an app server you would normally configure data sources through an admin screen - providing the data source bundle is doing just the same thing.

When you assemble the OSGi platform that you will use to run your application you will need to make sure that both the transaction-wrappers bundle and your datasource bundle are running in the platform before you drop your OSGi application onto the load directory to be run. If you are in any doubt about how to assemble the kind of OSGi platforn you will need have a look at the blog-assembly project in Aries.

Enhancing persistence entities

The other part of JPA that I always get bitten by is the need to enhance  persistence entities. Enhancing means running a utility  that takes the byte code for persistence entities, processes it and spits out another, vastly more efficient and much larger, set of byte codes. This is again something that a fully compliant JEE container be expected to do for you - so you probably wouldn't be aware of it. There are various ways to enhance persistence  entities, in the Aries samples we use Maven, look at the pom.xml in samples/blog/blog-persistence-jpa/ to see how. Sadly, not everyone likes Maven as much as I do, so here is how to do it using Eclipse.

In this example I'm using the Eclipse JEE (Helios) development platform with the "IBM Rational Development Tools for OSGi Applications 0.6" installed. This is convenient because I can work on the code, build it and then export it as an OSGi application (.eba file). The .eba file can be dropped into the 'load' directory of my Aries platform to be run.

My Eclipse screen looks like this:

I'm using a sample Stocks application; the biz module has some persistence entities and the persistence xml is in it's default location in the META-INF directory.  To enhance the entities we need to run en external tool. Click on the external tools drop-down (the thing with a little red suitcase in the top bar) and then external tools configuration. From the next screen, select 'Program' and then 'new' (a white rectangle with a yellow cross in the corner). You should see something like this:

For 'Name', type in JPA_enhancer. Then, in the 'Location' field add the location of your Java executable. For me this is: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/java.

Now the fun begins. Under 'Arguments' you will need to add the command to run the JPA enhancer, for me this looks something like:

-cp MYJARS/commons-collections-3.2.1.jar:MYJARS/geronimo-jta_1.1_spec-1.1.1.jar:MYJARS/geronimo-jpa_2.0_spec-1.0.jar:MYJARS/openjpa-2.0.0.jar:MYJARS/commons-lang-2.5.jar:MYJARS/org.apache.servicemix.bundles.serp-1.13.1_2.jar:MYWKSP/org.apache.stocks.biz/bin:MYWKSP/org.apache.stocks.api/bin:MYWKSP/org.apache.stocks.biz/src org.apache.openjpa.enhance.PCEnhancer

where MYJARS is the path to a directory where I have copies of all the jars I need. MYWKSP is the path to the sample code.

It's easiest to think about this in three parts. First,  all the jars that the enhancer need on the classpath, these are:

• commons-collections-3.2.1.jar
• geronimo-jta_1.1_spec-1.1.1.jar
• geronimo-jpa_2.0_spec-1.1.jar
• openjpa-2.0.0.jar
• commons-lang-2.5.jar
• org.apache.servicemix.bundles.serp-1.13.1_2.jar

Then you'll need the class files and the source for your persistence entities and the class files for any API they depend on, thus:

• org.apache.stocks.biz/bin
• org.apache.stocks.api/bin
• org.apache.stocks.biz/src

Finally the name of the program that you are going to run :

• org.apache.openjpa.enhance.PCEnhancer

Adding that command (with your own paths of course) and saving the configuration should get you to the point where you can run your JPA_enhancer. The easiest way to check that it has worked (apart from there being no obvious errors) is to look at the size of the class files  - they should be much larger than the unenhanced versions.

Before exporting the OSGi application you will  need to modify the MANIFEST.MF of your persistence bundle to make sure that the import-package contains:

org.apache.openjpa.enhance;version="[2.0,3)",org.apache.openjpa.util;version="[2.0,3)"

Don't worry if Eclipse complains about this. Finally - just export the project as an OSGi Application (EBA) and run it by adding it to the load directory of your OSGi platform.

Colliding worlds: Development and Marketing

During my career in the software industry I've worked in both marketing departments and in development labs. Now, as a technical advocate, I'm part of the development organisation but I work with marketing.

As a software developer my first reaction to any kind of marketing information, no matter who it comes from,  is that it is likely to be junk.  I wouldn't feel this way if I felt the material was aimed at me and was telling me about tools or products that would help me. But all too often it isn't. And yet, whose fault is that? We, as developers, can't expect marketing to 'just know' about cool stuff we are working on.

Really, development and marketing should talk to each other. And now we do - a little bit :-)

To illustrate the issues for both sides, this is the story of trying to create a marketing message that both organisations were happy with.  We were trying to find an illustration to go with the phrase "Turning developers into superheroes", this was the starting proposal from my marketing colleagues:

What's wrong with that? Seriously, just about everything. This might work if the caption was "Turning salesmen into superheroes".  No developer I know would come to work dressed like that - well, the cape maybe, but the shirt and tie? Forget it.

Development's counter proposal for the image was this:

Somewhat predictably, my colleagues in marketing issued an immediate veto. Underwear on display is apparently unacceptable even if it's worn over the top of other clothes and other underwear is being worn underneath. Actually I don't know that other underwear was being worn underneath, I'm not on that kind of terms with the model. Although I can safely assert that he is, in fact, a real developer.

Impasse.

I spent the weekend 'gimping up' the aforementioned unmentionables and came up with this:

However, I never got to  show it to marketing because they produced this:

which I  like a lot. The use of a QR code was a great idea and the guy doesn't look like a salesman. The image is a bit more "Incredible Hulk" than "Superman" but it works fine.  I'm really happy with this outcome, I think that we've got a much better result by working across an organisational boundary than either of us could have achieved on our own.

Next challenge - depict the benefits of Enterprise OSGi  in the style Marvel comics :-) I will be SpiderWoman.

Install the WAS OSGi Feature pack

It's easy and free - these are minimal (Ubuntu based) instructions for starting with no WAS installation and getting to an installation of WAS with the OSGi feature pack. If the steps aren't clear look at the rather more verbose instructions in an earlier post in this blog :-).

• Install WebSphere 
•  Download from here
• Unzip this was.cd.7000.wasdev.nocharge.linux.ia32.tar.gz 
•  sudo ./launchpad and follow the fairly obvious screens. Uncheck the box that asks if you want additional security.
• Download Fix pack 7.0.0.9 
• Download from here
• The file will be called something like: 7.0.0-WS-WAS-LinuxX32-FP0000009.pak
• Download the SDK upgrade pack
• Download from here
• File will be called something like: 7.0.0-WS-WASSDK-LinuxX32-FP0000009.pak
• Install the update installer
• Download from here.
• Extract 7.0.0.9-WS-UPDI-LinuxIA32.tar.gz
• cd to the top level directory of the installation
• sudo ./install to make it install itself
• After installing it will launch itself and you can go on to install the two 7.0.0.9 packs that you downloaded above.
• Get the OSGi Feature pack from here.
• Download Installation Manager, 1.3.4.1-WS-IM-LinuxX86.zip. (86MB)
• Unzip it
• cd to the top level installation directory
• sudo ./install to make IM install itself. IM will lead you through the next three steps
• Import your WAS installation.
• Install the OSGi Feature pack.
• Launch the profile management tool and augment your profile
• Check your installation
• cd /opt/IBM/WebSphere/AppServer/bin
• sudo ./startServer.sh server1
• navigate to http://localhost:9060/ibm/console/ and check that you can see the WAS console.
• sudo ./stopServer.sh server1

At this stage I would normally install the database for the blog sample and run the set up script for it.

•  cd /opt/IBM/WebSphere/AppServer/feature_packs/aries/samples/blog
• sudo /opt/IBM/WebSphere/AppServer/derby/bin/embedded/ij.sh createBlogDb.sql
• sudo /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/wsadmin.sh -f blogSampleInstall.py setupOnly server1 ubuntuNode01

Talking about Apache Aries

The number of OSGi related talks seems to be increasing - which can only be a good thing. I'm going to this one tonight and looking forward to it!

I thought I'd look at who was talking about Apache Aries and where for the next month, I'm sure this isn't a comprehensive list so let me know if I've missed anything.

June 2nd - Tim Ward will be talking about JPA and OSGi at Jazoon in Zurich

June 8th - Holly Cummins will be at the Paris JUG giving an Apache Aries presentation.

June 19th (*)  - Zoë Slattery will be at the SAP Inside Track talking about Enterprise OSGi in Apache Aries

June 26th(*)  - Mark Nuttall will be giving an Apache Aries presentation at the London Java Community Unconference.

July 1st - Andrew Osbourne will run a Blueprint tutorial at the OSGi Users' forum based on the implementation of Blueprint in Apache Aries


* These are both unconference style events so although presentations have been offered there is of course no guarantee that they will be delivered. However both events look pretty well worth attending whether there is Aries there or not :-)

Women's appointments

A couple of weeks ago I was helping my mother move some furniture and found a newspaper from Saturday December 23rd 1967 which had been used as drawer lining. I skimmed through it and eventually found the "Women's Appointments" section.






Of course you would never see anything like this in the UK now, not since the sex discrimination act in 1975. The weird thing is that I would not have seen anything odd about this section in a newspaper in 1967. In fact, I applied for a job in 1973 as a lab technician for a chemical company and was not even mildly annoyed when they wrote back and said the job was only available to men. It makes me wonder how much I accept now without thinking too much about it.

Thirty five years after the act there are clearly still things wrong in the UK. For example, why do so few girls go into computer science? For any teenage girl with a flair for maths it should be such an obvious career choice. My daughter obtained her degree in computer science last year and is very happily working for Assanka in London. However, I suspect that she might never have followed that route if I hadn't worked for IBM. It's also probably true that I wouldn't have pursued a career in science if my mother had not been a doctor. How long will it take to push through enough role models to even things out? Generations?

It's not all bad though, my son is a dancer and currently touring with Matthew Bourne's Swan Lake. I cannot imagine what would have happened in the the 1960s if a child of intellectual middle class parents had insisted that all he wanted to do was dance.

Reflections on Open Source Jumpstart #GDCOSJ1

When you work on an Open Source project most of your communication with colleagues will be through the mailing list or maybe on IRC. This works great 90% of the time but I think everyone understands that occasionally it's really helpful to meet and talk to the people you work with. Traditionally this has happened at conferences, for example ApacheCon, EclipseCon and so on.

That's fine for people that are established committers - but what about people who want to start? Those mailing lists are pretty intimidating aren't they? Then when you do screw up the courage to write a note sometimes it never gets answered and you don't know why not. Or sometimes people don't read your question properly and answer something else. It can seem very unwelcoming. Initiatives like GSOC do a good job but they also miss the face to face element.

It was just because of this that we decided to run Open Source Jumpstart. We wanted students to meet committers face to face, just once. It's amazing how many of those getting started barriers can be broken down with one day's work. It would be great if any of the students from Saturday carried on working on Open Source projects - however, even if they don't, in that one day's work bugs were fixed in every project and students learnt about how code is developed.

There isn't much that's more satisfying than bringing two groups of people together and seeing both of them get something out of the experience. Have a look at the Meetup to see feedback from the event.

Open Source Jumpstart #GDCOSJ1

Yesterday's GDC Open Source Jumpstart was amazing!

Thanks to all the open source projects that came:

1. Apache Aries
2. Apache Harmony
3. Apache Tomcat
4. Apache Tuscany
5. Apache Wookie
6. Citrine
7. Ikasan
8. Impala
9. PHP

You guys worked so hard all day!

Thanks to all the students that came along and fixed bugs, wrote tests and documentation. Well done! I can't believe how far people came (from Edinburgh in one case) - you represent the future of software development and it was great to meet you.

Thanks to IBM for letting us use their wonderful Southbank location and to the IBM Innovation Centre in Hursley for providing the food. The Innovation Centre have some great (free) resources for students, if any of you missed the links, here they are again:

1. Mydeveloperworks - all sorts of resources for creating groups, wikis etc
2. Student portal - competitions, stuff about jobs etc
   

Finally - thanks to Barry Cranford for being a continual positive inspiration and to the rest of the GDC organising committee for pulling yesterday's event together.

Yes, I really think we might do this again!

Apache programmers study Leech Farming in Ireland

For the last three days I've been in a Youth Hostel in rural Ireland with a bunch of programmers. Sounds like hell? Actually quite the reverse. It was probably the best 'unconference style' event that I've been to. So many things made it work - here are a few:

• Beautiful countryside (most of us did a couple of hours walk on Saturday)
• Everyone staying overnight for two days - no splitting up to go out to different pubs/restaurants etc
• The weather - yes, it was sunny - in Ireland - in April - for three consecutive days.
• Great mixture of projects, people, talks and coding time.
• The only use of PowerPoint was in 'Presentation Karaoke' - a right and fitting use for PowerPoint. This is where the Leech Farming came in.
  

Thanks go to Noirin Shirley for the organisation, not only for doing the normal hassle stuff (booking the hostel, organising the food) but also for roping in her husband to collect us from Bray station and persuading her parents to turn up with home baked bread on the last day.

Here is a shot of Andrus Adamchick at breakfast on the last day - just to give an idea of what the place was like.



These events are somehow much more satisfying than the huge, expensive conferences. I come away feeling that I've learned something and met some great people. I'm looking forward to the next one already.

Persistence layers in the Apache Aries Blog Sample

When we first added the Blog Sample to Apache Aries there was no support in Aries for JPA, so the sample was written with a JDBC persistence layer. Over the past month or so JPA support has been added to Aries, as a result I spent some time last week getting a new JPA version of the blog persistence layer to work on Aries components.

The samples in Aries are deigned so that they run on an OSGi platform which pulls in just enough components to run the application, for the blog sample we use Equinox as a base and build up from there.

Here are a couple of small statistics comparing the JPA and JDBC persistence implementations in the Aries blog sample:

The Java code is much more concise using JPA, the complexity has all moved into the platform. Which is, of course, the right way to go.

WebSphere from the ground up - part two

A week or so ago I posted on how to do an 'assume nothing' installation of WebSphere in order to run the OSGi Alpha Feature pack. Today the Open Beta of the OSGi Feature Pack was released and the requirements and installation process differ slightly from those required by the Alpha.

The basic steps are pretty much the same, differences are shown in this color:

1. Install the free-for-developers WebSphere Application Server Version 7
2. Install the 7.0.0.7 Fix pack and an update to the Java SDK for WAS
   
3. Install the Open Beta OSGi Feature pack using the IBM Installation Manager.

Following the instructions for the Alpha works up to half way through step 2. But here, as well as downloading the 7.0.0.7 Fix pack you will need to download an SDK update from here. The file will be called something like 7.0.0-WS-WASSDK-LinuxX32-FP0000007.pak. Put this file in the same directory as you put the 7.0.0.7 Fix pack, then run the UpdateInstaller as directed in the previous post to install both fixes.

To install the Open Beta you will need to start with this link . Scroll down till you find these two links:


The first link (Web install...) is the one you want. You will download a preconfigured version on the installation manager which already has links to the repositories containing the Beta download.

Click on the Web install link and follow through the next screens till you find an option to download the IBM installation manager. It is about 86MB and will be called something like iim.linux.x86_20100128.zip. Download it and unzip it in a temporary directory, then run the install script in that directory.

The installation manager will start up and ask if you want to install Version 1.3.4 of the installation manager. Continue with the installation of V1.3.4 through to the end when you will be asked if you want to restart, accept this option. When the installation manager restarts you will be prompted for an ID and password, these will be the same ones as you would have used to download WAS in the first place.

The next two steps are to 'Import' your existing WAS installation into the installation manager. After that you will be able 'Install' the Beta code from a remote repository which has already been configured in the Installation Manager.

At the end if the Beta installation the profile management tool will be launched, you will need to augment your profile with the OSGi feature pack. Again, the screens are easy to follow.

This is a fairly high level view of the instructions, there are excellent and very detailed steps available from here in the getting started guide.

WebSphere Application Server - from the bottom up.

Recently I installed the IBM WebSphere Application Server from scratch so that I could look at the OSGi support for enterprise applications available in WebSphere. Google was not my friend in this instance - I couldn't find a quick summary of the instructions for installing the WebSphere Application Server anywhere. It is actually all quite easy, not to mention free. In this post I'll provide a brief overview of the steps and links to download sites. If you want more detail, look here for information on every supported operating system. I used an unsupported operating system (Ubuntu**) and for the purposes of experimenting with the OSGi support this works just fine. Although I use Linux commands throughout this, the same thing will work on Windows with the appropriate modifications to paths and exchanging .bat for .sh files.

There are three steps:

1. Install the WebSphere Application Server Version 7
2. Install the version 7.0.0.7 Fix Pack
   
3. Install the Alpha OSGi Feature Pack
   

1. Install the WebSphere Application Server Version 7

This is free for development use and all you have to give IBM is your name and an email address, which they will not use unless you check the boxes saying that you want to be contacted. You will also have to read and accept some license terms. The link you need is here, there are Windows and Linux downloads, no Mac version (sorry). You will need version 7, and the download is 800 MB so you need to allow plenty of time and make sure you have enough disk space.

Installing is straightforward. Extract the file you downloaded (it will be called something like was.cd.7000.wasdev.nocharge.linux.ia32.tar.gz). In the top level directory you will find a 'launchpad' file. Launch the installer like this:

sudo ./launchpad.sh

The screens are fairly self explanatory, just make a note of where you install the AppServer (default on my system is /opt/IBM/WebSphere/AppServer) and, if all you want is an experimental installation, I suggest not configuring security. I'll refer to the place that you installed the AppServer as WAS_HOME for the rest of this post.

Skip the final screen asking if you want to launch the AppServer, it's better to get used to the command line. Change directory to WAS_HOME/bin, then run

sudo ./startServer server1

this will start up the server. To shut it down again,

sudo ./stopServer.sh server1

2. Installing the 7.0.0.7 Fix Pack.

This is a two step process. You will need to download both the fix pack and an installer. The steps are detailed here. If this is a new installation all you need are steps 5 and 6.

The installer that you download will be called something like 7.0.0.7-WS-UPDI-LinuxIA32.tar.gz and the fix pack will be 7.0.0-WS-WAS-LinuxX32-FP0000007.pak. Extract the installer somewhere temporary, then

cd UpdateInstaller
sudo ./install

The screens which follow will take you through installing the installer and then onto installing the fix pack. The screens are easy to follow - you will just need to point the installer to the location of the fix pack at some point.

After installing, try stopping and starting WebSphere again to make sure everything has gone according to plan.

3. Installing the Alpha OSGi feature pack

You will need to download the feature pack from this site. Select the 'Download' tab then scroll down till you find 'Download OSGi Applications Alpha'. You will have to register and accept another license, then you should find a screen that allows you to download 'OSGi-Applications-Open-Alpha-20100111.zip'. Copy the .zip file into the WAS_HOME directory and then extract it. To complete the installation you will need to run:

cd WAS_HOME/feature_packs/aries/bin/
sudo ./complete_installation.sh
sudo ./augmentProfile.sh AppSrv01

This assumes that 'AppSrv01' is the name of the profile you want to use; if this is stand alone test installation using AppSrv01 will be fine.

Finally - restart the AppServer, and point your web browser at http://localhost:9060/ibm/console, which will give you the WebSphere admin console, like this:



If you didn't set up security you will just be able to click the 'Login' button, if you did you will have to enter an ID and password.

You should now be in a position to experiment with the OSGi Alpha as described here

Finally...

This is all quite easy to work through but there are some additional things that it's helpful to know:

You will find the log files here:

WAS_HOME/profiles/AppSrv01/logs/server1

the one you are most likely to want if things don't go according to plan is SystemOut.log.

OSGi bundles are cached here:

WAS_HOME/profiles/AppSrv01/config/bundlecache

It can be useful to look and see what is in there.

The OSGi samples (and their source code) can all be found here:

WAS_HOME/feature_packs/aries/

** If you do use Ubuntu to run WebSphere you will need to make sure that /bin/sh is linked to /bin/bash, not /bin/dash.