Eclipse Yoxos Services Downloads Blogs About
Home > Blogs >

Scott Lewis

on Aug 20th, 2009Building Your Equinox OSGi Application Server – Part 3

In part 2 of this blog series, I described how to use Equinox p2 to install a new feature into a running Equinox application server. Rather than do this install at runtime via the OSGi console, many times it’s desirable to add bundles to an application server statically at build time rather than at runtime.  For example, this is usually the case when adding libraries for your web application to use. These libraries are sometimes created by others and sometimes created by you.

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:

p311 1024x719 Building Your Equinox OSGi Application Server   Part 3

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:

p32 1024x695 Building Your Equinox OSGi Application Server   Part 3

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

p33 1024x695 Building Your Equinox OSGi Application Server   Part 3

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:

p34 Building Your Equinox OSGi Application Server   Part 3

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

p35 1024x695 Building Your Equinox OSGi Application Server   Part 3

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:

p36 Building Your Equinox OSGi Application Server   Part 3

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:

p37 Building Your Equinox OSGi Application Server   Part 3

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

on Aug 17th, 2009Building Your Equinox OSGi Application Server – Part 2

In my previous post, I described how to easily build an Equinox-based web application server that can be run on any servlet container. Note that in the previous post I had these instructions for completing the export wizard dialog

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

sbp21 Building Your Equinox OSGi Application Server   Part 2

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:

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

sbp221 Building Your Equinox OSGi Application Server   Part 2

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

sbp232 Building Your Equinox OSGi Application Server   Part 2

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

sbp24 Building Your Equinox OSGi Application Server   Part 2

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

sbp25 Building Your Equinox OSGi Application Server   Part 2

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:

sbp26 Building Your Equinox OSGi Application Server   Part 2

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

sbp27 Building Your Equinox OSGi Application Server   Part 2

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!

on Aug 15th, 2009Building Your Equinox OSGi Application Server – Part 1

Over the past year I’ve developed a goal of making it easier to build and deploy the Equinox runtime as a web application server.  Not only does this fit my technical skills having previously worked on a commercial application server, it also fits my technical interests. It also seems that an ever increasing set of other people have been interested in running the Equinox OSGi runtime as a application server. Furthermore, many people may not be aware that there are now a number of really excellent  technologies available via the EclipseRT project that are relevant to creating modern application servers:

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

 Building Your Equinox OSGi Application Server   Part 1

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

sbimport1 Building Your Equinox OSGi Application Server   Part 1

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

sbexport1 300x165 Building Your Equinox OSGi Application Server   Part 1

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)

sbexport21 Building Your Equinox OSGi Application Server   Part 1

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)

tomcat1 Building Your Equinox OSGi Application Server   Part 1

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!

tomcat2 Building Your Equinox OSGi Application Server   Part 1

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

tomcat3 Building Your Equinox OSGi Application Server   Part 1

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.

on Aug 4th, 2009Remote OSGi Declarative Services

There is a very cool new tutorial by Bryan Hunt for using ECF‘s implementation of the OSGi Distributed OSGi spec (RFC 119) and OSGi Declarative Services (DS) together to do remote declarative services.

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!

on Jul 28th, 2009Teamwork, Innovation and Diversity

I was really impressed with this article from today’s NY Times:

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?

on Jul 13th, 2009Innovation, Competition and Open Source

There is an interesting op-ed in today’s NY Times from the venerable Robert Cringley:

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?

on Jun 29th, 2009Early bird defines the worm!

In his posting All contributions are Equal, some are more equal than others, Robert Konigsberg points out that contributing multiple ways of doing things can easily lead to more user complexity (e.g., by having multiple toString generators).

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.

on Jun 25th, 2009API Layering for Distributed OSGi

 API Layering for Distributed OSGi

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

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.

on Jun 19th, 2009Portland Galileo DemoCamp – ECF slides

As Elias and Darin already blogged, there was a memorable DemoCamp session in Portland Wednesday night.  Thanks to Instantiations for organizing and hosting.

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.

on Jun 16th, 2009Distributed OSGi EventAdmin Service

For those interested, there’s a new Distributed OSGi EventAdmin Service remote services example now available.

Distributedeventadmin Distributed OSGi EventAdmin Service

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!

Get Adobe Flash playerPlugin by wpburn.com wordpress themes
© EclipseSource 2008 - 2009