This post will go through a simple example of how to add your own bundles to your Equinox application at build time.

First, let’s return to the workspace that we setup as described in the first post in this series.  Here’s what the workspace should look like after completing steps 1-4 of the first post:

To add sets of bundles to the target application server, we create a new feature for grouping the bundles.  A feature project is created through the new project wizard via menu selections New Project->Other…->Plugin Development->Feature Project.  I’ve created a new empty feature called com.mycompany.myappserverfeature, but it can be called anything you like:

Then choose the Plug-ins (otherwise known as bundles) tab in the feature editor and you can add bundles to be included in your new feature.  The bundles that appear in the dialog when selecting Add… will include all the bundles in your workspace, as well as all bundles currently included in your target platform.  For a description of how to add to your target platform, and an explanation of what you can do with the target platform since Eclipse 3.5 please see the Improved Target Platform Management blog post.

I’ve also added some bundles in my target platform that support doing ECF remote services with the r-OSGi provider.   This enables support for remote OSGi services between application servers (i.e., having one server call a remote OSGi service exposed by another server).

After adding the bundles you wish to include, save the changes to your feature and then add your new feature to the equinox-milli.product. Features can be added to the equinox-milli.product on the Dependencies tab of the equinox-milli.product editor.

Here’s the Feature Selection dialog that appears when you select Add… on the Dependencies tab:

And then you will see your com.mycompany.myappserverfeature listed as part of the equinox-milli.product:

Save the changes to the equinox-milli.product and then you can go to product editor Overview tab, select the Eclipse Product export wizard (in lower right of Overview tab) to display the export wizard dialog:

You can now click Finish and do exactly the same things as described in steps 6, 7, 8, 9 in the original post to create a zip file (e.g., named myappserver.zip), rename it to myappserver.war and then hot deploy the new war file to your servlet container of choice to run it.

Once running, at the osgi> prompt you can convince yourself that the added bundles are now present in your application server by typing ss and looking for the bundles added by your feature in the resulting list:

As you can see, these bundles are in place and ready to use from within your web applications!

d) The Generate metadata repository should be unchecked

If using p2 (as in this post), this is incorrect.  It should say

d) The Generate metadata repository should be checked (to include p2 metadata)

I’ve updated this documentation in the original posting.

Once your p2-enabled app server is running, you can do some really cool things with it.  For example, since p2 is available, you can dynamically install new components into your running application server.  Here’s the OSGi console help output (part of it anyway):

Notice the Provisioning Commands text.  These are console commands enabled by the presence of p2 that allow you to do common provisioning operations like installing new components.  In this blog entry, I’ll show how to install a version of the Knoplerfish httpconsole, but the same approach applies to software available from other p2 repositories.  In other posts, the EclipseSource team will show how to do this hot deployment into a running server for:

• RAP
• ECF
• Other EclipseRT Project components

First, one must add the metadata and artifact repository URIs using the provaddrepo and provaddartifactrepo commands:

Notice the provlg command, which lists the p2 groups available in the newly added repositories (in this case, the Knopplerfish httpconsole v2.0.0).  Now, issue the provinstall command with the feature group and version… wait a few seconds and you should see the install complete message

Then issue the confapply command (this command applies the new bundle configuration to the currently running platform):

Now, you can see the new bundle installed via the short status (ss) command:

To start the httpconsole bundle (and activate the servlet that it runs) just type start 50.

At this point, you can open a web browser, and point it at your Equinox application server now running the httpconsole at http://localhost:8080/myappserver/console and magic…your application server is now running the Knoplerfish httpconsole servlet, which provides a web interface to the list of running bundles:

Just for fun, you can stop the httpconsole with stop 50 and the servlet will no longer respond

You can start it back up, and then the servlet will be running again. This makes a nice demo for people that have to manage the install and update of new components into a running application server. In future posts, I’ll show how to add features to your application server statically (during the build, rather than at runtime) as well as how to use ECF remote services to manage a running application server without having to use the OSGi console.

Enjoy!

• ECF
• RAP
• P2
• PDE
• Equinox
• EclipseLink
• Riena
• Smila
• eRCP

There’s a lot more to come, for example, ECF’s work on supporting Google Wave server protocol as well as commercial technologies from EclipseSource and other technology companies devoted to the OSGi stackless stack.

However, in my opinion it’s far more difficult to build, deploy, configure and run an Equinox server than it should be.  There is existing documentation on doing so from scratch here, but it is a little dated.  I am contributing to the Equinox project to get the documentation updated with community help.

So, I would like to do a short set of blogs about building your own Equinox-based application server.  Hopefully this will be helpful to those who are interested. It’s possible to create two ‘kinds’ of Equinox-based application servers. Those that are actually run stand-alone (i.e., as a Equinox OSGi application) or those that are run within an existing servlet container such as Jetty or most commercial application servers.  For this series, I’m going to focus on the servlet container method as I think this will ultimately be the more common and popular method. Furthermore, servlet containers now make deployment, installation and configuration very easy (which goes a long way toward my goal).

Ok, so how to create an Equinox-based application server?  Well, with the Eclipse Galileo PDE build, p2, features, and products, it turns out it’s now very easy to do so (compliments to the particularly to the folks who worked on PDE, Equinox, and P2 in this area).  I’ve created a simple feature and product that does so and contributed them to this bug.  Here are the steps:

1) Download the zip attached to bug 245267

2) In Eclipse, open a new workspace and import the projects from the downloaded zip (File->Import…->Existing Projects in Workspace->Select Archive File).  This will put two very small projects into your workspace

