Eclipse Yoxos Services Downloads Blogs About
Home > Blogs >

Posts Tagged ‘equinox’

on May 4th, 2011Launch an OSGi app and automatically kill its running instance

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.

bindException Launch an OSGi app and automatically kill its running instance

There is a fix now (though not necessarily for my forgetfulness icon wink Launch an OSGi app and automatically kill its running instance ).  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 icon smile Launch an OSGi app and automatically kill its running instance ). 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.

on Mar 23rd, 2011p2, 10 common pitfalls and how to avoid them

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.

on Feb 7th, 2011How to build a Server-Side Equinox/RAP Application

RAP Logo small How to build a Server Side Equinox/RAP ApplicationWhen you face the task of building a Server-Side Equinox or a RAP application (which is just a Server-Side Equinox application) you need to choose a build system from a fairly diverse palette. This choice is never easy because every build system has its pros and cons. In the end it comes down to which one you and others, love or hate.

To make this task a little easier we created a small github project called “RAP build examples”. It provides examples of how to build a RAP application with different build systems. Currently the following systems are covered:

PDE Build:

The goal of PDE Build is to facilitate the automation of plug-in build processes. Essentially, PDE Build produces Ant scripts based on development-time information provided by, for example, the plugin.xml and build.properties files. The generated Ant scripts, can fetch the relevant projects from a CVS repository, build jars, Javadoc, source zips, put everything together in a format ready to ship and send it out to a remote location (e.g., a local network or a downloads server). read more…

Tycho:

tycho logo How to build a Server Side Equinox/RAP ApplicationTycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles. Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGi bundles with Maven. Eclipse plugins and OSGi bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. read more…

WAR Products Tooling:

The WAR Products are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. read more…

All the examples in the git repository follow the same pattern. They provide a simple RAP Application (the famous mail demo) and the files you need for the build. You can read the instructions on how to run each build in the README file which is provided for every example. For those of you who are not using git we’ve also created a zip file which contains the whole repository. You can download it here.

We plan to extend the examples in the future. A Buckminster example is on its way shortly. If you have experience with other systems please feel free to leave a comment and we can create an example together.

on Feb 2nd, 2011Equinox/RAP WAR Products has moved. Hello Eclipse Libra…

A while ago I introduced you to my Google Summer of Code 2010 project, the WAR Products. I really appreciate your participation with feedback and bugs. It showed me that there is a real need for this tooling, so I’m proud to announce that the WAR Products development will not continue in the RAP Project.

You may think, “WTF? Odd thing to be proud of.” But, it really does make sense icon wink Equinox/RAP WAR Products has moved. Hello Eclipse Libra... . The WAR Products were never targeted to be part of RAP, primarily because the tooling is not RAP specific. It eases the deployment of Server-Side Equinox applications. And this kind of application does not necessarily have to be a RAP application.

Three months ago a new Eclipse project was announced. It’s called Libra or formerly “OSGi Enterprise Tools” (it had to be renamed ‘Libra’ because of legal issues). I don’t want to repeat the project goal here because Kaloyan (the Libra project lead) does a much better job with this than I could. You can read about the project in this proposal. Libra passed the project creation review a while ago and provisioning by the eclipse.org webmasters is ongoing. So, why am I talking about Libra here?

wtp logo 2010 Equinox/RAP WAR Products has moved. Hello Eclipse Libra...There is a simple reason.  Because of one sentence from Kaloyan about Libra, I thought it would be the perfect project to contribute the WAR Products to.  “Libra tries to close the gap between PDE and WTP”.  This maps exactly to the WAR Products as the tooling tries to ease the deployment of Equinox-based applications on Servlet-Containers or JavaEE Application Servers.

Additionally there are plans to extend the tooling with a WTP integration to enhance the creation of a WAR Archive with automated deployment functionality, without adding explicit dependencies to WTP. And where can this development be done better than in between PDE and WTP?

Yesterday I committed the WAR Products to the Libra git repository after it passed the IP process successfully. I also set up a temporary p2 repository from which you can install the tooling (Eclipse 3.7 M4+ required). Of course we’re trying to push Libra in the direction of Indigo. If this works you will soon be able to install the WAR Products from the Indigo Repository. Please keep in mind that the bundle ID’s have changed during the move. So, if you had installed the sneak-preview from this blog post, please uninstall the tooling before installing the Libra version. It’s really worth getting the new version because of many bug fixes and enhancements which are included. Please feel free to file bugs, but this time against Libra icon wink Equinox/RAP WAR Products has moved. Hello Eclipse Libra...

Please note: To use the WAR Product’s full functionality you need to add the Equinox Server-Side SDK to your target or set RAP 1.4 M5 as your target environment. There is no longer a “requiredBundles.zip” that you need. Use this temporary p2 repository to install the WAR Products: http://download.eclipsesource.com/~hstaudacher/warproducts/3.7/

on Jan 20th, 2011Amazon AWS Beanstalk and Eclipse Equinox

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 Amazon AWS Beanstalk and Eclipse EquinoxAWS 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”.beanstsalkUpload Amazon AWS Beanstalk and Eclipse Equinox
  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

on Dec 15th, 2010How do you run your RAP application today?

Hi,

We’d like to know more about RAP in the wild. Please take a moment and answer the question that follows below. We will publish the results of this anonymous poll later on this blog, and we’ll use them to influence the direction of the research work of the Sovereign project.

Thanks for your time.

