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 :)

A new laptop

Until now, I've resorted to use VMWare to have a Windows XP virtual system under my kubuntu box and run Office applications within it (paper templates and slideshows like those proprietary formats ...). Now, I have a new laptop I will use for this job only. So, a Linux box for development, a Windows laptop for presentation.

Let's how they will play together.

Spring-OSGi hello world application

The problem

OK, I need dependency injection in my cool Eclipse/OSGi applications. I plan to wrap actual Platform{UI].get*(..) method within Spring-OSGi service beans (that is, Spring beans exported as OSGi services). I want my n-tier applications to communicate through services. Ad I want them to add new features and update existing ones on the fly.

So I downloaded the actual sources, built them and copied all the jars in a directory which I made as additional extension to the JDT. This is good for me since I can play with Spring-OSGi from within eclipse without bothering with maven stuff (maven-eclipse integration is not helpful here).

I created a sample "Hello world" bundle which publishes the spring beans (one implementing a salute in Italian, the other in plain English) and an OSGi Greeter service that could be user by other services.

Spring-OSGi hints

A few things must be remembered:

• You can have bundle-scoped beans (they are only visible within the application context associated to that bundle and no else!)
• You can publish some beans as OSGi services (so making them available to the other bundles through the usual OSGi mechanisms, such as the service trackers).
• You must put your XML files declaring the application context under META-INF/spring directory in your project classpath: *.xml files will be loaded automatically by the Spring Extender service.
• The Spring Extender bundle must be activated as early as possible in your application's start-up and you cannot use the beans in the BundleActivator.{start,stop} lifecycle methods (the extender will take sometime to load the xmls and publish beans/services)
  

Keeping this in mind, we have all the usual Spring and OSGi concepts merged together :)

A last question: what is the minimum set of bundle for such a minimal application (no databases, no GUI, just plain OSGi+Spring+Console output) ? Here they are:

id    State       Bundle
0      ACTIVE      system.bundle_3.2.2.R32x_v20070118
163    ACTIVE      org.aopalliance_1.0.0
164    ACTIVE      org.apache.commons_logging_1.0.4.v200608011657
168    ACTIVE      org.aspectj.runtime_1.5.4.200701151324
169    ACTIVE      org.aspectj.weaver_1.5.4.200701151324
203    ACTIVE      org.springframework.osgi.backport-util-concurrent_3.0.0.SNAPSHOT
208    ACTIVE      org.springframework.osgi.spring-aop_2.0.5.osgi_m3_SNAPSHOT
209    ACTIVE      org.springframework.osgi.spring-beans_2.0.5.osgi_m3_SNAPSHOT
210    ACTIVE      org.springframework.osgi.spring-context_2.0.5.osgi_m3_SNAPSHOT
211    ACTIVE      org.springframework.osgi.spring-core_2.0.5.osgi_m3_SNAPSHOT
212    ACTIVE      org.springframework.osgi.spring-osgi-core_1.0.0.m3_SNAPSHOT
213    ACTIVE      org.springframework.osgi.spring-osgi-extender_1.0.0.m3_SNAPSHOT
214    ACTIVE      org.springframework.osgi.spring-osgi-io_1.0.0.m3_SNAPSHOT
219    ACTIVE      org.springframework.osgi.spring-osgi-mock_1.0.0.m3_SNAPSHOT

Obviously more will be needed for transactions and persistence frameworks. But for now I'm satisfied since I've breached within this new world!

Next steps

• testing (unit and integration practices)
• smoothing out the code and find the right time when to use the published services (for now I just use the service in a addingService() implemented in a custom service tracker of mine.

Mocking with EasyMock

Until now I've been using JMock (currently 1.1) for creating mock objects in my unit tests. Yesterday a decided to give a try to EasyMock (currently 2.2) and ... I must say that I like it very much its approach and will continue to use it, probably switching from JMock (but this I can't say for sure at this point). So I will share some first thoughts about it.

What I liked more about EasyMock is the ease when creating mocks without much hassle. For example I had a test written in this way:

