Currently, all configuration informations have to be available on framework
startup. This prevents the development of modular JSF applications with OSGi,
JPF or any other module platform, where modules of the application are installed
or replaced at runtime.
Suppose you have a JSF application distributed over several OSGi bundles, each
of which contains a logical unit of the application. As long as all bundles are
available on startup and never change at runtime, there is no problem, for the
configuration can be stored in a META-INF/faces-config.xml file in each bundle
and a proper TCCL strategy will find the config files of all bundles at startup.
However in OSGi (and in similar platforms) bundles can change over time.
Contained new or changed views will be (re-)read by the view-handler and thus
are "dynamic" out of the box. It would be nice if elements like components,
validators, converters and navigation rules could be registered when starting
the bundle and unregistered when it is stopped.
It won't make much difference whether configuration at runtime is done using
config files or an API. Maybe by using config files the feature can be
implemented without making it to the specification. In any case no dependency to
any concrete module platform would be added.
As OSGi gets more and more popular on the server side and frameworks like
Eclipse RAP make heavy use of it today, this could become more important in the
future. Corresponding features recently made its way into the Servlet 3.0 early
draft too (JSR315, section 4.4 and 8).