As we count down the days until June 22nd — the day Eclipse Indigo will ship — I’ve been counting down the top 10 Indigo features, according to me.  In my previous article I talked about OSGi and how modularity plays a central role for all Eclipse projects.  With over 46 million lines of code and 62 projects, we could not ship on-time without a rock solid module system.  But modularity is not easy! Lucky for us Eclipse developers, Eclipse also ships with first class tooling for OSGi. For historical reasons this tooling is called the Plug-in Development Environment (PDE).

Number 8 on my top 10 list is the Improvements to PDE.

Target definitions allow you to manage your development-, package- and run-time dependencies and provision them from a variety of sources.  A number of improvements were made to the target management facilities.  In particular, you can now ‘update‘ your targets. This means that if you’ve defined your target in terms of p2 repositories, you can now instruct p2 to find ‘updated‘ versions of your dependencies. Also, the target facilities are now smart enough to use existing bundles that you already have on your machine.  Rid yourself of downloading the same artifacts, repeatedly.

You can also specify that ‘You want source with that‘ while crafting your target definition. This option will provision the associated ‘source‘ bundles along with the binary ones making it easier to browse the source of your development time dependencies.  Special thanks goes out to Jeff McAffer for this features and Curtis Windatt for reviewing the patches.

Finally, there were a number of improvements to API tooling — one of the most underrated Eclipse feature IMHO.  With Indigo you can now create consumer use reports. The standard report organizes the references by ‘producer’, that is, the bundle that produces the API.  Consumer reports organizes the references by ‘consumer’ or those bundles that ‘use’ the API.

Thanks to Curtis Windatt, Ankur Sharma, Darin Wright, Chris Aniszczyk, Jacek Pospychala and Benjamin Cabe.

When most people think about Eclipse they think of a kick-ass IDE. While this is true, Eclipse is so much more.  Did you know that Eclipse hosts a top-notch webserver (Jetty), a framework for building Rich Internet Applications (RAP), a Java persistence solution (EclipseLink) and a foundation for building multi-tier enterprise client / server applications (Riena).  In fact, there is an entire top level Eclipse project dedicated to Eclipse RunTime technologies.

The common tread that runs through almost all Eclipse projects is the highly modular component model and the OSGi runtime that enables it.  In addition to the OSGi runtime (Equinox), Eclipse also provides a powerful provisioning platform (p2) optimized for OSGi .  Number 9 on my Top 10 Indigo Feature list is the improvements to p2 and Equinox.

p2 has come a long way since it’s humble beginnings.  While p2 certainly had its share of growing pains, most people don’t realize that the entire Eclipse release process (and release train) would not be possible without p2.  The popular MarketPlace Client would have never functioned with the old Update Manager technology.  p2 has now matured to a stage where it just stays out of your way.

There are a few notable improvements to p2 this year including the ability to save your current Eclipse configuration:

and tag configuration states.  This should make it easier to try out new functionality and return to working state with ease.

Kudos for the import / export work goes out to Meng Xin Zhu.  Dean Roberts gets the shout-out for the tagging feature.  Special thanks goes out to DJ Houghton, Matt Piggott and Pascal Rapicault for improving the stability of the p2 platform and keeping our builds green.

The Equinox project also received some love this year. Tom Watson and John Ross continued to improve the framework and compendium service.  In particular, Equinox was updated to support the OSGi 4.3 specification. This includes a number of enhancements including new framework hooks, weaving hooks and generic capabilities.

If you use Eclipse to develop OSGi based applications you may use the OSGi Launcher provided by the PDE Tooling. It’s cool tooling because it gives you full control over the OSGi instance to be launched.  You can choose the OSGi framework (e.g. Equinox or Felix), select the bundles to install and much more.

But this launcher has one drawback that hurts every time I run across it. It appears when an OSGi application uses the OSGi HttpService. When you used this service you may have configured a port for it via the property “org.osgi.service.http.port” VM Argument.  I use this configuration all the time.

When I launch the application everything works fine the first time. But, during development I often come to the point where I need to relaunch the application. When I forget to kill the previous running instance I get a java.net.BindException because the address is already in use. So, to fix this I have to kill both instances and launch it again. This happens to me a lot just because I forget to terminate the previous instance. Of course this isn’t a bug because it’s often useful to launch a second instance of the same configuration. But, not when it comes to developing with the HttpService.

