Conference Slide Updates

I went to four conferences over the past weeks, talking about various topics around the Spring and Eclipse tooling universe. All the talks included a number of live demos, so just looking at the slides doesn't give you the full experience and content of the talk. But anyway, I uploaded the slides for those who want to take a look:

• SpringOne 2011: Spring Tooling Update - New and Noteworthy (pdf, slideshare)
• JAX London 2011: WaveMaker - Spring Roo - SpringSource Tool Suite - Choosing the right tool for the right job (pdf, slideshare)
• EclipseCon Europe 2011: All about Virgo (pdf, slideshare)
• WJAX 2011: WaveMaker - Spring Roo - SpringSource Tool Suite - Choosing the right tool for the right job (pdf, slideshare)

Enjoy!

I went to four conferences over the past weeks, talking about various topics around the Spring and Eclipse tooling universe. All the talks included a number of live demos, so just looking at the slides doesn't give you the full experience and content of the talk. But anyway, I uploaded the slides for those who want to take a look:

• SpringOne 2011: Spring Tooling Update - New and Noteworthy (pdf, slideshare)
• JAX London 2011: WaveMaker - Spring Roo - SpringSource Tool Suite - Choosing the right tool for the right job (pdf, slideshare)
• EclipseCon Europe 2011: All about Virgo (pdf, slideshare)
• WJAX 2011: WaveMaker - Spring Roo - SpringSource Tool Suite - Choosing the right tool for the right job (pdf, slideshare)

Enjoy!

Conference Slide Updates

"Spring Tooling – What’s Cooking" - Article in German Eclipse Magazin

Based on my short "New and Noteworthy" kind of talk at the JAX conference I wrote an article for the German Eclipse Magazin about what is cooking in the Spring tooling world. And the article made it for the top cover story:

So if you wanna know more about the latest news from the Spring tooling world, take a look at this. Aside of my quick walkthrough, Eberhard Wolff added a nice feature about the Cloud Foundry PaaS, which provides a great introduction to this platform. Enjoy!

Based on my short "New and Noteworthy" kind of talk at the JAX conference I wrote an article for the German Eclipse Magazin about what is cooking in the Spring tooling world. And the article made it for the top cover story:

So if you wanna know more about the latest news from the Spring tooling world, take a look at this. Aside of my quick walkthrough, Eberhard Wolff added a nice feature about the Cloud Foundry PaaS, which provides a great introduction to this platform. Enjoy!

"Spring Tooling – What’s Cooking" - Article in German Eclipse Magazin

Slides from Spring Tooing Talk at JAX 2011

Yesterday I gave a short talk at JAX 2011 called "Spring Tooling - What's Cooking". During the talk I gave an overview of the Spring tooling landscape, demoed some nice features of Spring IDE and the SpringSource Tool Suite and deployed a small Spring app into the hosted cloudfoundy.com PaaS as well as into a local CloudFoundry cloud running exclusively on my notebook. Was fun doing that all in 30min... :-)

Here are the slides from that talk:

• Spring Tooling - What's Cooking (pdf)

The slides also contain the part that I didn't talked about (the team behind Spring IDE and STS, challenges of distributed agile development and our release cycles). So if you missed that from the talk, take a look at those slides.

Yesterday I gave a short talk at JAX 2011 called "Spring Tooling - What's Cooking". During the talk I gave an overview of the Spring tooling landscape, demoed some nice features of Spring IDE and the SpringSource Tool Suite and deployed a small Spring app into the hosted cloudfoundy.com PaaS as well as into a local CloudFoundry cloud running exclusively on my notebook. Was fun doing that all in 30min... :-)

Here are the slides from that talk:

• Spring Tooling - What's Cooking (pdf)

The slides also contain the part that I didn't talked about (the team behind Spring IDE and STS, challenges of distributed agile development and our release cycles). So if you missed that from the talk, take a look at those slides.

Slides from Spring Tooing Talk at JAX 2011

Upcoming Event: JAX 2011

