Man, have I been busy the last few weeks. So much to do, so much to learn, so much to try. Within two days it is time for our presentation at the dutch NLJug. I have been setting up the osgisamples website. Upgraded the family website. For my current employer we are finishing a webservices project at a big client. After about 1 1/2 year it is time to go to a new client. The time to relax is starting to come back. I want to use more time to start reading books. Ofcourse no thrillers :-), but interesting books. So from now on you will see some book reviews on the website again. I hope you will get enthousiastic about the books. If you decide to buy the books, you can support me by clicking on the link on this website. This also gives me an indication if people like what I write about the books.

This time I want to write something about the following book:


This is not a programming book, no you won't find java in here, no webservices, but a lot of technology. The book is about innovations. How can you be innovative. Is it something you can learn? Was the gravity moment of Newton an epiphany, or is that not possible. Does the eureka moment exist when your innovative, or do you need a lot of time to prepare that euraka moment. The book uses a nice historical introduction and a lot of links to resources on the web to read more. Sometimes it is just fun to follow the links and continue reading there. The biggest problem is that you need some sleep. You can really get lost in all that interesting reading on the web. Just for the fun two examples of interesting links.
http://www.ideafinder.com/ - look for good initiatives and learn from the past
http://www.goodyear.com/corporate/history/history_overview.html - nice story about how something simple can influence the world.

Today I agreed with Allard buijze (Some of you allready know him due to our osgisamples initiative) that he will also write down his knowledge in this blog. So welcome Allard and I hope we will find a lot of interesting posts from you in this blog.

greetz Jettro

We did it, Allard and I have been choosen to give a presentation at the NLJUG JSpring the 13th of June 2007. We are going to give a presentation about Webservice versioning using osgi.

A lot of companies are using or starting to use webservices and/or a Service Oriented Architecture. For each of these companies there comes a time to think about backwards compatibility and versioning. The solution is not always obvious. There are multiple options, we will discuss some of them and explain the concerns we have with them at our current projects. Our presentation deals mostly with a solution based on apache axis and the eclipse equinox implementation of the OSGi framework. The presentation uses a case of a congress registration system for demonstrating the problem of a plain webservice project. We will present our osgi based solution to the versioning problem. In a demo, we show that we can solve the versioning problem within one deployment with one ear/war file. Even better, we can do it at runtime, so no need to redeploy, no downtime. We can do an upgrade and roll it back without one second downtime. At the end of the presentation you will have basic understanding of osgi concepts. You will have the ambition to try it out yourself, that is when you take out your notes, go to our website and download all our material. This is when the real fun part starts.

Hai All,
just a short non technical message. It is quiet around this blog. Not that nothing is happening, but it is temporarily happening somewhere else. Together with a colleague of mine I am working on knowledge and samples around OSGi. We are creating a nice sample that proves we can create web service versioning within one application. So we deploy (at runtime) multiple versions of the same component (or bundle) in a way we can set multiple versions of the same web service live. Sounds interesting? Go to our website http://www.osgisamples.com.

see you next time

A few months a go I was reading the website of the springframework. One article subject supprised me. I had never heard of it, OSGi. Curious enough to want to know what it was about I opened the article and started reading. The more I read the more I was certain, this is going to be the next big thing. Then in December I attended The SpringExperience in Miami and of course there was one presentation I had to attend. It turned out I was not the only one interested in spring-OSGi. Adrian Colyer gave a very interesting presentation and almost the complete interface21 team was there. They all think OSGi is going to be the next big thing. If you do a google on spring osgi you will get a lot of hits. Of course none of these is as technical as mine

If you want to read more about the event look at this blog.

Now a few weeks later I had finally found some time to experiment, and of course I want to share what I have learned. This blog item is a step by step approach of creating your own spring-osgi bundle. Later I will add some more complicated bundles with references, listeners and maybe a webserver.

So, how do we start? Well first download all code and install it using maven. Hmm, maybe I should tell you first that you need to install maven 2 and subversion. So, please install subversion and maven2. Then checkout all sources:

svn checkout https://svn.sourceforge.net/svnroot/springframework/spring-osgi/trunk spring-osgi

Than step into the root folder and do a mvn install. You can ofcourse have a look at the samples that come with spring-osgi. Please go to the spring-osgi website and see the tutorials there. We arfe going to create a new bundle using the maven archetype.

