I complied with the term of the publishing company not to publish the PDF file of my latest article on the hook mechanisms of the Equinox OSGi runtime for a certain period of time, but the waiting time is now over. I put the PDF of the latest article on "Getting Hooked on Equinox" (in German) for the German Eclipse Magazin online in the publications section. Enjoy!
Wednesday, March 26, 2008
Update: Getting Hooked on Equinox - Article in German Eclipse-Magazine
EclipseCon 2008: Short Talk on Adopting "The Eclipse Way"
I put my slides from my short talk at EclipseCon 2008 about adopting "The Eclipse Way" online in the events section. Enjoy!
I put my slides from my short talk at EclipseCon 2008 about adopting "The Eclipse Way" online in the events section. Enjoy!
EclipseCon 2008: Short Talk on Adopting "The Eclipse Way"
Labels:
Agile Software Development,
Conferences,
Eclipse
Tuesday, March 18, 2008
Dependency Injection for Extensions
While preparing the tutorial on Spring Dynamic Modules for this years EclipseCon I played a bit with using Spring Dynamic Modules to dependency inject beans into views or other stuff I typically define as extensions for my Eclipse Rich Client Platform application. The problem is that the actual objects for those extensions are created by the Extension Registry and do therefore not pass the spring context for dependency injection. I needed to find a way to combine those two technologies somehow.
I came up with a very small and trivial solution for this: I created a class called SpringExtensionFactory that implements IExecutableExtensionFactory from the Extension Registry mechanism. This extension factory takes an ID from the extension definition, finds the spring application context for the bundle that contributes the extension and tries to retrieve the spring bean with the same id from that application context. This bean is then returned as the extension object. This trivial solution does not require any additional programming work to be done, no load-time weaving (for @Configurable, for example), just plain nothing.
Yon can download this SpringExtensionFactory from here, its open-source under EPL 1.0:
The interesting question is which ID this extension factory takes from the extension definition to look up the bean in the application context. The answer is: It is a two-step process. It first tries to find an "id" attribute within the configuration element of the extension definition. This is typically the case for RCP views, for example. They have an "id" attribute to identify the view. If there is no "id" attribute found within the configuration element it steps back to the extension definition itself and takes the "id" attribute from there.
If you have any questions I am happy to help you with this stuff. Just leave a comment (to share your thoughts and questions with the community).
I came up with a very small and trivial solution for this: I created a class called SpringExtensionFactory that implements IExecutableExtensionFactory from the Extension Registry mechanism. This extension factory takes an ID from the extension definition, finds the spring application context for the bundle that contributes the extension and tries to retrieve the spring bean with the same id from that application context. This bean is then returned as the extension object. This trivial solution does not require any additional programming work to be done, no load-time weaving (for @Configurable, for example), just plain nothing.
Yon can download this SpringExtensionFactory from here, its open-source under EPL 1.0:
The interesting question is which ID this extension factory takes from the extension definition to look up the bean in the application context. The answer is: It is a two-step process. It first tries to find an "id" attribute within the configuration element of the extension definition. This is typically the case for RCP views, for example. They have an "id" attribute to identify the view. If there is no "id" attribute found within the configuration element it steps back to the extension definition itself and takes the "id" attribute from there.
If you have any questions I am happy to help you with this stuff. Just leave a comment (to share your thoughts and questions with the community).
While preparing the tutorial on Spring Dynamic Modules for this years EclipseCon I played a bit with using Spring Dynamic Modules to dependency inject beans into views or other stuff I typically define as extensions for my Eclipse Rich Client Platform application. The problem is that the actual objects for those extensions are created by the Extension Registry and do therefore not pass the spring context for dependency injection. I needed to find a way to combine those two technologies somehow.
I came up with a very small and trivial solution for this: I created a class called SpringExtensionFactory that implements IExecutableExtensionFactory from the Extension Registry mechanism. This extension factory takes an ID from the extension definition, finds the spring application context for the bundle that contributes the extension and tries to retrieve the spring bean with the same id from that application context. This bean is then returned as the extension object. This trivial solution does not require any additional programming work to be done, no load-time weaving (for @Configurable, for example), just plain nothing.
Yon can download this SpringExtensionFactory from here, its open-source under EPL 1.0:
The interesting question is which ID this extension factory takes from the extension definition to look up the bean in the application context. The answer is: It is a two-step process. It first tries to find an "id" attribute within the configuration element of the extension definition. This is typically the case for RCP views, for example. They have an "id" attribute to identify the view. If there is no "id" attribute found within the configuration element it steps back to the extension definition itself and takes the "id" attribute from there.
If you have any questions I am happy to help you with this stuff. Just leave a comment (to share your thoughts and questions with the community).
I came up with a very small and trivial solution for this: I created a class called SpringExtensionFactory that implements IExecutableExtensionFactory from the Extension Registry mechanism. This extension factory takes an ID from the extension definition, finds the spring application context for the bundle that contributes the extension and tries to retrieve the spring bean with the same id from that application context. This bean is then returned as the extension object. This trivial solution does not require any additional programming work to be done, no load-time weaving (for @Configurable, for example), just plain nothing.
Yon can download this SpringExtensionFactory from here, its open-source under EPL 1.0:
The interesting question is which ID this extension factory takes from the extension definition to look up the bean in the application context. The answer is: It is a two-step process. It first tries to find an "id" attribute within the configuration element of the extension definition. This is typically the case for RCP views, for example. They have an "id" attribute to identify the view. If there is no "id" attribute found within the configuration element it steps back to the extension definition itself and takes the "id" attribute from there.
If you have any questions I am happy to help you with this stuff. Just leave a comment (to share your thoughts and questions with the community).
Dependency Injection for Extensions
EclipseCon 2008: Tutorial on Spring Dynamic Modules
EclipseCon 2008 has started today in sunny Santa Clara. I ran a two-hour tutorial about Spring Dynamic Modules together with Adrian Colyer from SpringSource and BJ Hargrave from IBM. The tutorial went well and was full-packed with a lot of stuff that we showed and demoed (mostly Adrian). Therefore it was no real surprise that we completely ran out of time and that my final part on Eclipse RCP and Spring Dynamic Modules was mostly skipped. Nevertheless you have the chance to take a look at the slides, they are online at the conference site as well as on my events section.
EclipseCon 2008 has started today in sunny Santa Clara. I ran a two-hour tutorial about Spring Dynamic Modules together with Adrian Colyer from SpringSource and BJ Hargrave from IBM. The tutorial went well and was full-packed with a lot of stuff that we showed and demoed (mostly Adrian). Therefore it was no real surprise that we completely ran out of time and that my final part on Eclipse RCP and Spring Dynamic Modules was mostly skipped. Nevertheless you have the chance to take a look at the slides, they are online at the conference site as well as on my events section.
EclipseCon 2008: Tutorial on Spring Dynamic Modules
Thursday, March 13, 2008
Release 1.1.0 of Equinox Aspects available
I am proud to announce that a new release of Equinox Incubator Aspects is available for download. Version 1.1.0 features a standard caching service for woven bundles on non-IBM VMs (contributed by Heiko Seeberger) and contains a number of big fixes and minor improvements.
Especially interesting is that you no longer need to define aspect bundles upfront in the config.ini when you start your runtime. The reworked supplementing mechanism can deal with such situations and handles even dynamically installed aspect bundles correctly (more details to follow in this blog).
This release works with all up-to-date and development versions of AJDT (1.5.1, 1.5.2, 1.6.0) and Eclipse (3.3, 3.4).
Especially interesting is that you no longer need to define aspect bundles upfront in the config.ini when you start your runtime. The reworked supplementing mechanism can deal with such situations and handles even dynamically installed aspect bundles correctly (more details to follow in this blog).
This release works with all up-to-date and development versions of AJDT (1.5.1, 1.5.2, 1.6.0) and Eclipse (3.3, 3.4).
I am proud to announce that a new release of Equinox Incubator Aspects is available for download. Version 1.1.0 features a standard caching service for woven bundles on non-IBM VMs (contributed by Heiko Seeberger) and contains a number of big fixes and minor improvements.
Especially interesting is that you no longer need to define aspect bundles upfront in the config.ini when you start your runtime. The reworked supplementing mechanism can deal with such situations and handles even dynamically installed aspect bundles correctly (more details to follow in this blog).
This release works with all up-to-date and development versions of AJDT (1.5.1, 1.5.2, 1.6.0) and Eclipse (3.3, 3.4).
Especially interesting is that you no longer need to define aspect bundles upfront in the config.ini when you start your runtime. The reworked supplementing mechanism can deal with such situations and handles even dynamically installed aspect bundles correctly (more details to follow in this blog).
This release works with all up-to-date and development versions of AJDT (1.5.1, 1.5.2, 1.6.0) and Eclipse (3.3, 3.4).
Release 1.1.0 of Equinox Aspects available
Subscribe to:
Posts (Atom)