Distributed OSGi with Newton + peaberry
Last week I finally got around to testing peaberry with the Newton distributed OSGi framework from Paremus. It was surprisingly easy to use peaberry with Newton, I only had to make a couple of changes to support native LDAP filter strings when querying the OSGi service registry:
http://code.google.com/p/peaberry/issues/detail?id=34
These changes are now available in the 1.1.1 release of peaberry. I've also written up a distributed OSGi example based on the existing Spring example.
The new example unpacks on top of a binary installation of Newton 1.3.2 and shows how you can use property files to switch between local and remote services without changing your compiled Guice bindings.
While writing the example I realized that there are a lot of cool abstractions we can build on top of the basic peaberry API. I'm trying to follow the model used in both Guice and OSGi and keep the core API as simple, lean, and mean as possible while providing ways for others to build even more user-friendly layers, such as BindForge, on top.
There are two essential layers I would like to add in the next peaberry release:
I'm also considering adding extender bundles to scan for service annotations or scrape 'blueprint' XML and dynamically configure the relevant bindings at runtime, but that would be more of a 1.3 feature. If you're interested in building on top of peaberry, or you have an interesting idea for a new feature, please let me know.
Until then take a look at Newton+peaberry and see distributed OSGi in action!
http://code.google.com/p/peaberry/issues/detail?id=34
These changes are now available in the 1.1.1 release of peaberry. I've also written up a distributed OSGi example based on the existing Spring example.
The new example unpacks on top of a binary installation of Newton 1.3.2 and shows how you can use property files to switch between local and remote services without changing your compiled Guice bindings.
While writing the example I realized that there are a lot of cool abstractions we can build on top of the basic peaberry API. I'm trying to follow the model used in both Guice and OSGi and keep the core API as simple, lean, and mean as possible while providing ways for others to build even more user-friendly layers, such as BindForge, on top.
There are two essential layers I would like to add in the next peaberry release:
- Configuration - but not tied directly to the OSGi CM service
- Lifecycle - but again, not tied directly to Bundles and Activators
I'm also considering adding extender bundles to scan for service annotations or scrape 'blueprint' XML and dynamically configure the relevant bindings at runtime, but that would be more of a 1.3 feature. If you're interested in building on top of peaberry, or you have an interesting idea for a new feature, please let me know.
Until then take a look at Newton+peaberry and see distributed OSGi in action!