If you want to have a look at the complete source code, do a checkout from the following google code website or browse it online

svn checkout http://gridshore.googlecode.com/svn/trunk/SpringOsgiSample gridshore

Using the archetype

mvn archetype:create \

  -DarchetypeGroupId=org.springframework.osgi \

  -DarchetypeArtifactId=spring-osgi-bundle-archetype \

  -DarchetypeVersion=1.0-SNAPSHOT \

  -DgroupId=nl.gridshore.samples.springosgi \

  -DartifactId=bookreview-service \

  -Dversion=1.0-SNAPSHOT \

  -DremoteRepositories=http://static.springframework.org/maven2-snapshots

Have a look at the generated pom.xml file and check mine. There are some things I altered that are important.
- I added the scope - test to the dependencies that did not have it
- I added the following dependencies : jcl104-over-slf4j.osgi, slf4j-log4j-full and log4j.osgi
- removed the dependecy for commons-logging
Check the pom.xml file of the provided samples by spring-osgi, that is where I got it from.

The archetype also provides a .project and .classpath file for eclipse. I had problems when I did a mvn eclipse:clean eclipse:eclipse. Some lines are not added that were in place when the files were provided by the archetype.

    <buildCommand>

      <name>org.eclipse.pde.ManifestBuilder</name>

    </buildCommand>

    <buildCommand>

      <name>org.eclipse.pde.SchemaBuilder</name>

    </buildCommand>

    <nature>org.eclipse.pde.PluginNature</nature>

Not sure whether these are absolutely necessary. I do know a bundle within eclipse is a plugin, therefore you need the plugin nature.

Start coding
The framework of the project is in place and should compile (mvn install). Now it is time to start creating the bundle. We'll start by creating the BookReviewService, the unit test and the implementation of this service. This is pure java code, check the sources if you like. Now add a bean that we can expose as a service to the spring context file. There are two context files out of the box. You can find them in the src/main/resources/META-INF/spring folder.
bundle-context.xml : contains the normal spring configuration
bundle-context-osgi.xml : contains all beans that use the osgi namespace

We have created the spring bean myBookReviewService:

<bean name="myBookReviewService" 

    class="nl.gridshore.samples.springosgi.impl.BookReviewServiceImpl" />

Then we expose this bean as a special osgi service

<osgi:service id="bookReviewServiceOSGi" ref="myBookReviewService"

    interface="nl.gridshore.samples.springosgi.BookReviewService" />

And now we are done, no not really. First we need to create an integration test. We use the special super class AbstractDependencyInjectionSpringContextTests. This test uses the spring config file to configure and start an application context. From the context we obtain our bean and test it to see if it works.
Alter the manifest file
Next step is to alter the manifest file, you can find this file in the META-INF folder at the same level of the src folder. You need to add an export package and the Bundle-classpath

Bundle-Version: 1.0

Bundle-SymbolicName: nl.gridshore.samples.springosgi.bookreviewservice

Bundle-Name: nl.gridshore.samples.springosgi.bookreview-service

Export-Package: nl.gridshore.samples.springosgi

Bundle-ClassPath: .,

 target/classes/

Now we are ready to package our bundle. By using one of the tutorials from the spring-osgi website you can use eclipse/equinox to install and start this bundle. There is however not much to see. Wouldn't it be nice to be able to test within an exsiting osgi container whether your hard labor was wurth it? You can, the next steps will describe how you can create an in container test.

Creating the in container test
Again the framework provides a number of super classes that makes life a lot easier. I am not going to explain in detail what these classes are doing. Still I think one thing is important to know. Your test projects is being transformed into a bundle at runtime with a reference to the bundle under test. But lets start with the creation of the normal jar file that will contain our test.

mvn archetype:create \

  -DgroupId=nl.gridshore.samples.springosgi \

  -DartifactId=bookreview-service-integration-test \

  -Dversion=1.0-SNAPSHOT \

Alter the pom, it should use the parent and have a lot of dependencies. There are two I would like to mention is special:
bookreview-service : this is our own project that we are gonna test
org.springframework.osgi.test : utilit classes for our own test class

The manifest file for the bundle that is created on the fly comes from the test/resources directory and looks like this.

Manifest-Version: 1.0

Bundle-Name: simple-service-integration-tests

