Peaberry: injecting OSGi services using Guice
Several months ago I blogged about Guice-OSGi, my OPS4J research project looking at using Guice to do dependency injection of OSGi services. Since then I've been distracted with other projects, moving house and our new cat (who almost managed to rewrite my DevCon submission when he took an keen interest in my MacBook, and then managed to disconnect the ADSL line - what a critic!)
Anyway, it seems that to officially use OSGi in a project name it must be an adjective, which is why Spring-OSGi has transformed into: "Spring Dynamic Modules for OSGi(tm) Service Platforms". Rather than try to compete with an equally long title, I decided to resurrect a name I'd previously used for a demo project: "peaberry", which is a special type of coffee bean. (as my wife will tell you, I really like coffee...)
So peaberry is the new Guice-OSGi, and is now hosted over at Google Code:
http://code.google.com/p/peaberry
I decided to host the project there rather than at OPS4J because it makes it easier for people who know the Guice site to find their way to peaberry. BTW, if you're interested in helping out, let me know and I'll add you to the project team.
I've just made the first download available:
peaberry-0.1.jar
which is an OSGi bundle of the latest trunk version of Guice with patches for issue 49 (binding factories) and issue 94 (classloader interception of generated classes) which are needed to use Guice in a reloadable container, such as OSGi. Hopefully these patches will eventually be folded back into the main Guice tree.
The next step is to install a 'bridge' classloader (based on issue 94) to allow generated classes to see both the internal Guice code and external user classes without needing DynamicImport-Package:* in the peaberry bundle. After that I plan to migrate the Guice-OSGi annotation work over to peaberry (based on issue 49) and remove the need to extend a specific base class to bootstrap the service injection process.
As mentioned in my last post, I've submitted a talk about my work on peaberry to the DevCon site, so if enough people are interested I may get the chance to explain all the cool features in person.
Anyway, it seems that to officially use OSGi in a project name it must be an adjective, which is why Spring-OSGi has transformed into: "Spring Dynamic Modules for OSGi(tm) Service Platforms". Rather than try to compete with an equally long title, I decided to resurrect a name I'd previously used for a demo project: "peaberry", which is a special type of coffee bean. (as my wife will tell you, I really like coffee...)
So peaberry is the new Guice-OSGi, and is now hosted over at Google Code:
http://code.google.com/p/peaberry
I decided to host the project there rather than at OPS4J because it makes it easier for people who know the Guice site to find their way to peaberry. BTW, if you're interested in helping out, let me know and I'll add you to the project team.
I've just made the first download available:
peaberry-0.1.jar
which is an OSGi bundle of the latest trunk version of Guice with patches for issue 49 (binding factories) and issue 94 (classloader interception of generated classes) which are needed to use Guice in a reloadable container, such as OSGi. Hopefully these patches will eventually be folded back into the main Guice tree.
The next step is to install a 'bridge' classloader (based on issue 94) to allow generated classes to see both the internal Guice code and external user classes without needing DynamicImport-Package:* in the peaberry bundle. After that I plan to migrate the Guice-OSGi annotation work over to peaberry (based on issue 49) and remove the need to extend a specific base class to bootstrap the service injection process.
As mentioned in my last post, I've submitted a talk about my work on peaberry to the DevCon site, so if enough people are interested I may get the chance to explain all the cool features in person.
No comments:
Post a Comment