I am pretty happy to participate in the upcoming JAX 2011 conference in Mainz, Germany as part of the Eclipse Tools Day (organized by Lars Vogel). In my talk "Spring Tooling - What's cooking" I will talk about the stuff I am doing in my job all day: building Eclipse-based tooling for the Spring development platform. Aside of showing some of the nice features we built into this tooling (like direct deployment to different PaaS clouds and nice improvements for annotation-based spring programming) I will also take a look under the hood. I will take a look at the challenges and problems building this tooling on top of the Eclipse platform and how we adressed them.

See you at JAX 2011 in Mainz!

I am pretty happy to participate in the upcoming JAX 2011 conference in Mainz, Germany as part of the Eclipse Tools Day (organized by Lars Vogel). In my talk "Spring Tooling - What's cooking" I will talk about the stuff I am doing in my job all day: building Eclipse-based tooling for the Spring development platform. Aside of showing some of the nice features we built into this tooling (like direct deployment to different PaaS clouds and nice improvements for annotation-based spring programming) I will also take a look under the hood. I will take a look at the challenges and problems building this tooling on top of the Eclipse platform and how we adressed them.

See you at JAX 2011 in Mainz!

Upcoming Event: JAX 2011

Spring Extension Factory now on Github

Two years ago I wrote a tiny little piece of software that lets you combine Spring Dynamic Modules and the Equinox Extension Registry in an easy way. Now I found the time to put this SpringExtensionFactory on Github. So if you ever wanted to use Spring Dynamic Modules to inject dependencies into your RCP view and editors - take a look, its quite simple to use... :-)

Two years ago I wrote a tiny little piece of software that lets you combine Spring Dynamic Modules and the Equinox Extension Registry in an easy way. Now I found the time to put this SpringExtensionFactory on Github. So if you ever wanted to use Spring Dynamic Modules to inject dependencies into your RCP view and editors - take a look, its quite simple to use... :-)

Spring Extension Factory now on Github

Load-Time Weaving for Spring-DM

Load-time weaving in an OSGi environment is different than in single-classpath-settings like you often have in Java. There you typically use a JVM agent or a specialized classloader that gets ClassFileTransformer components injected from your application. Those ClassFileTransformer components then to the real job of modifying bytecode at load-time. This is also used in the Spring framework to enable aspect weaving or JPA bytecode enhancements.
This gets different when you are working in an OSGi environment. Within OSGi you no longer have a single classpath application, you cannot (or at least should not) create specialized classloaders for yourself to do the magic, maybe the weaving should happen specifically for each bundle or the woven code gets additional dependencies woven into it. Using Spring in an OSGi environment doesn't make things easier. You can use Spring Dynamic Modules to implement really cool OSGi applications, but your Spring load-time weaving support remains broken to some degree (see all the related questions in the Spring-DM forum).
I often thought about using Equinox Aspects to solve these problems. Since Equinox Aspects is not tightly bound to AspectJ weaving only, you could re-use the base infrastructure to hook any kind of bytecode modifier into the Equinox runtime - and reuse the caching of Equinox Aspects at the same time.

Now I have a first sketch implemented that bridges between Spring-LTW and Equinox Aspects. The EquinoxAspectsLoadTimeWeaver class implements the LoadTimeWeaver interface of Spring and can therefore be used in your spring context as the load-time weaver component:

<context:spring-configured>
<context:annotation-config>
<context:load-time-weaver
  class="org.eclipse.equinox.weaving.springweaver.EquinoxAspectsLoadTimeWeaver"/>

If you define this load-time weaver your bundle need to define an Import-Package on "org.eclipse.equinox.weaving.springweaver", of course.

To use this kind of load-time weaver definition to need to add "org.eclipse.equinox.weaving.hook" (from Equinox Aspects) to your target platform as well as "org.eclipse.equinox.weaving.springweaver":

• org.eclipse.equinox.weaving.springweaver_0.1.1.zip
  

