Re: OSGi Support

From: Hendrik Kammeyer <>
Date: Fri, 11 Apr 2008 01:19:51 +0200

I'm no JSF dev but i tried to start JSF within an OSGi environment for
a whole week and ran into a lot of problems, although i got it working
at last with MyFaces (1.1 or 1.2) + Facelets 1.1.13. Here is what i
noticed, maybe it helps in your discussion:

- It seems not to be a good idea to split up JSF to one part running in an
  OSGi bundle and the other part running outside, for the bundle has its
  own classloader. All classes within the bundle are invisible to the

- As was already said, you could either run an OSGi platform within the
  servlet/JSP container or vice versa. Although the latter may be the
  preferred way, many users don't want to change their servers. When
  running OSGi within the servlet container, you have to bridge servlets
  into the OSGi platform (as org.eclipse.equinox.servletbridge does).
  Launching and configuring the OSGi platform is implementation-specific,
  o.e.e.servletbridge contains a replacable launcher for Equinox.

- No matter if you use o.e.e.servletbridge (OSGi inside servlet container)
  or o.e.e.jetty (servlet container inside OSGi), the only connection
  between JSF and the container is a HttpService interface, which offers
  a similar API to servlet spec 2.1. (Even less, as it doesn't support
  mappings by file name extension). No web.xml, no context listeners, no

- To work around that issues, i had to:
  - create a dummy web.xml inside the bundle, just to satisfy
    verifications inside MyFaces 1.2 ;-)
  - set a dispatcher servlet between the bridge servlet and the
    FacesServlet, that
      a) calls the MyFaces context initializer within its init() method and
      b) does the file name extension filtering.
  - hack for otherwise it won't
    be able to find the Facelets taglib files inside the bundle.
  - I used a test page within the JSF-bundle. In a real app, the pages
    and other resources would be distributed to different bundles.

- After that it worked for me, it is even possible to stop and restart
  the JSF-bundle. However after re-installing it without stopping the vm
  i got some nasty classloader exceptions. I suppose there are some
  assumptions in the JSF spec (or in the MyFaces impl.) of the underlying
  classloader being part of the servlet container?

- After all i did not manage to add content from other bundles to the
  running webapp, for the JSF API lacks of some functionality (forgive me
  if a am wrong, as i'm really no JSF expert...):
  - it seems not to be possible to add or remove managed beans at runtime
  - there is no remove*() equivalent to Application.addComponent(),
    addConverter and addValidator()
  - there is no way to add or remove Facelets taglibs at runtime
  - i found no way to map view-ids to Facelets pages from external

I hope that helps you getting a feeling of what would need to be changed to
support OSGi. And i hope you don't bury your plans now, as i am in need
of that feature and a couple of similar requests in the Equinox
Technology newsgroup had similar requests.

Best regards,

On Tue, 8 Apr 2008 08:44:04 -0500, Jason Lee <>

> Those are all very good questions, answers to which I'd like to hear myself.
> :)
> In terms of implementing these changes (whatever they turn out to be), I
> really have no idea when and where that would happen. Of course, I'm
> willing to help, but, as I've noted, I'm still an OSGi noob, so it will take
> me some time to get up to speed. If we can decide on how this should
> look/work, I'll think along those lines as I study OSGi, and we'll see what
> happens (assuming the entire idea isn't scrapped. Either way, I have to
> learn OSGi, though :)