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.hue...@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.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
>>>
>>>
>>>
>>
>>
>
