OSGi and Vertx Web example application

[Paul Bakker]

Hi all,

As a fun experiment I created an example app and blog post about using Vertx Web, the SockJS event bus bridge and Mongo in an OSGi environment. The goal was to integrate nicely with the OSGi dynamic services programming model and this turns out to work very nicely. 

The blog post can be found here: http://paulbakker.io/osgi/vertx-osgi/ and the example Github repo here: https://github.com/paulbakker/osgi-vertx-demo.

Well done on both the design and implementation side of Vertx that this works as well as it does!

Cheers,

Paul

[Clement Escoffier]

Hello Paul,

That’s great !

Our OSGi support is not yet complete so you may have issues on vert.x components that are not “bundle” yet. Especially, some of them use some class loading magic that would need some tweaking. I hope to be able to bundledize more components in vert.x 3.3.0.

BTW, we have a couple of OSGi examples in https://github.com/vert-x3/vertx-examples/tree/master/osgi-examples. If you want we can add yours here, or mention them in the README. What do you think?

Cheers,

Clement

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/eebd2a39-1071-48b7-9bea-a3b7c9f368bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Bakker]

Hi Clement,

The blog post describes how I worked around the issue of Vertx Web (and others) not being bundles yet. The main issue was figuring out which imports are optional and which aren't, but besides that it's not very difficult to get it to work.

Of course it would be great if this was supported better out of the box, so once you get to that I would be happy to help. Feel free to ping me about it.

The example workspace is a Bndtools workspace, not Maven. I'm not sure that fits well enough with the other examples? If that's not a problem I would be happy to move the repo to the official examples.

Cheers,

Paul

You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/836vf0QWbGk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/591893B7-8BEF-437B-B9CB-55D141458658%40gmail.com.

[Clement Escoffier]

Hello Paul,

I’ve added a link to your post and code on https://github.com/vert-x3/vertx-examples/tree/master/osgi-examples. 

I actually don’t mind having a project using bndtools on the repository, but the example repository is going to be restructured soonish, so I will ping you once done. 

I saw that you have make a bundle from the Mongo client, that’s really cool. I will integrate your BND instructions in the mongo client. 

One of the issue when making bundle is to embed the right set of language support. For instance, I saw you have exported the RXJava support, but not the Groovy support. This is always debatable (and hard to find the right balance).

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAGrzLmXeq9hUmhF4wKDBajzi_DvrRLe-ci8V5_hp-XpAuzGy-g%40mail.gmail.com.

[Paul Bakker]

Yes, this is a difficult issue to fix in a re-usable way. 

A few points about this:

- I guess all packages (excluding impl packages) should be exported. There is not really a reason I didn't export io.vertx.groovy.ext, and probably should be doing that.

- All optional dependencies should get optional, or even dynamic import packages, assuming that Vertx already handles the optional loading of these classes. groovy.lang is an example of this. From the Vertx side, is it possible to dynamically add these optional features? E.g. is the optional classpath loading re-checked every invocation? In that case dynamic imports would be the better choice.

- For this to fully work, all Vertx modules should become valid OSGi bundles following these same principles, ideally wrapping their transitive dependencies. 

Specifically for the activator I created that registers Vertx and Router as services, there is one more problem; *if* you're using the RX API, these services should be registered using that API. I guess there are two options:

1) Use conditional class loading to check if RX is available or not, register services based on that

2) Write two versions of the Activator, available in two different bundles. E.g. a Vertx-Web-OSGi bundle (that only contains the activator), and a Vertx-Web-Rx-OSGi bundle.

Looking at the Vertx code, should all classes *not* in impl be available to users? 

Bnd has a new Maven plugin available that is much better than the bundle plugin from the Felix project (which is currently used in vertx-core). Would it make sense starting an experiment to add this plugin to some of the modules (e.g. Vertx Web, Rx) to see if we can get this to work without manual wrapping like I did?

Cheers,

Paul

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/3C34473C-3AE9-497B-B61D-5605890DB260%40gmail.com.

[Paul Bakker]

Hi Clement,

I couldn't resist trying osgi-ifying some bundles, and it turns out to be easier than I expected. What I did:

1) Add the bnd plugin to Vertx Web's pom file. All non-impl packages are exported, and optinal imports for the optional modules. (See GitHub repo 1)

2) Same for Vertx RX (See GitHub repo 2)

3) Created another example workspace (See Github repo 3) with two different examples. The first example uses the plain Vertx / Vertx Web API to start a web server. In the run config (https://github.com/paulbakker/vertx-osgi-v2/blob/master/vertx.web.demo/demo.bndrun) it shows that this doesn't require Vertx RX, or the RX libs.

The second example uses the Vertx RX API to do the same. For this setup the Vertx RX bundle, and RX Java are required, which is handled correctly by the resolver.

I think this is the right pattern to apply to all modules, and that shouldn't be too difficult. The only "issue" that we will see is that some transitive dependencies are probably not bundles yet, so we might want to wrap them.

What do you think?

Cheers, Paul

GitHub repo 1: https://github.com/paulbakker/vertx-web/commit/b40d1e61a26cc35d16bc1cb32766936b540cba46

GitHub repo 2:  https://github.com/paulbakker/vertx-rx/commit/2832f551a251c8576afcb3d8d36d959313313040

GitHub repo 3: https://github.com/paulbakker/vertx-osgi-v2

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/3C34473C-3AE9-497B-B61D-5605890DB260%40gmail.com.