Bndtools and OSGi 4.3 Capabilities Support

Since the version 4.3 of the OSGi specification there is a general model to define any kind of dependencies, the required and provided capability model. An OSGi bundle now can define a provide capability, to define that the bundle provide some feature, e.g. the bundle provide an OSGi service, extender or a whiteboard. To define such a capability a new bundle header in the manifest was defined, the Provide-Capability header. If a bundle depends on a capability, the bundle can define, via the Require-Capability header, the dependency.  Here an bndtools example for the configuration for a provider and consumer bundle, the provider bundle provides an whiteboard:
That’s a lot of code in the configuration, for this reason bnd/bndtools provides some nice annotation @ProvideCapability and @RequireCapability to define a capability. Now we can define the dependency in the Java Code via an annotation here an example for the consumer:
If you like to use the @RequireCapability in many bundles and you like not to repeat your self, in bndtools you can make your own annotation for that case. Here a example how such a own annotation can be defined:
Why should I use the capability model? In bndtools you can use the capabilities to resolve a list of bundles, which are needed at runtime. For example to run an JAX-RS OSGi application, the following few lines of a bnd run configuration is required: Bndtools can now automatically resolve the list of run bundles to: The latest bndtools version, which can be installed from the jenkins update site, provides a nice feature (its hot and not stable at moment) to add capability information to existing’s bundles in a file repository. Here my bndtools repository setup to add some capabilities to the jaxrs bundle and to the felix http jetty bundle. I really like the bnd annotation to define capabilities. I hope the augments feature, to add capabilities to existing bundles, for the file repository will be soon stable and released. The resolver and the capabilities features in bndtools I think provides new ways for OSGi based frameworks to handle run configurations.

More details about the bnd/bndtools Manifest Annotations read the bnd documentation:
http://bnd.bndtools.org/chapters/230-manifest-annotations.html

Slides - OSGi and Spring Data for simple (Web) Application Development

Here the slides from my EclipseCon Europe / OSGi Community Event 2014 talk about "OSGi and Spring Data for simple (Web) Application Development".

OSGi and Spring Data for simple (Web) Application Development

Links

• Session Details here
• Coding Simple Blog Demo - https://github.com/tux2323/simple.web.blog

Spock Old Feature

Yesterday I watched the Idiomatic Spock presentation with Rob Fletcher on YouTube, a great talk about testing with Spock. A small feature I didn't know that this exits in Spock is the old method. With this static method from the Spock framework you can get a value from the test subject before the actions in the "when:" block are executed. This is done in Spock by some byte code magic (AST transformation), in the debugger you will see that the statement in the old method is executed before the statements above. This feature helps to get a clean and stable test logic and it can be use for example to verify that a size of a collection is increased, here a simple Spock specification which verify that the stack size is increased by using the Spock old Feature.

More Spock magic, patterns and anti patterns can be found in idiomatic-spock demo project on GitHub from Rob Fletcher and in his presentation on YouTube.

Hot Reload Support with Spring Loaded and JHipster

Yesterday I dry to get hot development support for my Spring Boot example application. For this I first tried Spring Loaded. Spring Loaded is a Java agent that transforms classes at loadtime to support a better 'hot code replacement'. Spring Loaded supports the following types of code changes to replace hot at runtime: add, modify and delete methods, fields or constructors. To use the Spring Loaded Java agent download the agent JAR from the project page. Then add following Java VM arguments to run your Spring Boot application:

-javaagent:${project_loc:name}/springloaded-1.2.0.RELEASE.jar -noverify

In Eclipse e.g. you can use ${project_loc:..} variable to get the absolute path of your project.

JHipster reload Controller

Spring Loaded e.g. does not support to add new Controller Class at runtime. For this I add the JHipster loaded core to my project. JHipster it self is a Framework that is build on Maven, Spring and AngularJS. JHipster promises to support full hot reload of Java and JavaScript code. The realod support of JHipster is based on Spring Loaded. To use the JHipster add-on for 'hot code replacement' the Spring Loaded agent must be setup. To activate the JHipster add-on I add the following Java VM parameters to start my Spring Boot example application:

-javaagent:${project_loc:simpleweb-springboot}/build/springloaded/springloaded-1.2.0.RELEASE.jar -noverify 
-DhotReload.enabled=true
-DhotReload.watchdir[0]=${project_loc:simpleweb-springboot}/bin
-DhotReload.package.project=simpleblog
-DhotReload.package.domain=simpleblog.domain
-DhotReload.package.restdto=simpleblog.rest

In my Spring Boot application I add the following Conditional spring configuration for the JHipster reload support:
With the JHipster extension now I could add new controller or service classes at runtime. But there are also restrictions I could not change the base class or the interface which a class implements. For this I must restart my application.

