Hello,
well, you can't simply "attach OSGi support" to an existing MyFaces
release. There are dozens of core classes that have to be changed. As
I've already mentioned, currently MyFaces assumes that it's sufficient
to save the class names (e.g. managed bean classes) as every class will
be loaded using the context class loader, but the OSGi-fied version of
MyFaces would also have to save the bundle to use for loading that
class, etc..
Hence I don't think that it's possible to create a new MyFaces commons
module for OSGi support.
regards,
Bernhard
Leonardo Uribe wrote:
Hi
Maybe a new module in myfaces commons is the right place to put this
efforts.
regards
Leonardo Uribe
2009/5/29 Bernhard Huemer <bernhard.hue...@gmail.com
<mailto:bernhard.hue...@gmail.com>>
Hello,
recently I've thought of using JSF in an OSGi environment because of
the greater modularity it would provide for developers. JSF already
provides reusability regarding the user interface, i.e. JSF provides
the possibility to create user interface components, but what do you
do if you want to reuse more aspects of previous applications than
just user interface fragements? How to reuse dialogs, i.e. certain
workflows, etc..?
OSGi already does provide these reusability features and hence I've
adapted MyFaces in a way so that it's runnable in an OSGi container.
Basically you just have to deploy an implementation of the OSGi HTTP
Service (e.g. Pax Web [1]), the two MyFaces bundles (myfaces-api and
myfaces-impl) and your web application bundles. Basically a
BundleListener keeps track of all bundles being deployed to the OSGi
container, so if the user installs a JSF bundle MyFaces gets
notified and merges the current configuration with the configuration
of the new bundle.
However, even though I've been able to implement a running version,
I had to change major parts of MyFaces. For example, using OSGi you
can't use the context class loader if you want to create a new
instance for a class that resides in a different bundle (think of
managed beans, MyFaces is responsible for creating the instance, but
the class file is located in a different bundle) and hence I had to
rewrite the configuration module (e.g. a LifecycleProvider
implementation receives just a class name of the managed bean to
instantiate assuming that it can load the class using the context
class loader, but that won't work in the case of an OSGi environment).
Therefore I'd like to know if I should start contributing these
changes? (and if so, should I create a different branch at first, etc.?)
regards,
Bernhard
[1]: http://wiki.ops4j.org/display/paxweb/Pax+Web