How do you run your RAP application today?

Create an online survey quiz or web poll

on Dec 8th, 2010Introducing the Eclipse RTP Project

Today’s a great day. The Eclipse Foundation accepted the proposal for the RTP Project. RTP stands for Runtime Packaging.  And here’s what it’s all about.

Marcus Baker wrote an article called “Install Me“, which was published in the book “97 things a programmer should know“. On two pages he shows the reader exactly how important the first minutes are when a new user tries to get familiar with your software. He argues that it is the responsibility of  the software developer, to make it as easy as possible for the user to see that your software is what he needs.

EclipseRT Introducing the Eclipse RTP Project

Currently we don’t do a good job with this at EclipseRT. There are several EclipseRT technologies out there and every one provides an individual starting point for new users. From my point of view, changing this would bring EclipseRT a big step further.

That’s the inspiration behind the RTP project.  All that a user should have to do is download – install – run. The idea is to create one or more common starting points that new users can use to get familiar with EclipseRT technology.  Once we have the installation accomplished, we’ll have to convince the user with good examples and documentation. Investigation shouldn’t take more than 5 minutes. If the user doesn’t see what he needs in his first five minutes, the software will not get a second chance. There is also the chance of course, that the annoyed user might spread the word that the software doesn’t do the job right.  So, its definitely worthwhile to invest in keeping new users happy.

And this is what RTP is all about:  working with as many EclipseRT projects as possible to provide a really good out-of-the box experience for new users. If you are interested in this project please let me know. We welcome all help towards succeeding with RTP. If you want to learn more about RTP there are also two EclipseCon 2011 submissions (submission 1, submission 2) you can read.

on Sep 13th, 2010Distribute objects with Terracotta and Equinox

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

on Aug 17th, 2010Equinox/RAP WAR deployment: an end to the pain

Please note: This post is outdated. Please read this post and do not follow the install instructions in this one.

A few weeks ago I presented you my GSoC 2010 project. The idea was to make Equinox/RAP WAR deployment easier. And yes, it was a real pain to create .war files for an Equinox/RAP application. About 215 deployment related threads on the RAP newsgroup speak for themselves. But the pain is over now, and I think I can say,  “Mission accomplished”.

I want to introduce you to a new concept called WAR Products. They are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. If you don’t believe me,  watch the screencast below and see for yourself.

You can use the tooling right now, but please keep in mind that we are still polishing. The final goal is to contribute it back to PDE, but there are still a few things to do before we make the contribution.  One of those items is to get your initial feedback so when you use the WAR Products tooling, please be sure submit your feature requests or file bugs and help us to continue to improve the tooling.

Here is what you need to do to use the WAR Products tooling:

  1. Install the tooling from this repository into your IDE: http://download.eclipsesource.com/~hstaudacher/warproducts/3.7
  2. Set up your target. You need to add RAP 1.4 M5 or the Server-Side Equinox SDK.

Again, comments, bugs and feature requests are appreciated!

At this point I want to thank some people. First of all, Rüdiger Herrmann for great mentoring and the whole RAP team for all the nice evenings in the beer garden. Not to forget Simon Kaegi, Scott Lewis and Chris Aniszczyk and the rest of the Equinox and PDE teams for tuning up the Product concept. Your changes made things much easier.

And, I hope that you will find WAR deployment and creating WAR Products not just easier, but completely pain free!

on Jul 16th, 2010Helios DemoCamp Darmstadt review

Two days ago was the Helios DemoCamp in Darmstadt at Deutsche Telekom.  I think it was a very successful evening with a whole bunch of good talks. Two of them are very noteworthy.

The first one was presented by Marcel Bruch. He talked about the Eclipse Code Recommenders project which he’s working on at TU Darmstadt. The basic idea behind this project is to provide a way to recommend code. He used the analogy of the Amazon online store. When you buy a book you always get a recommendation along the lines of, “People who bought this book also found this one interesting…”. The Code Recommenders does exactly the same just with code.  Watch the great screencast the Code Recommenders Team provides if you don’t want to take my word for it.

marcel 2 150x150 Helios DemoCamp Darmstadt review marcel 1 150x150 Helios DemoCamp Darmstadt review

Another especially noteworthy demo for me was presented by Stefan Lay. He demo’d the Eclipse Git Team provider called EGit.  In addition to the tooling he presented Gerrit. Gerrit is an automated review tool for Git. The scenario he presented was to push some changes to a remote repository. The changes were caught by gerrit to be reviewed.   With those changes however, an automated build failed and gerrit sent an automated message that the changes couldn’t be applied because they broke the build. I think this will make the workflow much easier for code review and keeping the repository stable. The EGit project already uses Gerrit for their productive work.

Lay 1 150x150 Helios DemoCamp Darmstadt review Lay 2 150x150 Helios DemoCamp Darmstadt review

To put it all in a nutshell it was a very cool DemoCamp with 120 attendees and nice buffet afterwards. At this point I want to thank Ralph Müller and the Foundation who organized a spontanous Eclipse Stammtisch after the DemoCamp. It was great to talk to all the guys individually. The bad thing about this is that the evening went by too fast. But there also a good thing. Most of those people will also attend the Eclipse Summit Europe in November and we can meet again.

stammtisch 2 150x150 Helios DemoCamp Darmstadt review stammtisch 1 150x150 Helios DemoCamp Darmstadt review
© EclipseSource 2008 - 2011