Jetty 10 and Bnd launcher

GENERAL
1

Hi,

I am currently working on a tutorial about OSGi Remote Services. I am using ECF and setting up different environments.

With PDE tooling I can consume Jetty 10 and Equinox HttpService and HttpWhiteboard and configure the auto-start of org.eclipse.equinox.http.jetty to get everything up and running.

With Bndtools I started using org.apache.felix.http.jetty which combines Jetty 9 and the HttpService and HttpWhiteboard. Works fine, but there is a strange issue if an ECF configuration is missing, which I did not see in the PDE example.
As there is no Apache Felix Jetty 10, I created a setup with all the bundles separately. But I don’t get the bundles org.eclipse.equinox.http.jetty and org.eclipse.equinox.http.servlet to start. I suppose because of two reasons:

  1. The bundles are configured for lazy activation
  2. Since Equinox has the policy to separate the service interfaces and the service implementations, nobody ever requests a class from the Equinox Http bundles.

My first question would be, am I right with my assumption?
Second, if my understanding is correct, what could be done to fix this?
If my understanding is incorrect, what could I do to get the bundles started?

Currently I have implemented an immediate component that searches for bundles that contain equinox.http.jetty that are in STARTING state and start them programmatically. But I needed to place that in a DS project, as the application project is also not started and sticks in the RESOLVED state, even with the contained immediate component (probably also a misunderstanding of the application project and why it is not started automatically).

The sources are located here:

I am still working on the Maven archetype variant. But there I will probably face the same issue if I want to use Jetty 10 instead of the Felix re-bundled Jetty 9.

Greez,
Dirk

2

Hello Dirk,

There are two things you can try (boils down to the same internal operation but two ways to set the flag:

In your bndrun, try either:

-runoptions: eager

OR


-runproperties: launch.activation.eager=true

and see if that gets around the lazy activation policy.

3

Hi Ray,

thank you very much for your fast response. Long question, short answer, and it works! :slight_smile:

BTW, is this documented somewhere? I haven’t found that information anyhwere so far.

4

Actually, it’s not documented. But I’ll try to fix that shotly :wink:

5

Wait, what? We have a freaking option to tell the launcher to start any bundle regardless of its activation policy? Why haven’t I seen this earlier…

6

Thanks @fipro78 for the question and @rotty3000 for the answer! I had the same issue with Jetty in iDempiere, and like Dirk I had to work around it by having a little code snippet that would run through and start bundles that are stuck in the “starting” state. I tried @rotty3000 's suggestion but it caused other issues.

It would be nice if this could be an attribute on the bundle spec in -runbundles, rather than a global option applied to all bundles indiscriminately…