Playing with hooks is nice

As you may know, eclipse provides a set of non-OSGi standard ways to developers to intervene in the framework intricate internal lifecycle (that is, they work only with Equinox). The need I have is to modify the classes bytecode when they are loaded so that I can perform manipulations of my own (let's say AOP-transformations).

From Java 5 you can use the -javaagent:agent.jar option and provide an instrumentor you like. Sadly, I'm still hard to understand how it works (maybe I'm just plain stupid with such things): in my case I only wanted to add the AspectJ weaver but after this modification it complys it cannot find classes in the AspectJ runtime library. So I give up as I want the eclipse-way for doing such things (and to learn about eclipse internals).

The instructions on the wiki page are quite precise (geez!, this is a wiki :))), so I'm only writing about what I've done: maybe it will be helpful for you out there too.

1. I've imported the org.eclipse.osgi (binary+source) within my workspace, since this is a requirement for adaptors framework to work.
   
2. I've create a new fragment for org.eclipse.osgi.
3. I've written a HookConfigurator-derived class within this fragment and implemented the addHooks( HookRegistry registry ) method for adding my own hooks (Do not forget to export the package in the manifest file!).

   public class SpringHooksConfigurator implements HookConfigurator
    public void addHooks( HookRegistry registry ) {
     SpringInjectorHook springInjector = new SpringInjectorHook();
     
     registry.addWatcher( springInjector );
     registry.addClassLoadingHook( springInjector );
    }
   }
   

   (My hook implements both ClassLoadingHook and BundleWatcher interfaces).
   


4. I've created a hookconfigurators.properties files to specify the configurators (as explained in the wiki page, the framework will look for such files and load the specified hooks).

   ##
   ## Hooks configuration
   ##
   ## This files describes to Equinox which adaptor hooks are provided by this fragment.
   ## Note that we only provide a HookConfigurator that will add its own hooks by code.
   ##
   hook.configurators = it.uniba.di.cdg.spring.hooks.SpringHooksConfigurator
   
   
   

5. I've added the -Dosgi.framework.extensions option to the VM arguments and make it point to my own fragment.
   

Done. Have fun with your ... hooks :)

First International Conference on Eclipse Technology

On October 4/5 I attended to the event. As a community event, I'm pretty happy about such meetings: you can know about other people, their projects and possibilities of collaboration. The bad is that the community has no way to keep in contact efficiently: no mailing-list (geez, that is really a must!), no board (many directions, no direction) and not a real web-site. But the problems emerged clearly and something for addressing the situation is coming: let's hope in Google Group being established ;)
About the event per-se, several people from different subjects like universities and corporations have shown their eclipse-based projects: applications for supporting their interests (e-Learning anybody?), job (running test-cases on distributed environment without changing the core test or designing business processes) and research areas (eConference?) . The linking point is the Eclipse -platform: no theme grouped the speeches.

But:

• the event should have separated themes allocated for days (of part of days): experience reports, research areas and tutorials(there is a heck of need for them!)
• Keep the event focused on Eclipse
  
• the Java User Groups was quite out-of-place and their intervention subtracted time to the discussions about the future of community. This is sad since many talks (about JBoss Seam, i.e.) where really interesting (but not in an Eclipse event).

For what I understand, an Eclipse-based community has two crossing concerns:

1. Vertical application domain solutions: we are interested in a domain (eLearning, Business modeling, ...) and we should try to develop common solutions (there are a lot of frameworks in many domains being developed by the world-wide Eclipse community). In what is our national community different?
   
2. Horizontal infrastructure solutions: we want to improve systems by developing common reusable parts that can be shared across applications (I mean basic components that can be assembled to compose building blocks for new or existing applications)

So, many of this things are already addressed by the international community. What can the Italian one propose in addition? Ok, everyone of us can develop and contribute improvements to existing Eclipse frameworks as listed on eclipse.org: so why having a national one if we are going to contribute to the Grand WWW directly? I guess that the technological problem has no national boundary so, at the end, the objectives of the community become:

• to evangelize Eclipse Technology (open, cross-platform, already proven, ...): Eclipse is not only Rich Clients but also server-side technology, reporting tools, ...
  
• to share experiences in direct meetings (and since we are on nation-wide scale we should meet more than once a year!)
• to adapt Eclipse frameworks on Italian context (e-Government over Eclipse)
  

Spring Dynamic Modules for OSGi Service Platforms

Ok, start with the first (and most important) news: Spring-OSGi 1.0-M3 is out. What comes next is that it has changed its name to the one in the topic (Spring-DM, for friends). There are some issues yet in this milestone but the results are really usable for real applications. Ah, and leave out commons-logging and log4j: it is time to switch to SLF4J (1.4.3: leave 1.3.1 to its doom). It is OSGi friendly (contrary to log4j) and, I'm sure you will agree, It-Just-Works(TM).

So, enjoy you dynamic modules :)