When you launch your OSGi runtime you need to set the system property: (osgi.framework.extensions=org.eclipse.equinox.weaving.hook) and start the springweaver bundle right at startup. You can do this by adding it to the config.ini file (org.eclipse.equinox.weaving.springweaver@4:start). This is basically the same when using Equinox Aspects, except that you no longer start org.eclipse.equinox.weaving.aspectj but instead the springweaver bundle.

There are still some issues that need to be solved (see this comment in the spring forum for details), but I hope to can try it out and tell me what works fine and what needs some more work.

Feedback always welcome! Enjoy!

Load-time weaving in an OSGi environment is different than in single-classpath-settings like you often have in Java. There you typically use a JVM agent or a specialized classloader that gets ClassFileTransformer components injected from your application. Those ClassFileTransformer components then to the real job of modifying bytecode at load-time. This is also used in the Spring framework to enable aspect weaving or JPA bytecode enhancements.
This gets different when you are working in an OSGi environment. Within OSGi you no longer have a single classpath application, you cannot (or at least should not) create specialized classloaders for yourself to do the magic, maybe the weaving should happen specifically for each bundle or the woven code gets additional dependencies woven into it. Using Spring in an OSGi environment doesn't make things easier. You can use Spring Dynamic Modules to implement really cool OSGi applications, but your Spring load-time weaving support remains broken to some degree (see all the related questions in the Spring-DM forum).
I often thought about using Equinox Aspects to solve these problems. Since Equinox Aspects is not tightly bound to AspectJ weaving only, you could re-use the base infrastructure to hook any kind of bytecode modifier into the Equinox runtime - and reuse the caching of Equinox Aspects at the same time.

Now I have a first sketch implemented that bridges between Spring-LTW and Equinox Aspects. The EquinoxAspectsLoadTimeWeaver class implements the LoadTimeWeaver interface of Spring and can therefore be used in your spring context as the load-time weaver component:

<context:spring-configured>
<context:annotation-config>
<context:load-time-weaver
  class="org.eclipse.equinox.weaving.springweaver.EquinoxAspectsLoadTimeWeaver"/>

If you define this load-time weaver your bundle need to define an Import-Package on "org.eclipse.equinox.weaving.springweaver", of course.

To use this kind of load-time weaver definition to need to add "org.eclipse.equinox.weaving.hook" (from Equinox Aspects) to your target platform as well as "org.eclipse.equinox.weaving.springweaver":

• org.eclipse.equinox.weaving.springweaver_0.1.1.zip
  

When you launch your OSGi runtime you need to set the system property: (osgi.framework.extensions=org.eclipse.equinox.weaving.hook) and start the springweaver bundle right at startup. You can do this by adding it to the config.ini file (org.eclipse.equinox.weaving.springweaver@4:start). This is basically the same when using Equinox Aspects, except that you no longer start org.eclipse.equinox.weaving.aspectj but instead the springweaver bundle.

There are still some issues that need to be solved (see this comment in the spring forum for details), but I hope to can try it out and tell me what works fine and what needs some more work.

Feedback always welcome! Enjoy!

Load-Time Weaving for Spring-DM

Slides from OOPSLA 2008

The slides of my OOPSLA demo on Equinox Aspects are now online - together with those of my tutorial about Spring Dynamic Modules:

• Slides of OOPSLA-2008-Demo on Equinox Aspects (pdf)
• Slides of OOPSLA-2008-Tutorial on Spring Dynamic Modules (pdf)

Enjoy!

The slides of my OOPSLA demo on Equinox Aspects are now online - together with those of my tutorial about Spring Dynamic Modules:

• Slides of OOPSLA-2008-Demo on Equinox Aspects (pdf)
• Slides of OOPSLA-2008-Tutorial on Spring Dynamic Modules (pdf)

Enjoy!

Slides from OOPSLA 2008

New version of Spring Extension Factory available

When retrieving an OSGi service its good practice to use a timeout. Otherwise the operation could be blocked forever (in the case the service never appears). In past versions the Spring Extension Factory used a hard-coded timeout of 5 seconds. I chose this value more or less randomly, guessing that no bundle would hopefully need for than 5 seconds to create its application context. But I was proven wrong... :-)

