Hi,
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
outside.
- 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
filters.
- 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 com.sun.facelets.util.Classpath.search() 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
bundles.
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,
Hendrik
On Tue, 8 Apr 2008 08:44:04 -0500, Jason Lee <jason_at_steeplesoft.com>
wrote:
> 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 :)