I think I'll have to explain that a little more:
The current OSGi-fied version of MyFaces that I've implemented doesn't
save class names in the runtime configuration but rather a combination
of a class name and a class loader.
///
public interface ClassLoader {
public Class loadClass(String className)
throws ClassNotFoundException;
}
/**
* ClassLoader implementation that uses the context class loader
* in order to load Java classes.
*/
public class JavaVmClassLoader implements ClassLoader {
private java.lang.ClassLoader classLoader;
public JavaVmClassLoader(java.lang.ClassLoader classLoader) {
this.classLoader = classLoader;
}
public Class loadClass(String className)
throws ClassNotFoundException {
return Class.forName(className, false, classLoader);
}
}
/**
* ClassLoader implementation that uses an OSGi bundle in order to
* load Java classes.
*/
public class OsgiClassLoader implements ClassLoader {
private Bundle bundle;
public OsgiClassLoader(Bundle bundle) {
this.bundle = bundle;
}
public Class loadClass(String className)
throws ClassNotFoundException {
return bundle.loadClass(className);
}
}
\\\
However, there are other issue as well besides this one (no JSP
available, different approach to resource loading, some dependencies of
MyFaces aren't "OSGi-friendly", ...).
regards,
Bernhard
Bernhard Huemer wrote:
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
