Karaf Cellar 4.1.1 deserialization issue

Due to a import limitation on the Cellar project, it is impossible to deserialize objects outside the cellar or hazelcast namespace:

[KARAF-5636] Enable dynamic import on cellar-hazelcast and dynamic import in Cellar DOSGi in order to support user defined class transport

The issue is solved in the next version, but there is a simple workaround. Make sure your bundles containing the classes for deserialization have the following namespace added to the manifest import-package statement:

org.apache.karaf.cellar

Forcing this into the manifest with the maven bundle plugin is not that straightforward when the bundle does not contain a real dependency on Cellar. But it is possible by declaring the namespace optional:

<Import-Package>

    org.apache.karaf.cellar*;resolution:=optional,*

</Import-Package>

On Karaf startup or on bundle install, Cellar will scan the import statements and detect and register your API bundles (OSGi extender pattern). Now it is able to find the required classes for deserialization and do a tccl switch to load it from the API bundle classpath.

Happy clustering...

JSR 349 Hibernate Bean Validation 1.1 on OSGi

Validation of objects and object graphs is a cross cutting concern and used within several architectural layers, and therefore should be separated from the business logic. The JSR349 specification describes a mechanism using annotations. At the time of writing, the latest reference implementation of the JSR 349 spec is the Hibernate Validator version 5.4.2.Final. The metadata API can be configured by XML, and the constraints can be extended by creating custom validation annotations.

Hibernate Validator requires special handling on OSGi, a proof of concept is located under net.betzel.javax.osgi.beanvalidation. Build the project and drop the produced Karaf archive file into the Karaf deploy folder to see the mechanism in action.

Readables:

http://beanvalidation.org
http://www.baeldung.com/javax-validation

JavaCPP libpostal preset

Parsing and normalizing street addresses around the world

Street addresses are among the most difficult artifacts of human language for any piece of parsing software. If you have ever tried it yourself, you know what i am talking about. Having to parse addresses from around the world where each country’s addressing system has its own set of conventions and peculiarities makes this even more difficult.

Searching the net for solutions to this problem i stumbled upon libpostal: a multilingual street address parsing/normalization library, written in C, that can handle addresses all over the world.

Libpostal uses machine learning and is informed by tens of millions of real-world addresses from OpenStreetMap. It currently supports normalization's in 60 languages and can parse addresses in more than 100 countries.

Since my veins are filled with caffeine i needed a Java JNI bridge to span my platform gap. There are bindings available under jpostal,  but having to hassle with all the compiler stuff and the native library handling in your project afterwards makes this not an attractive option.
To ease Java integration there is a great JNI library called JavaCPP. A tool that can not only generate JNI code but also build native wrapper library files from an appropriate interface file written entirely in Java. It can also parse automatically C/C++ header files to produce the required Java interface files. As a topping it generates a Maven artifact containing the whole setup including the specific platform native lib and loading capabilities, ready for use in your Maven projects.
I have used some presets of this project several times before and i believe it is a perfect fit for libpostal, giving the opportunity to add a complete new preset to this great project.

A big thanks to Samuel Audet for the support he provided throughout the process, providing the needed native platform knowledge i was lacking.

The 1.4 release also incorporates the new Systems preset, providing low level API access for Linux, MacOS an Windows.

Resources:

libpostal
bytedeco blog

JavaCPP

JavaCPP Presets