/**
 * Check that proxy works when on-demand instantiation creates
 * an object which implement the right interface.
 */
public void testProxyWorksOk() {
  Mock mockCfgElement = mock( IConfigurationElement.class );

  mockCfgElement.expects( once() )
          .method( "createExecutableExtension" )
          .with( eq( ExtensionsProxyFactory.CLASS_ATTR ) )
          .will( returnValue( new ProxyWannabe() ) );

  IProxyWannabe proxy = proxyFactory.getProxy(
              IProxyWannabe.class,
              (IConfigurationElement) mockCfgElement.proxy() );

  assertEquals( 0, proxy.getDummy() );
  proxy.costlyMethod1();
  assertEquals( 1, proxy.getDummy() );
  assertNotNull( proxy.costlyMethod2() );
}

This uses the typical JMock-pattern for writing expectations using some kind of specific API for testing (expects( once() ).method( "" ) ...). Typically what you would do is:

1. Write the expectation(s) for your mock object (what methods are to be called, with which parameters and what values are to be returned).
2. Get an object implementing the interface you want your object to be tested with.
3. Run the method you want to test with this mock.
   
4. Verify the expectations.

With JMock verification is automatically performed at the end of the method. But the biggest problem here is the passing of the expected method as a string: this is going to give some headache in case of refactoring (something that is going to happen often when acting in a test-driven way). Also the way of passing parameters seems a bit bloated ( with( eq( ... ) )... ).

The same test with EasyMock becomes:

public void testProxyWorksOk() throws Exception {
  IConfigurationElement mockCfgElement = createMock( IConfigurationElement.class );

  expect( mockCfgElement.createExecutableExtension( ExtensionsProxyFactory.CLASS_ATTR ) )
                  .andReturn( new ProxyWannabe() );
  replay( mockCfgElement );

  IProxyWannabe proxy = proxyFactory.getProxy( IProxyWannabe.class,  mockCfgElement );
          
  assertEquals( 0, proxy.getDummy() );
  proxy.costlyMethod1();
  assertEquals( 1, proxy.getDummy() );
  assertNotNull( proxy.costlyMethod2() );

  verify( mockCfgElement );
}

You will notice:

• The mock factory method returns an interface compatible with the one we want to mock (IConfigurableElement, in this case): JMock creates a proxy object (instance of type Mock).
• Writing the expectation is pretty straightforward (and less bloated).
• Verification must be performed explicitely.
  

Additionally, you test-cases classes can only inherit from the usual JUnit's TestCase base class while with JMock you must inherit from MockObjectTestCase (not shown here). This is because EasyMock uses static imports from Java 5.0 (and so it can't be used with older JDKs ).

Some resources for the ones who have lived in Outer Space and don't know about mock objects:

• Mock roles, not objects.
• Mock objects patterns.
• MockObjects.com.
  

Let's see how JMock2 will cope with the challenge ...

Some OSGi links

Just some references to interesting links related to OSGi stuff.

• Alex Blewitt's presentation at JSig (Alex is a very active poster on Eclipse Zone).
• Best Practices for Programming Eclipse and OSGi is a nice presentation from the EclipseCon 2006. Most interesting is the comparison among the OSGi services and Eclispe Extensions.
• A parley from Costin Leau (from the Spring Framework project) about the Spring-OSGi project. Very interesting for the future OSGi R5 specifications.

Lastly but not least, I've found a parley from Ramnivas Laddad about DDD and AOP: really enjoyed it!

A new life for this blog

Yeah, this blog has been resurrected! I will use it mainly for posting interesting (I hope!) stuff about my research along the Collaborative Development Group where I'm attending my Ph. D. course.

For the people who doesn't know about: I'm back in Brindisi after my brief transfer in Rome (less than 6 months!) and now work for the United Nations International Computing Center (cool name, eh?).

The good:

• I work at just 5(!) minutes from home!
• It is a well paid job (much more than current italian salaries ...)

The bad:

• It's a .NET-everywhere ecosystem
  
• It will last until 20 July 2007 :|