Therefore I made the timeout setting configurable. Now you can define the timeout value (in milliseconds) via a system property called "org.eclipse.springextensionfactory.timeout". To set the timeout to 20sec, for example, start the JVM with this option:

-Dorg.eclipse.springextensionfactory.timeout=20000

I also added some more readable exceptions if no application context can be found or if the name of the bean to be used cannot be determined.

The new version can be downloaded from here:

• org.eclipse.springframework.util_1.0.3.zip

Thanks for reporting the problem, Matthias!

When retrieving an OSGi service its good practice to use a timeout. Otherwise the operation could be blocked forever (in the case the service never appears). In past versions the Spring Extension Factory used a hard-coded timeout of 5 seconds. I chose this value more or less randomly, guessing that no bundle would hopefully need for than 5 seconds to create its application context. But I was proven wrong... :-)

Therefore I made the timeout setting configurable. Now you can define the timeout value (in milliseconds) via a system property called "org.eclipse.springextensionfactory.timeout". To set the timeout to 20sec, for example, start the JVM with this option:

-Dorg.eclipse.springextensionfactory.timeout=20000

I also added some more readable exceptions if no application context can be found or if the name of the bean to be used cannot be determined.

The new version can be downloaded from here:

• org.eclipse.springframework.util_1.0.3.zip

Thanks for reporting the problem, Matthias!

New version of Spring Extension Factory available

Bugfix for Spring Extension Factory available

I fixed a problem that prevents the Spring Extension Factory (which I originally described in this post) to work for bundles with Eclipse-LazyStart set to true. The new version works for bundles with or without the layz start setting:

• org.eclipse.springframework.util_1.0.2.zip

Thanks for reporting the problem as well as a solution, Jimmy!

I fixed a problem that prevents the Spring Extension Factory (which I originally described in this post) to work for bundles with Eclipse-LazyStart set to true. The new version works for bundles with or without the layz start setting:

• org.eclipse.springframework.util_1.0.2.zip

Thanks for reporting the problem as well as a solution, Jimmy!

Bugfix for Spring Extension Factory available

Dependency Injection for Extensions, Third Edition

As you might have read from my previous posting I created an example that demonstrates the usage of Equinox Aspects as the load-time weaving engine for Spring Dynamic Modules. Now its time to describe this in more detail. :-)

My first idea behind this combination was to use the @Configurable annotation to use Spring's dependency injection mechanism for arbitrary objects which you typically don't create via the application context of spring. The default examples for this are plain domain objects, extensions are another example (they are typically created by the extension registry of Eclipse). Spring realizes the dependency injection for those objects by weaving an aspect into their classes. This aspect takes care of injecting the dependencies after each object creation. And this is the point where Equinox Aspects comes into play.

Fortunately Spring ships as a set of OSGi bundles. This is also true for "spring-aspects.jar", the JAR archive that contains the aspect that is responsible for making the @Configurable annotation work. And you can use Equinox Aspects to weave this aspect into your bundles wherever you would like to use the @Configurable extension. Sounds good, eh?

Ok, what do you need to do? Let’s go through the example step by step. First you need a target platform that contains the following:

