Hello Bernhard,
I would suggest you start with a own branch in 1.2 for the osgi changes.
Later we should try to made all the myfaces libs more osgi frendly.
Maybe we need an addition module or code in myfaces commons for the
osgi support in tomahawk, tobago and trinidad based on experiences
from the myfaces-core.
I'm very interested in the osgi support. I would like to help you with
the required changes in tobago.
Regards
Bernd
On Fri, May 29, 2009 at 11:12 PM, Leonardo Uribe <lu4...@gmail.com> wrote:
> 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
>>>>
>>>>
>>>
>>>
>>
>
>