Bundle-SymbolicName: nl.gridshore.samples.springosgi.test

Bundle-Activator: org.springframework.osgi.test.JUnitTestActivator

Import-Package: junit.framework,

 org.osgi.framework;specification-version="1.3.0",

 org.springframework.core.io;specification-version="2.1.0",

 org.springframework.osgi.test,

 org.springframework.osgi.test.runner,

 nl.gridshore.samples.springosgi

Now we can create the test, use the ConfigurableBundleCreatorTests as a super class and implement the method to locate your MANIFEST.MF file. You also must implement a method that defines all the dependencies that can be obtained from your local maven repository. Finally you need to add your test methods.

public void testOSGiStartedOk() {

   BundleContext bundleContext = getBundleContext();

   assertNotNull(bundleContext);

}

This test checks if the context for the created bundle can be obtained.

public void testSimpleServiceExported() {

  waitOnContextCreation("nl.gridshore.samples.springosgi.bookreviewservice");

  BundleContext context = getBundleContext();

  ServiceReference ref = context.getServiceReference(BookReviewService.class.getName());

  assertNotNull("Service Reference is null", ref);

  try {

    BookReviewService bookReviewService = (BookReviewService) context.getService(ref);

    assertNotNull("Cannot find the service", bookReviewService);

    List bookreviews = bookReviewService.findBookReviewByKeyword("habits"); 

    assertEquals(1, bookreviews.size());

  } finally {

    context.ungetService(ref);

  }

}

This test first checks if the osgi service can be obtained from the bundle context. Then the obtained service is used and the result is checked. In my case we are looking for a book and if all is well we should be able to find exactly one.

Now do a mvn install on the highest level and you should have a tested spring osgi module

Conclusion
That is about it, I hope this will help some of you, do not hesitate to ask questions if something is not clear. You can find a lot of information on the spring osgi website, there is a google group and google lists about thousands of hits.

Currently I am working with vmware. I want to be flexible in reconfiguring my server without constantly having to re-install. Next to that I like it that I can configure my complete server and then move it to the production server. I am also looking into virtualization for the production server. Some of my collegues are also looking at it, and it looks very promising.

Ofcourse when using a new technique, you will be facing some problems. Within this blog I will explain my idea and the solution that I created.

Demand
I want an environment where I am able to install new servers on demand. I want to be able to have a continuous intergation server, a test server, a quality assureance server and of course a production server. If I go to my management and tell them I need 4 servers to start with they will not like it. It is better to ask for one big server and use vmware. Next to that I am very flexible in moving around servers. I can configure the server locally and put it on the host server if I am done. In the end there will be almost no downtime for testers etc.
Oke, that point should be clear now. There is another thing. I do not want to expose all virtual servers to the clients. This could lead to a lot of firewall rules, ip addresses to remember or dns entries. I want to be flexible. That is why I want a proxy in front of the virtual machines. This proxy is installed on the host machine and redirects to virtual machines.

Solution
The following image shows the complete picture in a deployment diagram

This diagram shows the host server that is running windows 2003 server edition. This server can be reached using a vpn and remote terminal client. Within this server we have vmware running with two images. One image for continuous integration and the maven reports, the second image contains apache tomcat with our deployed application.

First we install the linux virtual machines. I took a pre configured ubuntu installation:
http://www.thoughtpolice.co.uk/vmware/
After that I needed to install java, tomcat,continuum,apache2, ssh. It surprised my how easy this is nowadays. As an example, the next command downloads and configures ssh on the server.

$ sudo apt-get install ssh

It cannot get more easy than this. Simular steps were necessary for the other components. One other I want to mention is downloading the continuum jar. This is done with a command called wget.

$ wget http://www.apache.org/dyn/closer.cgi/maven/binaries/continuum-1.0.3-bin.tar.gz

Again, very easy. If you want to have more information, these websites helped me figuring out the right commands:
http://www.kintespace.com/rasxlog/?p=468
http://www.spaceprogram.com/knowledge/2006/05/installing-java-5-jdk-and-tomcat-on.html

Now you want to install and configure the apache 2 http server. Installation is not that difficult on most systems. You need to include the proxy module for apache. This can be done with the command

$ sudo a2enmod proxy

The final part is configuring the proxy, therefore you must add the following lines of code to the file /etc/apache2/mods-enabled/proxy.conf

