Details

Description

The provided patch will add OSGi information to bundle manifest. A bundle activator class makes the MyFaces framework aware that it is running in a bundle environment. A bundle classloader is used to load classes and resources from the bundle classpath. The patch doesn't require any new runtime dependencies and doesn't affect class loading in a non-OSGi environment. Though, small modifications to classloading were needed. This was mainly replacing Thread.currentThread.getContextClassLoader() with ClassUtils methods.

To run MyFaces in an OSGi environment both bundles (myfaces-api and myfaces-impl) have to be started in the OSGi container. Additionally, the myfaces-impl bundle has to be made available to myfaces-api. Use a fragment bundle with myfaces-api as Fragment-Host and myfaces-impl as Required-Bundle.

Sounds good. Will this be included in the 1.2 branch and whats the timeframe for this? What can we do to prioritize this issue?
We are going to port our application to osgi for more flexibility and of course maintainability.
So if myfaces would be more kindly to an osgi environment would be a big step forward.

Andreas Hartmann-Schneevoigt
added a comment - 06/Oct/09 16:23 Sounds good. Will this be included in the 1.2 branch and whats the timeframe for this? What can we do to prioritize this issue?
We are going to port our application to osgi for more flexibility and of course maintainability.
So if myfaces would be more kindly to an osgi environment would be a big step forward.

are public classes. No public classes could be added to myfaces-api, because do that breaks binary compatibility with ri. The problem is that according to OSGi javadoc, BundleActivator instances should have a public no args constructor.

Leonardo Uribe
added a comment - 23/Oct/09 21:00 I have checked the patch, but unfortunately it contains an serious bug. The following classes added in the patch:
javax.faces.component._BundleUtils
javax.faces.component._BundleProxyClassLoader
javax.faces.component._Activator
are public classes. No public classes could be added to myfaces-api, because do that breaks binary compatibility with ri. The problem is that according to OSGi javadoc, BundleActivator instances should have a public no args constructor.
Suggestions are welcome

What do you understand by the patch breaking the binary compatibility to the RI? Adding new classes won't break binary compatibility to the RI as it doesn't change any existing API nor does it affect the RI in any other ways.

Could you please explain what you mean by binary compatibility to the RI?

Another thing I want to point out as you're looking into this: both the myfaces-api and myfaces-impl contain a package called "javax.faces". This will result in a split package in OSGi world and the Messages_xx.properties files in myfaces-impl bundle won't be found from myfaces-api bundle.

Otherwise, I don't know of a way of getting the BundleContext without a BundleActivator. If adding the classes provided in the patch proves to be a real problem it appears to me that JSF is not osgifyable.

Felix Röthenbacher
added a comment - 28/Oct/09 01:07 What do you understand by the patch breaking the binary compatibility to the RI? Adding new classes won't break binary compatibility to the RI as it doesn't change any existing API nor does it affect the RI in any other ways.
Could you please explain what you mean by binary compatibility to the RI?
Another thing I want to point out as you're looking into this: both the myfaces-api and myfaces-impl contain a package called "javax.faces". This will result in a split package in OSGi world and the Messages_xx.properties files in myfaces-impl bundle won't be found from myfaces-api bundle.
Otherwise, I don't know of a way of getting the BundleContext without a BundleActivator. If adding the classes provided in the patch proves to be a real problem it appears to me that JSF is not osgifyable.

Leonardo Uribe
added a comment - 28/Oct/09 01:33 We can't add public classes on javax.faces package, because the classes there are dictated by JSR-252, but maybe we can add classes under org.apache.myfaces on myfaces-api jar.
We have to ask dev list how to deal with this. At this point we have the following options:
1. add the required classes as public under org.apache.myfaces package myfaces-api.jar
2. Create one or two jar specific for OSGi, that deal with this.
I'll ask this to dev list to see what we can do.

It could be good if you submit how did you test the previous patch. Before commit this one or some variant of this patch, it is necessary to check this patch works by some myfaces committer. I tried to run this bundle but there is a lot of problems that are not related to myfaces jars to make it run (make bundles for each dependences, problems with tlds.....).