There is a fix now (though not necessarily for my forgetfulness ).  Luckily we live in a modular world in Eclipse. As a result, I was able to develop a separate bundle called the “OSGi Eliminator” (what a descriptive name ). The bundle contributes the functionality to automatically terminate a running OSGi Instance when you try to launch the same instance a second time. This functionality already existed in the RAP launcher created by Rüdiger Hermann. All I did was to refactor the functionality out to make it run in a separate bundle and contribute to the OSGi Launcher instead of the RAP Launcher. This solves an annoying problem for me – maybe for you as well?

You can find this bundle on GitHub. I also created a p2 repository that lets you install the OSGi Eliminator directly into Eclipse.

• p2 repository: http://hstaudacher.github.com/OSGi-launcher-enhancements/
• git repository on GitHub: https://github.com/hstaudacher/OSGi-launcher-enhancements

Tags: equinox, felix, GitHub, httpservice, OSGi, pde, rap, rtp

On Tuesday, Pascal and I presented “p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2” where we talked about the 10 most common pitfalls developers face when using p2. More importantly, we talked about how you can avoid them.

For those of you who attended the talk, thank-you.  I hope you learned something.  For those of you who could not attend, I’ve attached the slides here.

Tags: eclipse, equinox, OSGi, p2

Have you used p2?  Have you tried to replace plug-in with an updated version, only to find p2  doesn’t find it?  Have you removed an unused plug-in and suddenly Eclipse stopped working?

You’ve probably not only hit these issues, but as a responsible member of the Eclipse community you even filed a  bug about it, thanks.  Why then, did the p2 team close your bug as INVALID?

Join Pascal and I on Tuesday and learn about the 10  most common pitfalls Eclipse developers face when using p2; and more importantly, learn how to avoid them!

Tags: eclipsecon

In p2, if you’ve ever tried to write to the same artifact.xml (artifact repository) from two different processes, you will quickly learn that this fails. In fact, both processes will start corrupting each others data and you will likely end up with an unusable artifact repo. This limitation is of particular concern if you wish to use proper bundle pooling (a single bundle pool for all your Eclipse installs). Of course, you could implement your own bundle pooling technology, but I’ve set out to fix this at the p2 level.

Java synchronization obviously doesn’t work in this case because we are talking about multiple processes (multiple VMs). Instead, we need some mechanism to communicate the locking between Java VMs. File locking is one of the most used techniques in this case, and lucky for us, the reference implementation of OSGi (Equinox) provides a Data Location service which does exactly this.

Equinox Data Location, among other things, allows you to create a file location and acquire / manage / release a lock on that location. Equinox takes care of the platform oddities around doing all that (how do you create a file lock using Java Foundation 1.1 on Windows?). To demonstrate how this works, I’ve implemented the classic Dining Philosophers problem using Equinox’s Location service.

For those of you unfamiliar with the problem, essentially there are N philosophers and N forks around a table. Philosophers think and eat. When they want to eat, they first must first acquire both the fork on their left and right. When they’ve successfully done this, they can eat. Once they are done eating, then put the forks down and resume thinking.

In my solution, I represent each fork as a ‘Location’. A location can be created as follows:

private  Location getLockLocation(URI baseLocation, int locationNumber)
  throws IllegalStateException, IOException {
 
    Location anyLoc = (Location)  Activator.getService(Location.class.getName());
    URI locationURI = URIUtil.append(baseLocation, "" + locationNumber);
    Location location = anyLoc.createLocation(null, URIUtil.toURL(locationURI), false); //$NON-NLS-1$
    location.set(URIUtil.toURL(locationURI),false);
    return location;
}

This will create a location at ${baseLocation}/locationNumber

Each philosopher can create a location for the fork on their left and right. From here, implementing the solution is fairly easy:

try {
  thinking: while (foodLeft > 0) {
    // Wait and do some thinking
    Thread.sleep(getThinkingTime());
    while (true) {
      // Continue until you can acquire both forks.  We could 
      // sleep for a bit if we don't acquire both forks, but
      // we are pretty hungry here, and sleeping is never good
      // on an empty stomach 
      boolean leftFork = false;
      boolean rightFork = false;
      try {
        leftFork = acquire(leftForkLocation);
        rightFork = rightForkLocation.lock();
        if (leftFork && rightFork) {
          eat();
          continue thinking;
        } 
      } catch (IOException e) {
        // do nothing, we will release everything below
      } finally {
        if (leftFork)
          release(leftForkLocation);
        if (rightFork)
          release(rightForkLocation);
      }
    }
  }
} catch (Exception e) {
  e.printStackTrace();
}

In this solution, we wait until we acquire the fork on the left. However, we quickly release both locks if we cannot acquire the fork on the right.

