Hi,
What is the status of this?
Cheers,
Bruno
2009/5/31 Bernd Bohmann <bernd.bohm...@atanion.com>:
> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
