dev@javaserverfaces.java.net

Re: OSGi Support

From: Hendrik Kammeyer <hendrik_at_hengames.de>
Date: Mon, 14 Apr 2008 17:42:24 +0200

Ok, i don't know how advanced your own plannings are so far, anyway i'd
like to share some thoughts :-)

What are the greatest general problems of supporting OSGi? I guess two
of them are the danger of
a) bloating the spec. in favor of a feature many people won't need.
b) adding another dependency on a specific technology/framework.

That said, it would be nice to change JSF in a way that it could easily
be used within an OSGi
environment, without a direct connection to OSGi. And i think that could
be realized just by
making JSF more dynamic. In particular that could mean:

- Every entity that is added to the framework at startup time (from
faces-config.xml) can be added
  at runtime. Entities could be navigation rules, managed beans,
validators, converters and so on.
- Every entity that can be added at runtime can also be removed (and
possibly be updated).
- The configuration is more flexible, in a way that it's possible to
read config files from any sources
  at runtime. Maybe a user definable ConfigurationHandler would make sense?

The list is propably incomplete, as i'm still not that deep in JSF. Of
course, those features would not be very
useful in a classic non-dynamic environment. You could summarize them to
a kind of optional extension of
the JSF spec or the like?

With these enhancements, an adapter could be written to start JSF within
an OSGi environment and distribute
the webapp over several bundles, each of which can appear and disappear
at runtime. So far i have only a
vague idea of how this could be implemented, but the JSF API would offer
everything that will be needed by
the adapter. Support for similar technologies could be added at a later
time. (JSR 277?).

However some problems remain, like the lack of having a Servlet 2.4+ API
within the OSGi platform.

Regards,
Hendrik


Jason Lee wrote:
> On Thu, Apr 10, 2008 at 6:19 PM, Hendrik Kammeyer <hendrik_at_hengames.de
> <mailto:hendrik_at_hengames.de>> wrote:
>
> 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.
> <http://1.1.13.> Here is what i
> noticed, maybe it helps in your discussion:
>
>
> Wow. That sounds painful. I'll try to digest all of this and see
> where it leads.
>
>
> - 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.
>
>
> Right, which may mean making ViewHandlers, etc as separate bundles
> difficult. I'm not sure that degree of modularization is even
> desirable. I think the original request was just to get JSF deployed
> in an OSGi container, not necessarily being able to swap out the
> internals at will...
>
>
>
> - 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.
>
>
> Hmm. OK. This will be the interesting part, I think.
>
>
> 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?
>
>
> That I don't know. I'll need to reread that part of the spec carefully.
>
>
> - 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.
>
>
> It may be that this JSF/OSGi bundle effort may need to be
> implementation-specific and leverage private APIs (and adding some, if
> need be) to make things work. Thoughts, anyone?
>
>
> 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.
>
>
> It helps a lot. Thanks for the feedback.
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com