/**
 * Blocks until a particular location can be locked
 */
private boolean acquire(Location l) throws IOException, InterruptedException {
  boolean lock = l.lock();
  if (lock)
    return true;
  while (true) {
    Thread.sleep(10);
    lock = l.lock();
    if (lock)
      return true;
    }
}

/**
 * Releases the lock on a particular location
 */
private void release(Location l) {
  try {
    l.release();
  } catch (Exception e) {
    // Do nothing
  }
}

I’ve put my solution to this problem on Github. Feel free to fork it (no pun intended).
https://github.com/irbull/com.ianbull.dining
In my solution, I’m actually not using multiple processes (and I’m sure there are other things that can be improved), but it should give you an idea of how to use the service.

Yesterday Amazon launched a new service called AWS Elastic Beanstalk. It’s basically a Tomcat hosting service. You can upload your WAR files via a web interface, to an instance of a Linux cloud image pre-configured with Tomcat. This is from the official Amazon description:

AWS Elastic Beanstalk is an even easier way for you to quickly deploy and manage applications in the AWS cloud. You simply upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. At the same time, with Elastic Beanstalk, you retain full control over the AWS resources powering your application and can access the underlying resources at any time. Elastic Beanstalk leverages AWS services such as Amazon EC2, Amazon S3, Amazon Simple Notification Service, Elastic Load Balancing, and Auto-Scaling to deliver the same highly reliable, scalable, and cost-effective infrastructure that hundreds of thousands of businesses depend on today. AWS Elastic Beanstalk is easy to begin and impossible to outgrow.

So, as an Eclipse guy the first question that comes to mind is, “Does OSGi/Equinox run on this?” I mean, it definitely should because we have the great Server-Side Equinox technology which we can deploy in a WAR file. So, I did a little experiment which everyone can repeat on his own. It took only 5 minutes to confirm that Equinox can run on Amazon’s Beanstalk. Here are the steps:

1. Create a Server-Side Equinox Application and package it into a WAR file. If you want to use an existing file I recommend that you download the rapdemo.war from the RAP Examples Demo. RAP Applications are basically Server-Side Equinox Applications with a UI.
2. Create an AWS Account and activate AWS Elastic Beanstalk. Follow the steps described in the AWS Management console.
3. Use the Web Interface to upload your example war archive. Don’t forget to check “Launch a new environment running this Application”.
4. After the upload is successful you have to wait a few minutes until the instance is started. When this is finished your application will be online and reachable under name-of-your-application.beanstalk.com. The example I deployed can be reached using this URL: http://eclipserap.elasticbeanstalk.com/

It was highly likely that Equinox was going to work on the beanstalk. But to be certain it works, is even better.  I can also say that I was really impressed by how easy it is to get a WAR file running on the beanstalk.  Just  two years ago, the only option you had to deploy a WAR file was to rent a (V)Server and set up Tomcat on your own. The question for me  now is how long it will take until the deployment of OSGi bundles will be so easy. Oh wait, there is Eclipse RTP…

Tags: amazon, beanstalk, eclipse, equinox, rap, rtp, server-side, tomcat

Terracotta is a transparent clustering service that allows multiple Java processes on different JVMs to work together using pure objects and threading logic. Here’s how you can use it with Equinox.

Prerequisites: An installation of Java 1.6.0u20 or later (Java SE Downloads) and Terracotta (Open Source Option) Terracotta Download..

Install the downloaded Terracotta:

> tar xvfz terracotta-3.3.0.tar.gz
> export TC_HOME=/opt/tools/terracotta-3.3.0

We wan’t Terracotta to integrate with Equinox. This is where Terracotta Integration Modules come into play:

Terracotta Integration Modules (TIMs) are sets of configuration elements and supporting Java classes packaged together as a single, includable module within the Terracotta configuration. A TIM allows you to integrate Terracotta DSO with the framework or platform that your application is based on.[1]

Let’s look how to include the TIM for Equinox 3.5.1 in the Terracotta configuration file $TC_CONFIG_HOME/tc-config.xml:

We create our own tc-config.xml in $TC_CONFIG_HOME based on a Terracotta sample configuration $TC_HOME/platform/samples/tc-config.xml. Add this snippet to the basic sample config:

Use the Terracotta helper tim-get.sh to install the TIM locally…

> $TC_HOME/bin/tim-get.sh install tim-equinox-3.5.1 1.2.0
Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3)
 
Installing tim-equinox-3.5.1 1.2.0...
   INSTALLED: tim-equinox-3.5.1 1.2.0 - Ok