3) There are two other projects (from Equinox CVS area) required before you can create your app server.  To add these projects right click on the equinox-servletbridge.psf file and select Import Project Set…  from the menu (use anonymous CVS login when prompted).  Now you should have four projects in the workspace

4) Now, open the PDE product editor by double clicking on equinox-milli.product file

5) Select Eclipse product export link in lower right of product editor

6) In the export wizard dialog set the following fields

a) The Root Directory field must be set to:  WEB-INF

b) The Synchronize before exporting check box can be unchecked

c) The Destination must be set to Archive file, and given a location/name of your choosing (e.g. myappserver.zip)

d) The Generate metadata repository should be checked (to include p2 metadata)

e) Click Finish

This will run PDE build and create a zip named (in the above case): myappserver.zip

6) Now comes the fun part.  Simply rename this zip file to a .war…i.e. myappserver.war

7) Start your servlet container (in this case I’m using tomcat)

8) Hot deploy the war file (in this case myappserver.war) in the manner appropriate for your servlet container (in tomcat’s case this is copying the myappserver.war file into the webapps directory).  After a few seconds, you should see something like the following output to the tomcat console…with the nice little osgi> prompt, indicating your Equinox server is deployed and running!

9) Give some OSGi console commands with the osgi> prompt just to convince yourself everything is working…e.g.

10) Go show your colleagues how easy it was to create, deploy and run your Equinox application server!

There’s a lot more that you can now do with your Equinox application server like:

• Adding servlets (via bundles)
• Using P2 to update your application server
• Creating your web applications in a modular fashion using bundles and features
• Reuse your favorite bundles from Eclipse or other projects
• Deploy and maintain your web application as bundles (and using PDE to do it)

In the future, I’ll describe how to do some of these things.

If people are interested in particular things to do, please comment and let me know.

In addition to demonstrating the power of combining DS with ECF 3.0′s support for distributed OSGi services, the tutorial has two other very cool aspects:

• It was created by a community member after using these technologies to build their own system
• The tutorial will soon be contributed to the ECF documentation section available in the ECF wiki area

Enjoy!

Netflix Competitors Learn the Power of Teamwork

I was particularly fond of this quote:

The biggest lesson learned, according to members of the two top teams, was the power of collaboration. It was not a single insight, algorithm or concept that allowed both teams to surpass the goal … Instead, they say, the formula for success was to bring together people with complementary skills and combine different methods of problem-solving

I think it provides an excellent example of the benefits received due to open collaboration (with distributed, diverse teams). Furthermore, I think it identifies a powerful and sustainable value creation and commercialization approach for open source projects.

What do you think? I think Eclipse does some of this already, but how can we improve things?

Chrome vs. Bing vs. You and Me

Cringley implicitly asserts that neither Google nor Microsoft are going to innovate in the interest of You and Me and sadly, I think this is all-to-often true in ‘big-time, big-money’ corporate software.

First and formost, companies are interested to achieve ever higher ROI for their shareholders. This does not necessarily mean that they will build anything of value for You and Me.   They may innovate and that’s terrific when it happens. However, if they can make more money by attacking each other and protecting their existing turf… I think it’s pretty clear they will frequently do so.

In my view, this points directly at a long-term sustainable role for open source and startup ecosystems:  end-user-focused innovation.  Of course, as Bjorn Freeman-Benson points out, end-user focus can be a challenge for open source communities.

What’s your opinion?

This is true and in my view, a risk for any system that has many strongly-opinioned contributors (pretty much any large open source project).

Toward the end of his post, he poses a process-level question about how to avoid the situation of some contributions being more equal than others…. I think the solution is the current de facto for Eclipse.org projects and that’s the (frequently unstated) reality that the early bird defines the worm.

When it comes down to it, those that initiate and then follow through on enhancements, fixes, documentation or other contributions get to choose when it comes to actual design decisions. Inevitably, there are design choices that some disagree with, even when all discussion is had completely in the open.

I think the truth of the early bird defines the worm statement is that we should provide incentive to organizations and individuals in the community to be more aggressive about contributing to existing Eclipse projects. This is because  waiting for someone else to initiate, design, implement, test and document something often doesn’t work very well.

To some, it may seem like Eclipse Project development is effectively subsidized by others, but this is not true.  Even for one’s own usage of Eclipse, contribution and community involvement with Eclipse.org projects pays dividends. There are many ways to contribute, from contributing discussion/ideas, to planning, to new example/app code, to helping to maintain existing code, to documentation, to build support, to testing and bug reporting, to providing bug fixes, to mentoring, and plenty of other kinds of support.

In my view, these are the ways to get your contributions into Eclipse, and influence the community around the software.

Here’s my understanding of where the toString() contribution originated.

We’ve added to our distributed OSGi documentation (with examples+source) for ECF 3.0/Galileo:

• Distributed OSGi Services with ECF
• Getting Started with ECF’s RFC119 Implementation
• Getting Started Using the ECF Remote Services API

We have API layering so service programmers can choose the simplest appropriate mechanism for their system requirements, while still providing access to ‘lower-level’ concerns when necessary:

• failure handling
• synchronous vs. asynchronous remote method invocation
• serialization and wire protocol
• and so on…

If you have any questions or comments, please let us know on the ECF mailing list.

The ECF slides for this are here.  Some of them I didn’t actually have time to show at the DemoCamp, so there’s a little new information there, even for those that were present.

What does this mean? Well, you can now create distributed implementations of OSGi services using JMS or other messaging frameworks for distributing messages to other OSGi frameworks. This is all possible because of ECF’s provider architecture that allows the creation of a distributed EventAdmin implementation that can use a variety of wire protocols (e.g., XMPP, ActiveMQ).

Please let email the ecf-dev list if you have any questions!