myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: MyFaces in an OSGi environment
Date Fri, 29 May 2009 21:12:56 GMT
Hi

Ok, so the idea is become myfaces core OSGi friendly rather than create a
module for it. Sounds good for me.

regards

Leonardo Uribe

2009/5/29 Bernhard Huemer <bernhard.huemer@gmail.com>

> 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.huemer@gmail.com <mailto:
>>> bernhard.huemer@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
>>>
>>>
>>>
>>
>>
>

Mime
View raw message