Done. (Make sure to update your tc-config.xml with the new/updated version if necessary)
Now that we’ve configured the Equinox integration it’s time to tell Terracotta about our counter, a POJO:

public class Counter {
 
	private AtomicInteger counter;
 
	public int inc() {
		return counter.incrementAndGet();
	}
 
	public int getCurrentCounter() {
		return counter.intValue();
	}
}

Our Terracotta ‘application’ configuration holds the simple root object (graph) : A “root” is the top of a clustered object graph as declared in the Terracotta configuration.[2]

 
      com.eclipsesource.sovereign.terracotta.counter..*
 
      com.eclipsesource.sovereign.terracotta.counter.Counter.counter

Last we need a so called Terracotta “boot JAR”:

Some classes, however, are loaded too early in the lifecycle of the JVM for Terracotta to hook into their loading process. These are classes that are loaded by the boot classloader. Such classes cannot be instrumented at classload time, but must be pre-instrumented and placed in a special JAR file that is then prepended to the boot classpath.[2]

This is done with a Non-Standard Option of the JVM [3]

-Xbootclasspath/p:${TC_CONFIG_HOME}/boot JAR.jar

> $TC_HOME/platform/bin/make-boot-jar.sh -f $TC_CONFIG_HOME/tc-config.xml
2010-09-09 15:11:15,446 INFO - Terracotta 3.3.0, as ...
...
2010-09-09 15:11:27,456 INFO - Successfully created boot JAR file at ...
> cp $TC_HOME/lib/dso-boot/dso-boot*jar $TC_CONFIG_HOME

Enough installation and configuration. Engage! We need a running Terracotta server instance.

Terracotta server instances together form a Terracotta server array, which is the heart of a Terracotta cluster. Each Terracotta server instance performs two basic functions:[2]

• Cluster-wide thread coordination and lock management
• Clustered object data management and storage

> $TC_HOME/bin/start-tc-server.sh -f $TC_CONFIG_HOME/tc-config.xml
2010-09-09 15:34:42,370 INFO - Terracotta 3.3.0, as of ...
2010-09-09 15:34:55,915 INFO - Terracotta Server instance has started up... successfully, and is now ready for work.

What’s a server without a client? We fire up the Equinox client with Pax Runner with some additional JAVA_OPTS:

> export JAVA_OPTS=-Dtc.install-root=${TC_HOME} -Dtc.config=${TC_CONFIG_HOME}/tc-config.xml -Xbootclasspath/p:${TC_CONFIG_HOME}/dso-boot-hotspot_linux_160_21.jar

One configuration file contains our counter OSGi bundle etc/counter-demo.pax:

mvn:com.eclipsesource.sovereign/terracotta.counter/0.1.0-SNAPSHOT

The second specifies platform, version, inProcess executor, bootDelegation, …

--platform=equinox
--version=3.5.1
--executor=inProcess
--bootDelegation=sun.*,com.sun.*,javax.xml.*,javax.xml.transform.*,...
--systemPackages=javax.naming, javax.naming.directory, javax.naming.spi, ...

>$PAX_RUNNER_HOME/bin/pax-run.sh etc/counter-demo.pax --args=file:etc/runner.args
2010-09-09 17:14:23,435 INFO - Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3)
2010-09-09 17:14:24,794 INFO - Successfully loaded base configuration from file at...
2010-09-09 17:14:30,101 INFO - Connection successfully established to server at ...
__________                 __________
\______   \_____  ___  ___ \______   \__ __  ____   ____   ___________
 |     ___/\__  \ \  \/  /  |       _/  |  \/    \ /    \_/ __ \_  __ \
 |    |     / __ \_>    <   |    |   \  |  /   |  \   |  \  ___/|  | \/
 |____|    (____  /__/\_ \  |____|_  /____/|___|  /___|  /\___  >__|
                \/      \/         \/           \/     \/     \/       
 
Pax Runner (1.4.0) from OPS4J - http://www.ops4j.org
 
----------------------------------------------------
...

Review the first lines showing that the Terracotta client successfully estalished it’s connection to the server. If those lines are missing please double check the path to your “boot JAR”.

We added some OSGi commands to interact with our clustered POJO counter:

osgi> help
...
---Sovereign counter commands---
	inc - increment the global counter
	currentValue - show current counter value

osgi> inc
4
 
osgi> currentValue
4

Start another application and have fun with the clustered counter….

Sources:

[1] Terracotta Integration Modules Manual
[2] Concept and Architecture Guide
[3] Java SE Documentation – Java – the Java application launcher

Tags: equinox, terracotta