Dependency Injection for Extensions, Second Edition

At this years EclipseCon I implemented an extension factory utility that could be used to delegate the creation of an extension object to a spring context (if you are using Spring Dynamic Modules). The result was that you were able to define your extensions as spring beans including all the nice spring features (dependency injection, aop, dessert topping, whatever...). That first implementation was nice, but had a number of stupid limitations (worked only for active bundles, for example). The good news is: A new version is available that includes some nice improvements... :-)

Firstofall, here is the new version of the Spring-Extension-Factory:

• org.eclipse.springframework.util_1.0.1.zip

The new features are:

• Ability to declare the bean-id explicitly within the extension definition


• Automatic start of non-active bundles (and application context creation via Spring Dynamic Modules) when an extension is being created

How can I use this extension factory? Lets look at some examples. Lets assume you implement an RCP application and you would like to define a view as spring bean to inject some dependencies. First, you declare your spring bean inside the spring context:

<bean id="myview"
    class="org.eclipse.example.springdm.rcpview.View"
    scope="prototype">
  <property name="myService" ref="serviceBean"/>
</bean>

Okay, this defines the spring bean called "myview" and injects a bean with the id "serviceBean" as a dependency into my view. The class of the view is the normal view implementation that you are familiar with. Don't forget to declare the bean as of scope "prototype". Otherwise spring would return always the same object every time an extension should be created (which is not the contract of the extension mechansim).

Now we define the extension in the plugin.xml file:

<extension point="org.eclipse.ui.views">
  <view name="Message"
    allowmultiple="true"
    icon="icons/sample2.gif"
    class="org.eclipse.springframework.
          util.SpringExtensionFactory:myview"
    id="org.eclipse.example.springdm.rcpview.view">
  </view>
</extension>

The class that is now referenced in the extension instead of the view itself is the spring extension factory followed by a colon and the id of our bean from the spring context. The rest of the extension definition looks exactly as before (without the extension factory).

The Spring Extension Factory includes two additional options to refer to the bean id within the extension definition. This is the strategy that I implemented into the extension factory:

1. If a bean-id is explicitly defined (like in the example above), use this id to lookup the bean.


2. If not, search for an id attribute within the contribution element of the extension and use it as the bean-id.


3. If no id attribute is found inside the contribution element, try to use the id of the extension itself as bean-id.
   

The first option is the most explicit one. The second option works just for those extension definitions where the corresponding extension point schema defines an id attribute as part of the specific extension (this is the case for views, but obviously not for all extension points). The third option can be used for all extension points but is less explicit that the first one. In the end its a matter of taste which option you prefer.

Comments, feedback and improvements, of course, highly welcome.

Have fun with it!!!

At this years EclipseCon I implemented an extension factory utility that could be used to delegate the creation of an extension object to a spring context (if you are using Spring Dynamic Modules). The result was that you were able to define your extensions as spring beans including all the nice spring features (dependency injection, aop, dessert topping, whatever...). That first implementation was nice, but had a number of stupid limitations (worked only for active bundles, for example). The good news is: A new version is available that includes some nice improvements... :-)

Firstofall, here is the new version of the Spring-Extension-Factory:

• org.eclipse.springframework.util_1.0.1.zip

The new features are:

• Ability to declare the bean-id explicitly within the extension definition


• Automatic start of non-active bundles (and application context creation via Spring Dynamic Modules) when an extension is being created

How can I use this extension factory? Lets look at some examples. Lets assume you implement an RCP application and you would like to define a view as spring bean to inject some dependencies. First, you declare your spring bean inside the spring context:

<bean id="myview"
    class="org.eclipse.example.springdm.rcpview.View"
    scope="prototype">
  <property name="myService" ref="serviceBean"/>
</bean>

Okay, this defines the spring bean called "myview" and injects a bean with the id "serviceBean" as a dependency into my view. The class of the view is the normal view implementation that you are familiar with. Don't forget to declare the bean as of scope "prototype". Otherwise spring would return always the same object every time an extension should be created (which is not the contract of the extension mechansim).

Now we define the extension in the plugin.xml file:

<extension point="org.eclipse.ui.views">
  <view name="Message"
    allowmultiple="true"
    icon="icons/sample2.gif"
    class="org.eclipse.springframework.
          util.SpringExtensionFactory:myview"
    id="org.eclipse.example.springdm.rcpview.view">
  </view>
</extension>

The class that is now referenced in the extension instead of the view itself is the spring extension factory followed by a colon and the id of our bean from the spring context. The rest of the extension definition looks exactly as before (without the extension factory).

The Spring Extension Factory includes two additional options to refer to the bean id within the extension definition. This is the strategy that I implemented into the extension factory:

1. If a bean-id is explicitly defined (like in the example above), use this id to lookup the bean.


2. If not, search for an id attribute within the contribution element of the extension and use it as the bean-id.


3. If no id attribute is found inside the contribution element, try to use the id of the extension itself as bean-id.
   

The first option is the most explicit one. The second option works just for those extension definitions where the corresponding extension point schema defines an id attribute as part of the specific extension (this is the case for views, but obviously not for all extension points). The third option can be used for all extension points but is less explicit that the first one. In the end its a matter of taste which option you prefer.