ProxyPass /ci http://192.168.93.130/continuum

ProxyPassReverse /ci http://192.168.93.130/continuum



ProxyPass /naboo http://192.168.93.130/naboo

ProxyPassReverse /naboo http://192.168.93.130/naboo



ProxyPass /test http://192.168.93.130:8080/scheduling

ProxyPassReverse /test http://192.168.93.130:8080/scheduling

It is not the best step-by-step approach I have created, still I thing this will do. If you are have questions, use the comments. If you want more information about the mod_proxy module have a look at this website:
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

For a project I did a while ago we were thinking about using a branch for each developer while working on large changes/additions. Why, you ask? Well I'll try to explain, believe me I know there are alternatives but think about it before you judge.

Scenario
We want to deliver version 3.0 of our application but we also want to continue creating some new usecases. Since we use test driven development, we create a test, implement functionality and run the test. After this we want to check in the stuff and let the integration test run by our continuous build. One possible obvious solution could be to use a branche for the 3.0 release and continuo working on the head.
This all sounds clear, we use subversion as an scm (Source Control Management) system. I do have one problem though. The repository is on a server of a friend of mine, I need to use an scm which I cannot use everywhere due to firewall settings. Therefore I cannot checkin code, which makes I cannot separate the different features I implement.
Last week I listened to the javaposse podcast. There was an item about distributed scm. I got interested and desided to investigate further. I had a look at Mercurial and I am still curious. I copied the following piece of text from their wiki:
A distributed SCM tool is designed to support a model in which each Repository is loosely coupled to many others. Each Repository contains a complete set of metadata describing one or more projects. These repositories may be located almost anywhere. Individual developers only need access to their own repositories, not to a central one, in order to Commit changes.
Distributed SCMs provide mechanisms for propagating changes between repositories.
I installed the stuff (very easy, good manual, only 2.5 Mb or so download). There is a nice tutorial giving you the basics of using mercurial.

Next steps
I am not convinced I need a distributed scm. I like the idea of having a local repository. I think this can help you when working in a gridshore project. I want to have a better look at a good workflow for such a system. How are you going to configure your continuous integration? The first thing I did was looking for a mercurial maven scm plugin. There is a very current thread in jira about maven and mercurial. I want to start an experiment with this, so if you are reading this and you have experience or good articles please post a comment or send an email.

I was thinking a long time about doing this. Writing an opinion about runtime agains checked exceptions. I decided to do it, just to form my own opinion and start doing it consistent. Please do not start the debate here, it is just my opinion. I will point you to a number of resources that can help you form you own opinion.

The reason to introduce Checked Exceptions in java is to assure that people do something with exceptions. This is made sure by the compiler. However there are a lot of side effects to this theory. Bruce Eckel has a very good entry on his blog, I quote one of his sentences that sais it all:
When someone is trying to do something and you are constantly praddin them with annoyances, they will use the quickest device available to make those annoyances go away.
One of the anti patterns is born: catch (Exception e), swallowed exceptions.

A disadvantage of Checked Exceptions is all the code you must write or rethrowing exceptions. This way you throw exceptions in layers that do not belong there or you catch exceptions and throw a new other exception. And a new anti-pattern is born. Runtime exceptions just go up untill the main thread, or you can catch them if you can can do something about it. The important part, if you do nothing you will get an exception at the top, you are not tempted to do the catch Exception part.

The blog item of Tim McCune is also a very good article about exception handling. This article states a number of anti-patterns that you will find in your code. You do not have to agree on all the items, but you can learn a lot of them. Some rules of this website that I agree upon are:

• Either log an exception or rethrow it.
• Never throw java.lang.Exception
• Never add multiple exceptions to throws that propably are handed the same, use a super class instead
• Never throw an exception from a finally block

I also have some ideas of myself, I adhere to the following rules:

• Add important runtime exceptions to the throws clause of your method. Instead of this you can also document them in your javadoc. It is important to let the users of your class/interface know what kind of exceptions they can expect
• Use a good logging framework, agree upon the levels to use and make sure to log the exception if you catch one.
• From java 1.4 there are nested exceptions, use these if you want to wrap a checked exception in a runtime exception. You can also use a special wrapper. There is one in apache commons-lang. The utility class to use from this package is:http://jakarta.apache.org/commons/lang/api-release/org/apache/commons/lang/exception/ExceptionUtils.html

