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.