Leonardo Uribe
added a comment - 28/Oct/09 02:56 Hi Felix,
It could be good if you submit how did you test the previous patch. Before commit this one or some variant of this patch, it is necessary to check this patch works by some myfaces committer. I tried to run this bundle but there is a lot of problems that are not related to myfaces jars to make it run (make bundles for each dependences, problems with tlds.....).
regards
Leonardo Uribe

Felix Röthenbacher
added a comment - 28/Oct/09 03:30 Unfortunately, I won't have the time to provide you with an OSGi runtime environment (and this can be a real pain) but I can give you some directions how my setup looks like:
Use fragment bundle for myfaces-api bundle to allow access to myfaces-impl and, in my case, also Trinidad. I used the require-bundle directive so search for resources can be limited to those bundles
Manifest-Version: 1.0
Built-By: syabru.ch
Bundle-Name: Syabru OSGi org.apache.myfaces.core.api fragment
Fragment-Host: org.apache.myfaces.core.api;bundle-version="1.2.8"
Require-Bundle: org.apache.myfaces.core.impl;bundle-version="1.2.8",
org.apache.myfaces.trinidad.impl;bundle-version="1.2.12"
Bundle-Version: 0.0.1.SNAPSHOT
Bundle-ManifestVersion: 2
Bundle-SymbolicName: ch.syabru.osgi.org.apache.myfaces.core.api-fragmen
t
Setup OSGi runtime environment with Equinox (note: to my knowledge Apache Felix doesn't support fragments)
I used Spring Dynamic Modules for OSGi ( http://www.springsource.org/osgi ) to startup Tomcat as OSGi service and deploy web application bundle

I just checked with Mojarra: they ARE an OSGI Bundle, and they don't have any bundle-activators or other stuff. Only meta-data. Nothing special in Mojarra for OSGI. Felix, why did you feel the need to create these classes?

Martin Marinschek
added a comment - 28/Oct/09 09:28 Hi Leonardo, Felix,
I just checked with Mojarra: they ARE an OSGI Bundle, and they don't have any bundle-activators or other stuff. Only meta-data. Nothing special in Mojarra for OSGI. Felix, why did you feel the need to create these classes?
regards,
Martin

Felix Röthenbacher
added a comment - 28/Oct/09 10:28 The reason to use the BundleActivator and BundleContext is to get the bundle's classloader instead of using the context classloader.
You can find further information about context classloader issues in OSGi world at:
http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements
Of the special interest for you might be the problem description:
http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Problem_Description
Mojarra apparently uses the Thread.currentThread().getContextClassLoader() to load classes and resources. The problem is, that the context classloader is undefined in an OSGi environment. As I understand it, Mojarra, despite publishing OSGi bundle metadata, hasn't solved the class loading problem.
Hth, Felix

Many third-party libraries use the thread context ClassLoader to access application types and resources. Each bundle in OSGi has it's own ClassLoader, so therefore, only one bundle can be exposed as the thread context ClassLoader at any time. This means that if a third-party library needs to see types that are distributed across multiple bundles, it isn't going to work as expected.

The Platform fixes this by creating a ClassLoader that imports all the exported packages of every module in your application. This ClassLoader is then exposed as the thread context ClassLoader, enabling third-party libraries to see all the exported types in your application........"

Use a BundleActivator is the OSGi suggested way to solve this issues, but given the context of the problem, it seems better to do not use a BundleActivator and use spring dm to deal with this stuff.

Conclusion: The best we can do from myfaces side is use org.apache.felix maven-bundle-plugin to create a manifest in the way described before without include BundleActivator classes, and let this issue open, so if somebody wants to use the BundleActivator way, he/she can change the code adding it. The only thing left is set the context class loader for Digester instances to org.apache.myfaces.shared_impl.util.ClassUtils.getContextClassLoader().

Leonardo Uribe
added a comment - 28/Oct/09 17:00 It seems spring dm has already solved the problem with Thread.currentThread().getContextClassLoader(). Look this blog:
http://blog.springsource.com/2008/05/02/running-spring-applications-on-osgi-with-the-springsource-application-platform
the important part is below:
"......Thread context classloader management
Many third-party libraries use the thread context ClassLoader to access application types and resources. Each bundle in OSGi has it's own ClassLoader, so therefore, only one bundle can be exposed as the thread context ClassLoader at any time. This means that if a third-party library needs to see types that are distributed across multiple bundles, it isn't going to work as expected.
The Platform fixes this by creating a ClassLoader that imports all the exported packages of every module in your application. This ClassLoader is then exposed as the thread context ClassLoader, enabling third-party libraries to see all the exported types in your application........"
Use a BundleActivator is the OSGi suggested way to solve this issues, but given the context of the problem, it seems better to do not use a BundleActivator and use spring dm to deal with this stuff.
But note this link:
http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.myfaces.javax.faces&version=1.2.2&searchType=bundlesByName&searchQuery=jsf
in SpringSource Bundle Repository it is possible to find a OSGi bundle for myfaces. This is the manifest for myfaces-api.jar
Manifest-Version: 1.0
Export-Package: javax.faces;provider="myfaces";version="1.2.2",javax.f
aces.application;provider="myfaces";version="1.2.2";uses:="javax.el,j
avax.faces,javax.faces.component,javax.faces.context,javax.faces.conv
ert,javax.faces.el,javax.faces.event,javax.faces.validator",javax.fac
es.component;provider="myfaces";version="1.2.2";uses:="javax.el,javax
.faces,javax.faces.application,javax.faces.context,javax.faces.conver
t,javax.faces.el,javax.faces.event,javax.faces.model,javax.faces.rend
er,javax.faces.validator",javax.faces.component.html;provider="myface
s";version="1.2.2";uses:="javax.faces.context",javax.faces.context;pr
ovider="myfaces";version="1.2.2";uses:="javax.el,javax.faces,javax.fa
ces.application,javax.faces.component,javax.faces.lifecycle,javax.fac
es.render",javax.faces.convert;provider="myfaces";version="1.2.2";use
s:="javax.faces.application,javax.faces.component,javax.faces.context
",javax.faces.el;provider="myfaces";version="1.2.2";uses:="javax.face
s.context",javax.faces.event;provider="myfaces";version="1.2.2";uses:
="javax.el,javax.faces.component,javax.faces.context,javax.faces.life
cycle",javax.faces.lifecycle;provider="myfaces";version="1.2.2";uses:
="javax.faces,javax.faces.context,javax.faces.event",javax.faces.mode
l;provider="myfaces";version="1.2.2";uses:="javax.servlet.jsp.jstl.sq
l",javax.faces.render;provider="myfaces";version="1.2.2";uses:="javax
.faces.application,javax.faces.component,javax.faces.context,javax.fa
ces.convert",javax.faces.validator;provider="myfaces";version="1.2.2"
;uses:="javax.el,javax.faces.application,javax.faces.component,javax.
faces.context",javax.faces.webapp;provider="myfaces";version="1.2.2";
uses:="javax.el,javax.faces.component,javax.faces.context,javax.faces
.convert,javax.faces.validator,javax.servlet,javax.servlet.jsp,javax.
servlet.jsp.tagext"
Implementation-Title: Apache Myfaces JSF Core-1.2 API
Bundle-Classpath: .
Implementation-Version: 1.2.2
Built-By: lu4242
Bundle-Name: Apache MyFaces JSF API
Created-By: Apache Maven
Bundle-Vendor: SpringSource
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache.myfaces.core
Build-Jdk: 1.6.0_02
Bundle-Version: 1.2.2
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.springsource.org.apache.myfaces.javax.faces
Import-Package: javax.el;version="[1.0.0, 2.0.0)",javax.servlet;versio
n="[2.5.0, 3.0.0)",javax.servlet.http;version="[2.5.0, 3.0.0)",javax.
servlet.jsp;version="[2.1.0, 3.0.0)",javax.servlet.jsp.jstl.core;vers
ion="[1.1.2, 2.0.0)",javax.servlet.jsp.jstl.sql;version="[1.1.2, 2.0.
0)",javax.servlet.jsp.tagext;version="[2.1.0, 3.0.0)",org.apache.comm
ons.logging;version="[1.1.1, 2.0.0)"
Archiver-Version: Plexus Archiver
Conclusion: The best we can do from myfaces side is use org.apache.felix maven-bundle-plugin to create a manifest in the way described before without include BundleActivator classes, and let this issue open, so if somebody wants to use the BundleActivator way, he/she can change the code adding it. The only thing left is set the context class loader for Digester instances to org.apache.myfaces.shared_impl.util.ClassUtils.getContextClassLoader().

Added patch for this issue using felix maven-bundle-plugin. Still pending testing of the generated artifacts, but note before test it is required correct <Fragment-Host> part with proper version name, due to a bug in felix (I filed FELIX-1820).

Leonardo Uribe
added a comment - 28/Oct/09 20:45 Added patch for this issue using felix maven-bundle-plugin. Still pending testing of the generated artifacts, but note before test it is required correct <Fragment-Host> part with proper version name, due to a bug in felix (I filed FELIX-1820 ).

I wouldn't say that Spring dm has solved the problem with exposing all exported packages of all bundles. It makes things rather worse: imagine, for example, you've got a bundle in version 1 and version 2 running in your OSGi environment (e.g. JSF 1.2 and JSF 2.0). From which one will the classes be loaded? This approach will cause all sorts of problems. I would rather tend to use something like Equinox's buddy class loader which makes it much more predictable where classes are loaded from.

> Use a BundleActivator is the OSGi suggested way to solve this issues,
> but given the context of the problem, it seems better to do not use a
> BundleActivator and use spring dm to deal with this stuff.

That doesn't sound like a good idea to me to force people to use a specific OSGi implementation. And Spring dm doesn't seem to deal well with this sort of problems either.

> in SpringSource Bundle Repository it is possible to find a OSGi
> bundle for myfaces. This is the manifest for myfaces-api.jar

That's myfaces 1.2.2 with added OSGi metadata. And it doesn't solve the class and resource loading problems. It is the very objective of this Jira issue to provide this OSGi metadata and proper class loading in an OSGi environment out of the box.

> Conclusion: The best we can do from myfaces side is use
> org.apache.felix maven-bundle-plugin to create a manifest in the way
> described before without include BundleActivator classes, and let
> this issue open, so if somebody wants to use the BundleActivator way,
> he/she can change the code adding it. The only thing left is set the
> context class loader for Digester instances to
> org.apache.myfaces.shared_impl.util.ClassUtils.getContextClassLoader().

If we have a look at what is causing this troubles it shows that the API bundle isn't purely API but contains some key implementation classes like javax.faces.FacesServlet or javax.faces.FactoryFinder. This leads to the point that the API bundle has to have some knowledge about the implementation and it has to know how to load the respective factory classes.

Felix Röthenbacher
added a comment - 28/Oct/09 21:25 > It seems spring dm has already solved the problem with
> Thread.currentThread().getContextClassLoader(). Look this blog:
>
> http://blog.springsource.com/2008/05/02/running-spring-applications-on-osgi-with-the-springsource-application-platform
>
I wouldn't say that Spring dm has solved the problem with exposing all exported packages of all bundles. It makes things rather worse: imagine, for example, you've got a bundle in version 1 and version 2 running in your OSGi environment (e.g. JSF 1.2 and JSF 2.0). From which one will the classes be loaded? This approach will cause all sorts of problems. I would rather tend to use something like Equinox's buddy class loader which makes it much more predictable where classes are loaded from.
> Use a BundleActivator is the OSGi suggested way to solve this issues,
> but given the context of the problem, it seems better to do not use a
> BundleActivator and use spring dm to deal with this stuff.
That doesn't sound like a good idea to me to force people to use a specific OSGi implementation. And Spring dm doesn't seem to deal well with this sort of problems either.
> in SpringSource Bundle Repository it is possible to find a OSGi
> bundle for myfaces. This is the manifest for myfaces-api.jar
That's myfaces 1.2.2 with added OSGi metadata. And it doesn't solve the class and resource loading problems. It is the very objective of this Jira issue to provide this OSGi metadata and proper class loading in an OSGi environment out of the box.
> Conclusion: The best we can do from myfaces side is use
> org.apache.felix maven-bundle-plugin to create a manifest in the way
> described before without include BundleActivator classes, and let
> this issue open, so if somebody wants to use the BundleActivator way,
> he/she can change the code adding it. The only thing left is set the
> context class loader for Digester instances to
> org.apache.myfaces.shared_impl.util.ClassUtils.getContextClassLoader().
If we have a look at what is causing this troubles it shows that the API bundle isn't purely API but contains some key implementation classes like javax.faces.FacesServlet or javax.faces.FactoryFinder. This leads to the point that the API bundle has to have some knowledge about the implementation and it has to know how to load the respective factory classes.

Felix Röthenbacher
added a comment - 28/Oct/09 21:51 Leonardo,
just to make you aware of an issue when testing with Apache Felix:
http://felix.apache.org/site/apache-felix-framework-faq.html
Let me know if it works despite the FAQ stating fragment bundles with imports are not supported yet. Would be awesome to have an alternative OSGi container than Equinox to test on.

The first one is the patch corrected for osgi without activator, just as reference, because I'll commit this patch.

The second one is an example hello world app using maven pax plugin, that setup an enviroment to test this issue.

I spent a lot of time on this issue, and the conclussion was the most difficult part in this issue is find the correct configuration to make it work. This includes, create/find the proper bundles to make work servlet/jsp container in osgi and myfaces dependences and then wire everything in a way that other people can reproduce it with some considerations.

First it is necessary to add some jar files available on spring dm distribution:

It start an equinox osgi container and download all necessary dependences.

With this stuff I can finally commit the patch proposed. Note that I agree this is not an osgi full solution to this issue, by the problems described before, but it is the best we can do at this time.

To be clear with the problem related to apply the first patch proposed, the following ideas must be taken into account:

In the first patch, the class extending BundleActivator is responsible to indicate if we are or not in a osgi container and if so, do not use Thread.getContextClassLoader() and use bundle class loader instead.

There are other efforts to deal with this issue outside myfaces like Equinox buddy class loading policy, or Knopplerfish bytecode patching (create a new bundle fixing the original one at bytecode level). It seems that context class loader behavior will be normalized in a future version of OSGi.

For now, I'll commit the last patch proposed (MYFACES-2290-no-activator-2.patch). Unfortunately I can't dedicate more time to this issue for now. Anyway I'll let this issue open while we found more alternatives to this problem.

Leonardo Uribe
added a comment - 03/Nov/09 19:23 I have attached two files:
The first one is the patch corrected for osgi without activator, just as reference, because I'll commit this patch.
The second one is an example hello world app using maven pax plugin, that setup an enviroment to test this issue.
I spent a lot of time on this issue, and the conclussion was the most difficult part in this issue is find the correct configuration to make it work. This includes, create/find the proper bundles to make work servlet/jsp container in osgi and myfaces dependences and then wire everything in a way that other people can reproduce it with some considerations.
First it is necessary to add some jar files available on spring dm distribution:
catalina.start.osgi-1.0.0.jar --> inside spring-osgi-1.2.0-with-dependencies.zip spring-osgi-1.2.0\lib
catalina.configuration-1.2.0.jar --> Compile spring-osgi-1.2.0\src\samples\web-console\catalina.config maven project. It allows use tomcat 6.0.x with spring-dm
To run this just type on the downloaded file:
mvn clean install -PpaxConfig pax:provision
It start an equinox osgi container and download all necessary dependences.
With this stuff I can finally commit the patch proposed. Note that I agree this is not an osgi full solution to this issue, by the problems described before, but it is the best we can do at this time.
To be clear with the problem related to apply the first patch proposed, the following ideas must be taken into account:
In the first patch, the class extending BundleActivator is responsible to indicate if we are or not in a osgi container and if so, do not use Thread.getContextClassLoader() and use bundle class loader instead.
There are other efforts to deal with this issue outside myfaces like Equinox buddy class loading policy, or Knopplerfish bytecode patching (create a new bundle fixing the original one at bytecode level). It seems that context class loader behavior will be normalized in a future version of OSGi.
For now, I'll commit the last patch proposed ( MYFACES-2290 -no-activator-2.patch). Unfortunately I can't dedicate more time to this issue for now. Anyway I'll let this issue open while we found more alternatives to this problem.

Felix Röthenbacher
added a comment - 03/Nov/09 20:18 Hi Leonardo
I had a look at your patch and noticed that you enforce javax.el to be version 1.0. I had all sort if issues with this
(see also https://issuetracker.springsource.com/browse/EBR-408 or http://jira.springframework.org/browse/SPR-6265 )
as other bundles require javax.el in version 2.1. Could you please change your patch accordingly to allow javax.el version
2.1 as well.
Cheers, Felix

Ivan
added a comment - 25/Nov/09 06:38 Hi, since 2.0-snapshot is to support JSF 2.0, which is a component of jee 1.6, should the javax.servlet;version="[2.5.0, 3.0.0)" be updated to javax.servlet;version=" [2.5.0, 3.0.0] " ?

The attached patch changes the osgi metadata installed by the maven-bundle-plugin so that myfaces can be used with osgi bundles with normal package versioning for javaee6, mostly allowing use of a servlet 3.0 spec jar. Note that this does not affect the ability to use myfaces 2 with earlier spec jars, it only allows myfaces to be used in ee6 containers that run under osgi.

David Jencks
added a comment - 21/Dec/09 09:39 The attached patch changes the osgi metadata installed by the maven-bundle-plugin so that myfaces can be used with osgi bundles with normal package versioning for javaee6, mostly allowing use of a servlet 3.0 spec jar. Note that this does not affect the ability to use myfaces 2 with earlier spec jars, it only allows myfaces to be used in ee6 containers that run under osgi.
Geronimo integration of myfaces 2 cannot proceed without this patch.

I was able to run myfaces with this configuration, but doing some very nasty hacks that can't be committed.

The most critical problem to make run jsf in osgi is the class javax.faces.FactoryFinder. This class is responsible to load the factories used to setup the environment. The problem is it depends on the thread context classloader in a way that we just cannot bypass it.

In other words, JSF uses Thread.currentThread().getContextClassLoader() to obtain the web context classloader. The problem is OSGi doesn't have this concept in its HttpService definition. But in theory this could be solved creating a custom classloader that wraps the context classloader but also use the bundle classloader of the web application, allowing the user to bypass the bundle restriction. Unfortunately I tried this solution but pax uses a classloader to make jsp works, so any call to getFactory() fails, because the context classloader was replaced (PAXWEB-98). In theory, with this hack it is possible to run an application using facelets.

Unfortunately, I can't dedicate more time to this one. Anyway, I think if it is possible to do more tests with equinox (in theory myfaces 1.2 could run in servlet 2.4, jsp 2.0 and facelets), or maybe fix pax web to allow myfaces works there.

Leonardo Uribe
added a comment - 17/Mar/10 18:17 I tried to run myfaces in OSGi, but without spring-dm, just to see what are the problems that spring-dm are solving and check if we can do something else from our code to be more osgi friendly.
For do that, I tried to use pax web extender. Equinox only support jsp 2.0, so we can't use it to test what we want to.
An issue in pax web was opened:
http://issues.ops4j.org/browse/PAXWEB-199
that code hides some packages that needs to be exported, because contains serializable classes, so myfaces can see them. Also, it was notice another issue is there:
http://issues.ops4j.org/browse/PAXWEB-98
I was able to run myfaces with this configuration, but doing some very nasty hacks that can't be committed.
The most critical problem to make run jsf in osgi is the class javax.faces.FactoryFinder. This class is responsible to load the factories used to setup the environment. The problem is it depends on the thread context classloader in a way that we just cannot bypass it.
In other words, JSF uses Thread.currentThread().getContextClassLoader() to obtain the web context classloader. The problem is OSGi doesn't have this concept in its HttpService definition. But in theory this could be solved creating a custom classloader that wraps the context classloader but also use the bundle classloader of the web application, allowing the user to bypass the bundle restriction. Unfortunately I tried this solution but pax uses a classloader to make jsp works, so any call to getFactory() fails, because the context classloader was replaced (PAXWEB-98). In theory, with this hack it is possible to run an application using facelets.
Unfortunately, I can't dedicate more time to this one. Anyway, I think if it is possible to do more tests with equinox (in theory myfaces 1.2 could run in servlet 2.4, jsp 2.0 and facelets), or maybe fix pax web to allow myfaces works there.

Leonardo, as an outsider on the OSGI thing, we route already everything through our shared ClassUtils.forName.
I added a pluggable loading architecture to that one to bypass the classloader issues in web containers, you might use
the loader plugin mechanism which allows to plug in other loaders from outside at startup (or manually by using the api)
for the OSGI classloading issues as well, because then you can route the forName through the OSGI loading mechanism instead of having
a fixed dependency into the context loaders.

Werner Punz
added a comment - 17/Mar/10 18:33 Leonardo, as an outsider on the OSGI thing, we route already everything through our shared ClassUtils.forName.
I added a pluggable loading architecture to that one to bypass the classloader issues in web containers, you might use
the loader plugin mechanism which allows to plug in other loaders from outside at startup (or manually by using the api)
for the OSGI classloading issues as well, because then you can route the forName through the OSGI loading mechanism instead of having
a fixed dependency into the context loaders.

I forget to say, it was also committed some fixes to make myfaces code more friendly with osgi, including add a Require-Bundle header, so myfaces-api bundle can find myfaces-impl using the bundle classloader.

Leonardo Uribe
added a comment - 17/Mar/10 18:33 I forget to say, it was also committed some fixes to make myfaces code more friendly with osgi, including add a Require-Bundle header, so myfaces-api bundle can find myfaces-impl using the bundle classloader.

I am about to commit jsp-2.1 and jstl-1.2 support in eclipse orbit. I am also working on jetty-osgi.
I have managed to run myfaces 1.2.8 with jetty-osgi inside equinox and without dependencies on spring.
I had to repackage myfaces bundles to avoid the split-package mentionned be Felix on the comment "28/Oct/09 01:07 AM".

jetty-osgi does set the context classloader during the execution of the servlets.
So as along as myfaces required packages are imported by the consumer bundle or as long as they are injected by a fragment into the jetty.osgi.bootstrap bundle, they will be nicely resolved.

If you can remove the split-package that would certainly be a good step to support OSGi.

Hugues Malphettes
added a comment - 17/Mar/10 18:34 Hi Leonardo,
I am about to commit jsp-2.1 and jstl-1.2 support in eclipse orbit. I am also working on jetty-osgi.
I have managed to run myfaces 1.2.8 with jetty-osgi inside equinox and without dependencies on spring.
I had to repackage myfaces bundles to avoid the split-package mentionned be Felix on the comment "28/Oct/09 01:07 AM".
jetty-osgi does set the context classloader during the execution of the servlets.
So as along as myfaces required packages are imported by the consumer bundle or as long as they are injected by a fragment into the jetty.osgi.bootstrap bundle, they will be nicely resolved.
If you can remove the split-package that would certainly be a good step to support OSGi.

Jakob did that, so the latest code does not have this problem anymore. It could be good to know what you did when you repackage myfaces bundles. The idea is make easier for users. Actually, we have very few examples (2, and only one works without problems), and if we can put an example using equinox it will be a big help. Really, if we can get this example, it would be great to create an archetype of this stuff.

Leonardo Uribe
added a comment - 17/Mar/10 18:56 Jakob did that, so the latest code does not have this problem anymore. It could be good to know what you did when you repackage myfaces bundles. The idea is make easier for users. Actually, we have very few examples (2, and only one works without problems), and if we can put an example using equinox it will be a big help. Really, if we can get this example, it would be great to create an archetype of this stuff.

I can help with testing and creating MyFaces examples. Have you committed jsp-2.1, jstl-1.2 and jetty-osgi bundles to Orbit? It will be great if you can provide minimal instructions to test your work and I will be glad to test it.

Raj Saini
added a comment - 23/Mar/10 15:19 Hi Hugues,
I can help with testing and creating MyFaces examples. Have you committed jsp-2.1, jstl-1.2 and jetty-osgi bundles to Orbit? It will be great if you can provide minimal instructions to test your work and I will be glad to test it.

Hugues Malphettes
added a comment - 23/Mar/10 16:57 Hi Raj, thanks for the offer. Sorry for not reacting faster here.
We are still working on adding those to orbit: https://bugs.eclipse.org/bugs/show_bug.cgi?id=304891
Let me cleanup the target-platform I have been using to test things.

Leonardo Uribe
added a comment - 21/Feb/11 18:56 MYFACES-2995 is not OSGi specific, but to solve OSGi support we need it fixed. After close that one, we can close this issue, because all SPI interfaces required will be complete.