• Your standard target platform (Eclipse 3.4 SDK, for example, if you develop RCP apps)
• The latest Equinox Aspects dev build (http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-downloads.php)
• The matching AJDT version (btw: you don't need the full AJDT installation within your target platform. "org.aspectj.runtime" and "org.aspectj.weaver" is all you need)
• Spring 2.5.5 bundles
• Spring Dynamic Modules 1.1.0 bundles
  

Now you have a class that would like to use @Configurable. In my example it is a view for an RCP application that looks somewhat like this:

@Configurable
public class View extends ViewPart {

 private Service service;

 public void setService(Service service) {
   this.service = service;
 }

 public void createPartControl(Composite parent) {
 ...

Then you define in the spring context of the same bundle the view as a spring bean, including the "service" property (the dependency that should be injected):

<bean class="org.eclipse.example.springdm.rcpview.View" scope="prototype">
  <property name="service" ref="myservice"/>
</bean>

<bean id="myservice" class="org.eclipse.example.springdm.rcpview.Service"/>

Take care to define the bean for the view as of scope "prototype". This is necessary to tell spring that this bean definition should be used as prototype for various instances.
Now we need to tell your bundle to be woven with the spring aspect. Therefore you just define the aspect bundle as required bundle:

Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
 org.springframework.bundle.spring.aspects

Now Equinox Aspects (if started correctly) weaves the aspect into your bundle wherever the @Configurable annotation is used. The next step is to tell the spring context that it should use load-time weaving and annotation configuration (plain old spring configuration for load-time weaving, nothing special here):

<context:spring-configured>
<context:annotation-config>
<context:load-time-weaver class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver">

This also requires some more import package statements within your manifest:

Import-Package: org.aspectj.lang,
 org.aspectj.runtime.reflect,
 org.springframework.instrument.classloading,
 org.springframework.beans.factory.annotation

The first two import statements are necessary because they are needed if an aspect gets woven into one of your classes. A more elegant solution for this would be to reexport those packages from the spring-aspects bundle, but they didn’t define the reexport in their manifest. Therefore you need to import them manually.
The last step is to take care of the startup sequence of your bundle. If the extension is created, your bundle should be activated to get the spring context created. This creation of the spring context should happen synchronously to ensure that the context is created when your extension object is created – otherwise the dependency injection would not work. Therefore I declare in the manifest:

Eclipse-LazyStart: true
Spring-Context: *;create-asynchronously:=false

If you would like to take a look at the complete example that I used, you can download it here:

• Dependency Injection for RCP-Views using Spring & Equinox Aspects (zip)
  

Feedback and questions are always welcome!

As you might have read from my previous posting I created an example that demonstrates the usage of Equinox Aspects as the load-time weaving engine for Spring Dynamic Modules. Now its time to describe this in more detail. :-)

My first idea behind this combination was to use the @Configurable annotation to use Spring's dependency injection mechanism for arbitrary objects which you typically don't create via the application context of spring. The default examples for this are plain domain objects, extensions are another example (they are typically created by the extension registry of Eclipse). Spring realizes the dependency injection for those objects by weaving an aspect into their classes. This aspect takes care of injecting the dependencies after each object creation. And this is the point where Equinox Aspects comes into play.

Fortunately Spring ships as a set of OSGi bundles. This is also true for "spring-aspects.jar", the JAR archive that contains the aspect that is responsible for making the @Configurable annotation work. And you can use Equinox Aspects to weave this aspect into your bundles wherever you would like to use the @Configurable extension. Sounds good, eh?

Ok, what do you need to do? Let’s go through the example step by step. First you need a target platform that contains the following:

• Your standard target platform (Eclipse 3.4 SDK, for example, if you develop RCP apps)
• The latest Equinox Aspects dev build (http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-downloads.php)
• The matching AJDT version (btw: you don't need the full AJDT installation within your target platform. "org.aspectj.runtime" and "org.aspectj.weaver" is all you need)
• Spring 2.5.5 bundles
• Spring Dynamic Modules 1.1.0 bundles
  

Now you have a class that would like to use @Configurable. In my example it is a view for an RCP application that looks somewhat like this:

@Configurable
public class View extends ViewPart {

 private Service service;

 public void setService(Service service) {
   this.service = service;
 }

 public void createPartControl(Composite parent) {
 ...

Then you define in the spring context of the same bundle the view as a spring bean, including the "service" property (the dependency that should be injected):

<bean class="org.eclipse.example.springdm.rcpview.View" scope="prototype">
  <property name="service" ref="myservice"/>
</bean>

<bean id="myservice" class="org.eclipse.example.springdm.rcpview.Service"/>

Take care to define the bean for the view as of scope "prototype". This is necessary to tell spring that this bean definition should be used as prototype for various instances.
Now we need to tell your bundle to be woven with the spring aspect. Therefore you just define the aspect bundle as required bundle:

Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
 org.springframework.bundle.spring.aspects

Now Equinox Aspects (if started correctly) weaves the aspect into your bundle wherever the @Configurable annotation is used. The next step is to tell the spring context that it should use load-time weaving and annotation configuration (plain old spring configuration for load-time weaving, nothing special here):

<context:spring-configured>
<context:annotation-config>
<context:load-time-weaver class="org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver">

This also requires some more import package statements within your manifest:

Import-Package: org.aspectj.lang,
 org.aspectj.runtime.reflect,
 org.springframework.instrument.classloading,
 org.springframework.beans.factory.annotation

The first two import statements are necessary because they are needed if an aspect gets woven into one of your classes. A more elegant solution for this would be to reexport those packages from the spring-aspects bundle, but they didn’t define the reexport in their manifest. Therefore you need to import them manually.
The last step is to take care of the startup sequence of your bundle. If the extension is created, your bundle should be activated to get the spring context created. This creation of the spring context should happen synchronously to ensure that the context is created when your extension object is created – otherwise the dependency injection would not work. Therefore I declare in the manifest:

Eclipse-LazyStart: true
Spring-Context: *;create-asynchronously:=false

If you would like to take a look at the complete example that I used, you can download it here:

• Dependency Injection for RCP-Views using Spring & Equinox Aspects (zip)
  

Feedback and questions are always welcome!

Dependency Injection for Extensions, Third Edition

Code Examples from "Aspect Weaving for OSGi" Talk

As promised, here are the projects of my live demos from "Aspect Weaving for OSGi" at last weeks Java-Forum-Stuttgart 2008.

• Eclipse Monitor Demo (zip)
• Dependency Injection for RCP-Views using Spring & Equinox Aspects (zip)

Eclipse Monitor Demo

This demo features the relatively old Eclipse Monitor application that Chris Laffra wrote a while ago. It visualizes plugin activities within your Eclipse application and you can analyze what is going on. This monitor uses Equinox Aspects to weave an aspect into all your bundles at load-time to gather the information of what is going on at runtime. It uses AspectJ advises for all methods and object creations. While this is a pretty heavy use of load-time weaving (you will notice a huge performance impact at first startup) it demos nicely the caching feature of Equinox Aspects. The second startup of your monitored app will perform very similar to a startup without any aspect weaving.

To run the example: Within your development environment you should have AJDT installed to work with AspectJ. In your target environment you should have included your favorite IDE (as example RCP app to monitor), the matching AJDT version, and the latest Equinox Aspects development build from here: http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-downloads.php. Notive: You need to install the latest dev build, not one of the archived builds. Once you have this you should be ready to run the example. Just import the projects in your workspace and use the included launch configuration.

Dependency Injection with Spring Dynamic Modules and Equinox Aspects

Spring provides this nice mechanism to inject dependencies in domain objects via the @Configurable annotation (see more here: http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-atconfigurable).
The main difference to general spring beans is that the creation of those domain objects is not done by the application context of Spring. Therefore Spring uses an aspect to call the application context after object creation to inject all necessary dependencies. In plain old Spring applications this aspect is woven into the system using load-time weaving.
Wouldn't that be a nice mechanism to inject dependencies into Eclipse extensions (like views or editors)? Just annotate your extension with @Configurable and define the dependencies to be injected inside the application context of your bundle (using the Spring Dynamic Modules stuff)?

One way of doing this is to use Equinox Aspects together with Spring Dynamic Modules. Just use the spring-aspects.jar from your spring distro (its already an OSGi bundle) and enable Equinox Aspects weaving - and you are done. It just works! :-)

To run the example: You don't need any special support within your development environment. Instead your target platform should be configured carefully. For the example projects I used Eclipse 3.3.2 as target platform, added AJDT, added the latest dev build of Equinox Aspects, Spring 2.5.4 bundles and Spring Dynamic Modules 1.1.0 bundles. Import the example projects from the zip file into your workspace and use the included launch config to run the demo. The example injects a spring bean into the view extension.

I will give more detailed information on how this Equinox Aspects weaving can be used together with Spring Dynamic Modules in an upcoming post.

If you observe any problems or if I forgot something in this description, please let me know.

Have fun with the examples!

As promised, here are the projects of my live demos from "Aspect Weaving for OSGi" at last weeks Java-Forum-Stuttgart 2008.

• Eclipse Monitor Demo (zip)
• Dependency Injection for RCP-Views using Spring & Equinox Aspects (zip)

Eclipse Monitor Demo

This demo features the relatively old Eclipse Monitor application that Chris Laffra wrote a while ago. It visualizes plugin activities within your Eclipse application and you can analyze what is going on. This monitor uses Equinox Aspects to weave an aspect into all your bundles at load-time to gather the information of what is going on at runtime. It uses AspectJ advises for all methods and object creations. While this is a pretty heavy use of load-time weaving (you will notice a huge performance impact at first startup) it demos nicely the caching feature of Equinox Aspects. The second startup of your monitored app will perform very similar to a startup without any aspect weaving.

To run the example: Within your development environment you should have AJDT installed to work with AspectJ. In your target environment you should have included your favorite IDE (as example RCP app to monitor), the matching AJDT version, and the latest Equinox Aspects development build from here: http://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-downloads.php. Notive: You need to install the latest dev build, not one of the archived builds. Once you have this you should be ready to run the example. Just import the projects in your workspace and use the included launch configuration.

Dependency Injection with Spring Dynamic Modules and Equinox Aspects

Spring provides this nice mechanism to inject dependencies in domain objects via the @Configurable annotation (see more here: http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-atconfigurable).
The main difference to general spring beans is that the creation of those domain objects is not done by the application context of Spring. Therefore Spring uses an aspect to call the application context after object creation to inject all necessary dependencies. In plain old Spring applications this aspect is woven into the system using load-time weaving.
Wouldn't that be a nice mechanism to inject dependencies into Eclipse extensions (like views or editors)? Just annotate your extension with @Configurable and define the dependencies to be injected inside the application context of your bundle (using the Spring Dynamic Modules stuff)?

One way of doing this is to use Equinox Aspects together with Spring Dynamic Modules. Just use the spring-aspects.jar from your spring distro (its already an OSGi bundle) and enable Equinox Aspects weaving - and you are done. It just works! :-)

To run the example: You don't need any special support within your development environment. Instead your target platform should be configured carefully. For the example projects I used Eclipse 3.3.2 as target platform, added AJDT, added the latest dev build of Equinox Aspects, Spring 2.5.4 bundles and Spring Dynamic Modules 1.1.0 bundles. Import the example projects from the zip file into your workspace and use the included launch config to run the demo. The example injects a spring bean into the view extension.

I will give more detailed information on how this Equinox Aspects weaving can be used together with Spring Dynamic Modules in an upcoming post.

If you observe any problems or if I forgot something in this description, please let me know.

Have fun with the examples!

Code Examples from "Aspect Weaving for OSGi" Talk

Reminder: Equinox Aspects at Java-Forum-Stuttgart 2008

This is just a friendly reminder that you have the chance to see Equinox Aspects live and in action at the upcoming Java-Forum-Stuttgart 2008 next week at the 3rd of July. I will give a talk at this nice conference in Stuttgart, Germany, about Aspect Weaving for OSGi. And the talk will be fully packed with a number of live demos including:

• Monitoring Eclipse with aspects
• Installing, updating and uninstalling aspects at runtime (dynamics for aspects)
• Using Equinox Aspects together with Spring Dynamic Modules

It will be really really cool, don't miss it! :-)

This is just a friendly reminder that you have the chance to see Equinox Aspects live and in action at the upcoming Java-Forum-Stuttgart 2008 next week at the 3rd of July. I will give a talk at this nice conference in Stuttgart, Germany, about Aspect Weaving for OSGi. And the talk will be fully packed with a number of live demos including:

• Monitoring Eclipse with aspects
• Installing, updating and uninstalling aspects at runtime (dynamics for aspects)
• Using Equinox Aspects together with Spring Dynamic Modules

It will be really really cool, don't miss it! :-)

Reminder: Equinox Aspects at Java-Forum-Stuttgart 2008

Slides and Examples from Spring-Dynamic-Modules-Talk at the OSGi Community Event 2008

Already more than a week ago I gave a talk at the OSGi Community Event 2008 in Berlin about the Spring Dynamic Modules project. Giving the talk was fun, I used a number of live demos to showcase Spring DM in action. The slides are now online:

• Talk: Spring Dynamic Modules by Example (pdf)
  

The code for all the demos can be found at the JAX blog entry of my colleque Gerd Wütherich, who prepared most of this talk. Thanks again for the great work, Gerd!

For those who are new to Spring Dynamic Modules: This project of the Spring portfolio basically allows you to use the Spring framework within an OSGi environment in a very nice and easy way. You can find more information on the Spring Dynamic Modules homepage.

Already more than a week ago I gave a talk at the OSGi Community Event 2008 in Berlin about the Spring Dynamic Modules project. Giving the talk was fun, I used a number of live demos to showcase Spring DM in action. The slides are now online:

• Talk: Spring Dynamic Modules by Example (pdf)
  

The code for all the demos can be found at the JAX blog entry of my colleque Gerd Wütherich, who prepared most of this talk. Thanks again for the great work, Gerd!

For those who are new to Spring Dynamic Modules: This project of the Spring portfolio basically allows you to use the Spring framework within an OSGi environment in a very nice and easy way. You can find more information on the Spring Dynamic Modules homepage.

Slides and Examples from Spring-Dynamic-Modules-Talk at the OSGi Community Event 2008

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

Slides from JAX 2008 Talks Available

So I am back from the JAX 2008 conference where I met people, gave a number of talks and listened to some other interesting presentations. The PDF versions of my slides are now available from the events section. Enjoy!

So I am back from the JAX 2008 conference where I met people, gave a number of talks and listened to some other interesting presentations. The PDF versions of my slides are now available from the events section. Enjoy!

Slides from JAX 2008 Talks Available

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:

• org.eclipse.springframework.utils_1.0.0.zip

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:

• org.eclipse.springframework.utils_1.0.0.zip

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

Recording of SpringOne Talk on Spring and Eclipse RCP

A complete video recording of the talk about Spring and Eclipse RCP that I gave at last years Spring One conference is now online at Parleys.com. Thank you guys for all the great work of recording all the sessions!!!

A complete video recording of the talk about Spring and Eclipse RCP that I gave at last years Spring One conference is now online at Parleys.com. Thank you guys for all the great work of recording all the sessions!!!

Recording of SpringOne Talk on Spring and Eclipse RCP

EclipseCon 2008

I am very happy to tell you that two of my proposed sessions are accepted for presentation at EclipseCon 2008 in Santa Clara. The first one ("Spring OSGi Reloaded") is an updated version of last years tutorial about the combination of Spring and OSGi technology (now called Spring Dynamic Modules for OSGi Service Platforms). And I am very happy to be part of the tutorial team consisting of BJ Hargrave, Adrian Colyer, Bernd Kolb and myself. The second one is a short talk about "Lessons Learned from Adopting The Eclipse Way" for general in-house software projects.

I am very happy to tell you that two of my proposed sessions are accepted for presentation at EclipseCon 2008 in Santa Clara. The first one ("Spring OSGi Reloaded") is an updated version of last years tutorial about the combination of Spring and OSGi technology (now called Spring Dynamic Modules for OSGi Service Platforms). And I am very happy to be part of the tutorial team consisting of BJ Hargrave, Adrian Colyer, Bernd Kolb and myself. The second one is a short talk about "Lessons Learned from Adopting The Eclipse Way" for general in-house software projects.

EclipseCon 2008