You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Bernhard Huemer <be...@gmail.com> on 2009/05/29 17:05:19 UTC
MyFaces in an OSGi environment
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
Re: MyFaces in an OSGi environment
Posted by Bruno Aranda <br...@gmail.com>.
Hi,
What is the status of this?
Cheers,
Bruno
2009/5/31 Bernd Bohmann <be...@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 <lu...@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 <be...@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
>>>>> <ma...@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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: MyFaces in an OSGi environment
Posted by Bernd Bohmann <be...@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 <lu...@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 <be...@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
>>>> <ma...@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
>>>>
>>>>
>>>
>>>
>>
>
>
Re: MyFaces in an OSGi environment
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <be...@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
>>>
>>>
>>>
>>
>>
>
Re: MyFaces in an OSGi environment
Posted by Bernhard Huemer <be...@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
>> <ma...@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
>>
>>
>
>
Re: MyFaces in an OSGi environment
Posted by Bernhard Huemer <be...@gmail.com>.
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
> <ma...@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
>
>
Re: MyFaces in an OSGi environment
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Maybe a new module in myfaces commons is the right place to put this
efforts.
regards
Leonardo Uribe
2009/5/29 Bernhard Huemer <be...@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
>
Re: MyFaces in an OSGi environment
Posted by Kito Mann <ki...@virtua.com>.
To me, this sounds like a great way to implement Grails-style plugin
support. I haven't worked with Grails closely enough to know for sure,
however. Thoughts?
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99 http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3
On Fri, May 29, 2009 at 11:05 AM, Bernhard Huemer <bernhard.huemer@gmail.com
> wrote:
> 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
>