You find my Spring Boot demo application with the hot reload support on GitHub. I only tried the Demo with Eclipse but it should also work in other environments.

Spring Context the Grails Way

Since Spring Framework Version 4.0, there is a way to define a spring context in a groovy DSL, like the spring configuration can be done in Grails. A short description of this DSL can be found in the JavaDoc of the class GroovyBeanDefinitionReader and on the spring.io blog there is a good post that covers the DSL features.

Today I played around with the DSL, my context configuration covers a lot of the DSL feature and is shown in the listing.
If you like to use the groovy context in Spring JUnit test a ContextLoader must be defined, a simple test that uses the groovy context is show in the listing.
The whole demo project can be found on my github account here.

mapstruct - Java bean mappings

In the Java space there are a lot of tools for bean mappings, for example a common tool is Dozer. But the most tools I know, does a lot of magic, by using the Java reflection API, this is bad for debugging the bean mapping logic. Now there is a new and hot Java open source tool called  mapstruct. The project provides a simple way to map Java beans. By generating the mapping code from a Java interface with annotations. A simple mapping for a Car bean and a Engine bean  can be found in the code bellow.
Mapstruct also provides a simple way for own mappings, for this a mapper can be define by the uses attribute in the Mapper  annotation on the interface, the example use a mapper called PowerMapper. The implementation of this mapper  is shown in the code bellow.
How the generated bean mapper can be used is show in the following JUnit test.
More Details about mapstruct see the project documentation. I think mapstruct it is a very promising bean mapping tool, try it and leave some comments here.

Project Templates with Lazybones

Lazybones is a cool command line tool to manage project templates. The tool can be used for example to create a ratpack project. But you can also manage your own project templates, to create any kind of project with lazybones from your own template.

Install lazybones

Before you can use lazybones you should install it. To install lazybones you can use gvm the Groovy enVironment Manager.

gvm install lazybones

More options how to install lazybones can be found in the project README.

How to create your own template

It is easy to create an own project template. For your own templates project you should use the lazybones template. To create a simple templates project, the following steps should be done:

1. Create a workspace folder for the template project
2. Switch to the workspace folder
3. Create the templates project from the lazybones template: 
• lazybones create lazybones-project simple-templates-project
4. Switch into the templates project: cd simple-templates-project
5. Create a template in the templates folder:
• mkdir templates/simple-groovy/
• Add a VERSION file in the folder "templates/simple-groovy". The VERSION file should contain the template version.
• Add a README.md file in the same folder, the README file should contain the template project description.
• Add a build.gradle file in the folder to build the template project.
6. Now you can publish the template by running a gradle task. To install the template project local run: 
• gradle installAllTemplate
7. The new template now can be used from the lazybones command line tool:
• lazybones create simple-groovy 0.0.1 my-app

More details how to publish the template project see the lazybones template development documentation.

Template Logic

If you need some user interaction or template logic add a "lazybones.groovy" file in the template project. Here simple "lazybones.groovy" script:

My simple templates demo project can be found here on github. More details about lazybones see the project documentation and the templates projects.

How do you get the Bundle Class Loader?

The class loader of a bundle can be obtained through the BundleWiring interface. The BundleWiring interface has replaced the OSGi PackageAdmin service. The new interface can be used to get any information of the actual (dependencies) wiring of a bundle. And the new API also provides a method to get the class loader instance of a bundle.

Continuous Delivery in Action

Getting started with Spock (in 5 min)

More about Spock see:

• Spock Framework - http://www.spockframework.org
• Spock Examples - https://github.com/spockframework/spock-example
• Spock Documentation - http://docs.spockframework.org/en/latest/

Spring Security Java Configuration

Spring Security now has new module called spring-security-javaconfig. It provides a fluent builder API to configure spring security in Java code instead of XML. I used the CI build in a simple demo blog application and I really like it to have no XML file in the whole web project. The code snippet belows shows the security configuration from this demo appliction.
To get spring security support up and running the "DelegatingFilterProxy" must be added to your web application filter chain. This can also be done without any XML by using the Servlet API 3.0 features by using the Spring "AbstractAnnotationConfigDispatcherServletInitializer" base class to configure the web-app. The web-app configuration is shown in the code listing below.
More details on spring security java config see the github project.

Gradle and Continuous Delivery

Here my slides from the SEITENBAU Developer Convention 2013. The slides provide an introduction to Gradle Basics and cover how to use Gradle for Continuous Delivery.

Simple Table DSL in Groovy