Of course this is not a very extensive post, but it does give an idea about how I feel about checked exceptions.

I have created a lot of small applications that include spring and acegi. Most of the time I copy most of the resources from another project. Some time ago I learned about the maven archetypes. An easy way to create the project structure. That was the time I decided that I wanted to have my acegi springframework archetype. Last weeks I found some time to create this archetype. You can download the files here:
http://code.google.com/p/gridshore/
And the generated maven site here:
http://www.gridshore.nl/projects/springframeworkarchetype/index.html
Ofcourse there is also a maven website about creating an archetype, this is not a very extensive website. In this blog item I will explain more about the archetype I created.

First thing to know, well surprise, the archetype is just a maven project. You can start you new archetype by using a maven archetype:
mvn archetype:create
-DgroupId=nl.gridshore.samples.archetype
-DartifactId=SpringframeworkArchetype
-DarchetypeArtifactId=maven-archetype-quickstart
Have a look at the pom for the other properties; scm, distributionManagement, etc.

The project itself contains an src\main\resources\META-INF\maven\archetype.xml file that defines all the resources that need to be copied.

<archetype>

  <id>SpringframeworkArchetype</id>

  <sources>

    <source>src/main/java/App.java</source>

  </sources>

  <testSources>

    <source>src/test/java/AppTest.java</source>

  </testSources>

  <resources>

      <resource>src/main/webapp/index.jsp</resource>

      <resource>src/main/webapp/WEB-INF/web.xml</resource>

      <resource>src/main/webapp/WEB-INF/action-servlet.xml</resource>

      <resource>src/main/webapp/WEB-INF/jsps/welcome.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/adminwelcome.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/accessdenied.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/login.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/loginerror.jsp</resource>

      <resource>src/main/resources/security-springConfig.xml</resource>

      <resource>src/main/resources/views.properties</resource>

      <resource>src/main/resources/errormessages.properties</resource>

      <resource>src/main/resources/sitetext.properties</resource>

      <resource>src/main/resources/log4j.dtd</resource>

      <resource>src/main/resources/log4j.xml</resource>

  </resources>

</archetype>

The structure is pretty easy, you can find all the resources under the directory:
src\main\resources\archetype-resources

You can use the following parameters in your file as placeholders:
http://maven.apache.org/plugins/maven-archetype-plugin/create-mojo.html. Have a look at the src\main\resources\archetype-resources\pom.xml for an example:

  <groupId>$groupId</groupId>

  <artifactId>$artifactId</artifactId>

  <version>$version</version>

Hope that helps you on your way to your own archetype. If you just want to use mine:

mvn install

mvn archetype:create

	-DgroupId=your.groupid

	-DartifactId=your.artifactId

	-DarchetypeArtifactId=SpringframeworkArchetype

	-DarchetypeGroupId=nl.gridshore.samples.archetype

	-DarchetypeVersion=1.0.0-SNAPSHOT

Yesterday I attended the Profict Java Summer Camp. And what a camp it was. The first surprise was the location, what a nice environment to do your work. In introduction of profict, "we are hiring". Then the real camp started. 4 hours head on with Greg Murray. Greg is working for more then 10 years with java, mostly for sun. The last years he has been busy with AJAX. He gave a very enthousiastic talk about a ajax and some frameworks. Just to give you some pointers:
Dojo framework, jMaki frameowork, ajax blueprints, netbeans.
He showed a lot of examples, a few I liked very much.
http://www.javaserver.org/jmaki/
https://blueprints.dev.java.net/ajax.html
http://www.isoma.net/games/goggles.html (Oops not ajax)
In Brief, a very nice presentation with a lot of information. It could have been a little bit shorter. Some nice pointers to start new research into java

The next presentation was by Bram Smeets of interface21. We allready know him, read one of the other posts about dwr on my blog. He gave a very good introduction to the powers of dwr and what it can do if you combine it with spring. I guess I allready knew, still, it was interesting to see and hear Bram talk about it and put some stuff into perspective. I am curious about the next step of dwr and the use of spring 2 stuff within DWR.

After the presentations there was a nice barbeque, had some good conversations with Greg, Bram and others. It was a very nice camp, thank you profict.