Java Reference
In-Depth Information
Figure 15.5
The
Google stock-watcher
application running in
an OSGi context
The Web Applications specification allows you to take advantage of
OSG
i's module
layer to share classes installed elsewhere in the
OSG
i framework, ensure that you have
the correct dependencies installed, and enforce defined module boundaries. You can
also use the lifecycle layer to allow dynamic installation, update, and removal of your
web application.
Modularity improves memory consumption
In this trivial example, sharing classes offers relatively little value, because the
stock watcher has few external dependencies. But consider the benefits of being
able to share classes in a large web application environment. In standard WAR de-
velopment, each application must embed its own set of dependencies in its WAR
file under the WEB-INF/lib directory. For utility classes, such as collections libraries,
XML parsers, and logging frameworks, this can mean a lot of duplicate classes get
loaded into the VM for each WAR file installed in your application server. These
classes can eat up memory. In an OSGi environment, you can move dependencies
into separate bundles that are then shared among installed applications, reducing
the overall memory footprint.
You've got modularity. You've got lifecycle. What about services? Yep, the example
uses services too! The following listing shows how.
Listing 15.9 Accessing the
BundleContext
from within a servlet
public class StockPriceServiceImpl extends RemoteServiceServlet
implements StockPriceService {
private BundleContext ctx;
@Override
public void init() throws ServletException {
ctx = (BundleContext) getServletContext()
.getAttribute("osgi-bundlecontext");