Sometimes the best way to model data is as a table. A good example where you could use tables is the spock framework. Spock is a great testing framework for Java and Groovy. In spock the test parameters can be defined as a table. The spock framework use Groovy AST transformations to implement the DSL for the tables. I think about if there is a simpler way to parse an embedded table DSL in groovy. Not with the same features then the spock table DSL. My requirements for the DSL are to define a table and to have support for variables in the table.

Here a short example of such a table:

To implement the DSL parser in groovy I use two groovy languages feature:

1. The category feature to define the OR operators, for the different types of the table values 
2. The dynamic of groovy for the variable support, the getProperty is overwritten and creates a object of type Var for a undefined groovy variable

The code below contains a simple groovy implementation of a table DSL parser. The simple parser now can be used to parse the table DSL from the example above. How the DSL can be use in JUnit is show in the parameterized test in the listing below. Not a perfect example, because for testing you should use Spock instead.

Overview Parameterized Tests with JUnit

Gerard Meszaros's describes in his great book with the title xUnit Test Patterns a pattern with the name Parameterized Test. This blog post describes how the pattern can be implemented in a JUnit 4.X test. The post compares three different options.

1. JUnit Parameterized Test

The JUnit framework comes with a runner for parameterized tests. The parameters are defined by a static function which is marked with the annotation @Parameters. The JUnit Runner is called Parameterized.

Example: 
Output - Eclipse JUnit View: 

Advantages
No extra framework or library for parameterized tests is needed. The JUnit view in eclipse and also in other IDEs works fine. One test with one defined parameter set can be invoked via the JUnit view in eclipse.

Disadvantages
The output from the tests is not clear. The output shows only the index number of the used test parameter. Only one test data model and parameter set per test class.

2. More JUnit Parameterized Test in a Test Class

It is possible to have more then one parameterized JUnit test in one test class by using the experimental runner "Enclosed".

Example: 
Output - Eclipse JUnit View:

Advantages
Grouping logic tests together in one class. Each test can be run from the JUnit view, a single test can be executed for debugging.

Disadvantages
Lots of boilerplate code of the embedded classes.

3. TwiP

TwiP is JUnit extension for parameterized tests. The library brings a JUnit runner, which is named "TwiP".

Example: 
Output - Eclipse JUnit View: 

Advantages
More then one parameterized test in a class is possible. Mixing parameterized and not parameterized tests is possible in one test class. Clear test output toString() method is used for the test parameters.

Disadvantages
A single test could not be chosen from the JUnit output (Eclipse JUnit view) and could not be invoked. This makes debugging the tests difficult because always all test combination must be executed to debug one failing test with one special combination.

4. JUnit Params

JUnit Params is another JUnit extension for parameterized tests like TwiP. The essential difference between TwiP and JUnit Params are the syntax how to define the parameterized tests.

Example: 
Output - Eclipse JUnit View: 

Advantages
Same advantages as TwiP and a little bit clearer test output then TwiP.

Disadvantages
Same disadvantages as TwiP a single test could not be invoked.

5. Summary

A perfect solution for a parameterized test in JUnit does not exists. TwiP and JUnitParams provided the way I like to write parameterized tests. But TwiP and also JUnitParams test cannot be debugged a single test can not be executed. I think the problems lies in the JUnit design for the descriptions and not in the TwiP or the JUnitParams project. Hope there will be a better solution in the future. So it's a difficult choice

Performance Apache Common StringUtils Split and Google Guava Splitter

Last Friday I have a discussion with a colleague at SEITENBAU about the semantic of the split method of the Apache common lang StringUtils class. At the end we have compared the Google Guava Splitter API with the Apache commons Lang StringUtils split methods. Our opinion after that is that the source code based on Guava could be better understood and is much clearer.

After comparing the APIs, we have thought about which of the two APIs has the faster split implementation. So I have build simple performance test for the two String split implementations. The result has surprised me. The StringUtils split method is in my test case much faster then the Guava Splitter split method.

Test setup is I generate 5000 random strings with a length of 10000. The test strings contains commas to split the strings in the test. I invoke the Apache common spilt method and the Guava Splitter with the same test data, the performance result is shown in the table bellow.

Test Runs	1	2	3	4
Apache Common StringUtils.split(…)	126 ms	122 ms	121 ms	122 ms
Google Guava splitter.split(…)	352 ms	350 ms	346 ms	349 ms

Here the source of my simple performance test:
Why
Has anybody an idea why the Guava API in my test is slower then the StringUtils split method? I read that the Guava Splitter performance should be very good. Therefore, I am surprised about the result.

Here the dependencies I have used for the performance test:

Equinox CM and ECF inconsistent Behavior

This evening I had a long OSGi debugging session with the Equinox Configuration Admin and ECF based Remote Services implementation. In the end I found out, it was my mistake used configuration admin wrong. And I update this blog post.

