Hooking up remote systems with distributed OSGi - Enterprise OSGi in Action - page 257

Figure 10.13 After adding Distributed OSGi

To get a remote service imported into your framework, you need to install the Distrib-
uted OSG i bundle, which again you can do by dropping it into the load directory of your
framework. Sadly, this is enough to cause a problem. As you can see from figure 10.13,
adding Distributed OSG i has caused something to go wrong with your application.
Although the problem may look severe, it's not as bad as it looks. Distributed OSG i
makes use of the Jetty Web Container project to provide its HTTP web service hosting.
This is exactly the same web container that your basic runtime uses, and when the Dis-
tributed OSG i bundle starts up, it ends up accidentally reconfiguring your runtime's
Jetty instance as well as its own!
Unfortunately, the reconfiguration that happens moves Jetty onto a randomly
assigned free port. Luckily, it's easy for you to find out what port Jetty was reassigned
to. If you look at your runtime's pax-web-jetty-bundle in the OSG i console, you see
something like figure 10.14.
If you look closely at figure 10.14, you can see that pax has registered an OSG i
HTTP Service implementation in the Service Registry, and that one of the service
properties for this service is called org.osgi.service.http.port , and it has a
numeric value. This value is the port that you can access your application on. If you
change your URL to use this port instead, then things look much rosier again (see fig-
ure 10.15).
Although your application is still working happily, notice that your foreign foods
special offer is nowhere to be seen. This is because you haven't given Distributed OSG i
any information about the remote endpoints you want it to connect to. If you want to
go any further, you'll need to learn more configuration.

Figure 10.14 Your
Jetty service properties