Comments, feedback and improvements, of course, highly welcome.

Have fun with it!!!

Dependency Injection for Extensions, Second Edition

Equinox Aspects and Spring-DM at the OSGi-Community-Event 2008

The OSGi-Community-Event 2008 in Berlin is less than two weeks ahead and I am pretty excited to give a talk on Spring Dynamic Modules there as well as some live demos on Equinox Aspects at the evening reception Tuesday night. The talk on Spring-DM will introduce the possibilities of using the Spring framework and Spring-DM within the OSGi world using some examples and live code. For the evening demo of Equinox Aspects I will do my very best to show the current state of Equinox Aspects together with some cool new features things like dynamics (aspects coming and going) with Equinox Aspects and (maybe) even load-time aspect weaving for Spring and Spring-DM within OSGi using Equinox Aspects. So please keep your fingers crossed for my live demos. :-)

The OSGi-Community-Event 2008 in Berlin is less than two weeks ahead and I am pretty excited to give a talk on Spring Dynamic Modules there as well as some live demos on Equinox Aspects at the evening reception Tuesday night. The talk on Spring-DM will introduce the possibilities of using the Spring framework and Spring-DM within the OSGi world using some examples and live code. For the evening demo of Equinox Aspects I will do my very best to show the current state of Equinox Aspects together with some cool new features things like dynamics (aspects coming and going) with Equinox Aspects and (maybe) even load-time aspect weaving for Spring and Spring-DM within OSGi using Equinox Aspects. So please keep your fingers crossed for my live demos. :-)

Equinox Aspects and Spring-DM at the OSGi-Community-Event 2008

Finally aspects become dynamic

I recently committed some changes to the Equinox Aspects project which allows the Equinox Aspects runtime to handle dynamically uninstalled aspects correctly with regards to the woven bundles in the system. Having this it was only a small step to also deal with dynamic updates to aspect bundles as well as woven bundles at runtime. And now, finally, we are there: real dynamics for aspects. You can install, update and uninstall aspects at runtime as you like and the Equinox Aspects runtime takes care that everything will be woven and re-woven correctly. This is really really cool and a huge step towards real OSGi-enabled AOP, I think.

But what happens if aspect bundles are installed, updated or uninstalled at runtime? All other bundles that need to be woven, that need to be re-woven or that need to be un-woven from the aspect are updated automatically by the aspect runtime using the OSGi mechanisms. This means also that your system should be able to deal with OSGi dynamics and bundles coming and going (which is not a trivial thing to do). So be a good citizen of the OSGi world and your bundles will behave well when aspects are coming and going at runtime... :-)

I recently committed some changes to the Equinox Aspects project which allows the Equinox Aspects runtime to handle dynamically uninstalled aspects correctly with regards to the woven bundles in the system. Having this it was only a small step to also deal with dynamic updates to aspect bundles as well as woven bundles at runtime. And now, finally, we are there: real dynamics for aspects. You can install, update and uninstall aspects at runtime as you like and the Equinox Aspects runtime takes care that everything will be woven and re-woven correctly. This is really really cool and a huge step towards real OSGi-enabled AOP, I think.

But what happens if aspect bundles are installed, updated or uninstalled at runtime? All other bundles that need to be woven, that need to be re-woven or that need to be un-woven from the aspect are updated automatically by the aspect runtime using the OSGi mechanisms. This means also that your system should be able to deal with OSGi dynamics and bundles coming and going (which is not a trivial thing to do). So be a good citizen of the OSGi world and your bundles will behave well when aspects are coming and going at runtime... :-)

Finally aspects become dynamic

Aspect Weaving for OSGi at Java Forum Stuttgart

This years Java-Forum-Stuttgart 2008 is on the 3rd of July and takes place again at the Kultur- & Kongresszentrum Liederhalle (KKL) in Stuttgart, Germany. I attended this nice conference over the past years talking about various topics and listened to interesting talks there. Its well organized and its a pleasure to be there.
This year I will talk about one of my favorite topics: Aspect Weaving in OSGi. I will tell people what they need if they are going to adopt OSGi and AOP for the same system and how it is possible to modularize aspects into OSGi bundles. The talk will contain some live demos showing load-time aspect weaving for OSGi using the Equinox Aspects open-source project. It will be way cool, don't miss it! :-)

This years Java-Forum-Stuttgart 2008 is on the 3rd of July and takes place again at the Kultur- & Kongresszentrum Liederhalle (KKL) in Stuttgart, Germany. I attended this nice conference over the past years talking about various topics and listened to interesting talks there. Its well organized and its a pleasure to be there.
This year I will talk about one of my favorite topics: Aspect Weaving in OSGi. I will tell people what they need if they are going to adopt OSGi and AOP for the same system and how it is possible to modularize aspects into OSGi bundles. The talk will contain some live demos showing load-time aspect weaving for OSGi using the Equinox Aspects open-source project. It will be way cool, don't miss it! :-)

Aspect Weaving for OSGi at Java Forum Stuttgart