Home/ Questions/Q 43747
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T15:32:38+00:00

I’ve been looking into OSGi recently and think it looks like a really good

  • 0

I’ve been looking into OSGi recently and think it looks like a really good idea for modular Java apps.

However, I was wondering how OSGi would work in a web application, where you don’t just have code to worry about – also HTML, images, CSS, that sort of thing.

At work we’re building an application which has multiple ‘tabs’, each tab being one part of the app. I think this could really benefit from taking an OSGi approach – however I’m really not sure what would be the best way to handle all the usual web app resources.

I’m not sure whether it makes any difference, but we’re using JSF and IceFaces (which adds another layer of problems because you have navigation rules and you have to specify all faces config files in your web.xml… doh!)

Edit: according to this thread, faces-config.xml files can be loaded up from JAR files – so it is actually possible to have multiple faces-config.xml files included without modifying web.xml, provided you split up into JAR files.

Any suggestions would be greatly appreciated 🙂

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. You are very right in thinking there are synergies here, we have a modular web app where the app itself is assembled automatically from independent components (OSGi bundles) where each bundle contributes its own pages, resources, css and optionally javascript.

    We don’t use JSF (Spring MVC here) so I can’t comment on the added complexity of that framework in an OSGi context.

    Most frameworks or approaches out there still adhere to the ‘old’ way of thinking: one WAR file representing your webapp and then many OSGi bundles and services but almost none concern themselves with the modularisation of the GUI itself.

    Prerequisites for a Design

    With OSGi the first question to solve is: what is your deployment scenario and who is the primary container? What I mean is that you can deploy your application on an OSGi runtime and use its infrastructure for everything. Alternatively, you can embed an OSGi runtime in a traditional app server and then you will need to re-use some infrastructure, specifically you want to use the AppServer’s servlet engine.

    Our design is currently based on OSGi as the container and we use the HTTPService offered by OSGi as our servlet container. We are looking into providing some sort of transparent bridge between an external servlet container and the OSGi HTTPService but that work is ongoing.

    Architectural Sketch of a Spring MVC + OSGi modular webapp

    So the goal is not to just serve a web application over OSGi but to also apply OSGi’s component model to the web UI itself, to make it composable, re-usable, dynamic.

    These are the components in the system:

    • 1 central bundle that takes care of bridging Spring MVC with OSGi, specifically it uses code by Bernd Kolb to allow you to register the Spring DispatcherServlet with OSGi as a servlet.
    • 1 custom URL Mapper that is injected into the DispatcherServlet and that provides the mapping of incoming HTTP requests to the correct controller.
    • 1 central Sitemesh based decorator JSP that defines the global layout of the site, as well as the central CSS and Javascript libraries that we want to offer as defaults.

    • Each bundle that wants to contribute pages to our web UI has to publish 1 or more Controllers as OSGi Services and make sure to register its own servlet and its own resources (CSS, JSP, images, etc) with the OSGi HTTPService. The registering is done with the HTTPService and the key methods are:

      httpService.registerResources() and httpService.registerServlet()

    When a web ui contributing bundle activates and publishes its controllers, they are automatically picked up by our central web ui bundle and the aforementioned custom URL Mapper gathers these Controller services and keeps an up to date map of URLs to Controller instances.

    Then when an HTTP request comes in for a certain URL, it finds the associated controller and dispatches the request there.

    The Controller does its business and then returns any data that should be rendered and the name of the view (a JSP in our case). This JSP is located in the Controller’s bundle and can be accessed and rendered by the central web ui bundle exactly because we went and registered the resource location with the HTTPService. Our central view resolver then merges this JSP with our central Sitemesh decorator and spits out the resulting HTML to the client.

    In know this is rather high level but without providing the complete implementation it’s hard to fully explain.

    Our key learning point for this was to look at what Bernd Kolb did with his example JPetstore conversion to OSGi and to use that information to design our own architecture.

    IMHO there is currently way too much hype and focus on getting OSGi somehow embedded in traditional Java EE based apps and very little thought being put into actually making use of OSGi idioms and its excellent component model to really allow the design of componentized web applications.

    • 0