But the problem is that the behavior of the configuration admin depends on which bundles calls the createFactoryConfiguration(...) method and this makes debugging hard.

The problem was that when I create the first time a factory configuration via my remote bundle (which is running on the same system local in other OSGi framework), I become a exception. The remote bundle invokes the method "createWall(…)" see the code sample:

When the first caller of this method was the remote bundle I become the following exception (when the second caller of the configuration admin is a local bundle got the same exception, e.g. when a configuration is created via the apache webconsole):

When the same logic is called first time from a local bundle everything works fine. After some time of debugging, I found the issue. The point is not that the bundle is local or remote.

In the implementation of the method "createWall(...)" the Configuration Admin method "createFactoryConfiguration(...)" with location null is used. The JavaDoc of this method says, when this method is called the first time, with location null, then the location of the first bundle is used which register a service.

OSGi Compendium Specification JavaDoc for the createFactoryConfiguration says:

"The Configuration is bound to the location specified. If this location is null it will be bound to the location of the first bundle that registers a Managed Service Factory with a corresponding PID."

In my case the first bundle was sometimes indirect the remote bundle. So I have the problem and become the exception. My fix was to set the location to the bundle location of the bundle which creates the wall configuration, see the code sample:

In end I found out, that the two OSGi frameworks has the same configuration area, the same local directory. Provider an host are running on the same system. It was a coincidence that the fix work. If the PID for the configuration folder was not locked by the other OSGi instance everything works. So in the end I must say it is my mistake because the OSGi instances had the same directory configured as configuration area. But the design that the location depends on the first caller makes debugging crazy. Does anybody know if this is the expected behavior? This is really hard to debug, that the directory where the configuration is stored could depend on the first caller. What is the best practice set the location parameter always?

Groovy Closures and Annotation Parameters

Since Groovy 1.8 there is support to have a closure as a parameter in annotations. A nice example how to use this feature is the GContracts project, a groovy design by contract framework, which use closure annotation parameters, to define pre and post conditions of a method.

The support of closures in annotations provides a simple way to have much more dynamic in annotations. This is cool and provides new areas where you now could use annotations. Here a simple example how a closure as annotation parameter could be used to group properties.


More details about closures in annotation see the groovy 1.8 release notes.

Links:

• http://groovy.codehaus.org/Groovy+1.8+release+notes#Groovy18releasenotes-Closureannotationparameters 
• https://github.com/andresteingress/gcontracts

Crazy Scala Combinator Parser

Updates

• 2012-06-?? Add Chris Hodapp version to the post.
• 2012-06-23 Fix word is now in the second sample no method anymore its a val

Create my first parser with the Scala combinator library. I really like the concept to have simple way to compose simple parsers via high-level functions to a complex parser. But I think the syntax for the internal Scala parser DSL is a little bit crazy. I’m not sure why the method names in Scala always must be as short as possible e.g. rep. For me this makes the source of my simple parser really crazy. Here my first simple key value parser to show how the source of Scala parser looks like.


The concept behind the Scala combinator parsers are great, try it and you will learn a lot about how to create a parser in functional language. But I don’t understand why always the shortest and cryptic methods names are used in Scala. This type of naming makes the source hard to read and understand and it makes the Scala source so crazy. But when you know the cryptic names it makes a lot of fun to write such crazy Scala source.

Try it more details about regex parsers please see the Scala doc. The demo parser is not perfect and I’m not a Scala professional, if there are any comments feel free write me how to make it better.

A better Scala version of the parser by Chris Hodapp here: Links

• http://www.scala-lang.org/api/current/index.html#scala.util.parsing.combinator.RegexParsers

Groovy Declared Fields Filter Synthetic

Groovy generates some "synthetic" field to a class, that means the reflection method getDeclaredFields returns more fields than fields which are declared in the Groovy source of a class. To filter the "synthetic" fields the Groovy grep method could be used e.g. "anyClass. declaredFields.grep { !it.synthetic }".

Links

• http://stackoverflow.com/questions/6069513/can-we-get-declared-properties-of-a-groovy-class-by-its-order

Grails and Spring @Async Annotation

If some logic e.g. in a grails service should be invoked asynchronous, in Grails 2 the spring annotation @Async can be used. For that the spring annotation driven task support must be activated in the spring configuration. To activate the task support, the task namespace should be added to the spring configuration. Here a sample spring configuration ("resources.groovy").


Now the spring annotation can be used to mark e.g. service logic which should be invoked asynchronous. Here a sample to send mails asynchronous (for sending the mails the grails mail plugin is used).



For more details see also the spring framework documentation:
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async