MyFaces Core
  1. MyFaces Core
  2. MYFACES-2290

Add OSGi bundle information and bundle classloader / activator

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.2.8-SNAPSHOT
    • Fix Version/s: 2.0.5
    • Component/s: General
    • Labels:
      None
    • Environment:
      OSGi (Equinox, Apache Felix, ...)

      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.

      1. myfaces-core.diff.txt
        24 kB
        Felix Röthenbacher
      2. myfaces-shared.diff.txt
        13 kB
        Felix Röthenbacher
      3. MYFACES-2290-no-activator.patch
        6 kB
        Leonardo Uribe
      4. myfaces-test-helloworld-osgi-springdm.zip
        13 kB
        Leonardo Uribe
      5. MYFACES-2290-no-activator-2.patch
        6 kB
        Leonardo Uribe
      6. allow-ee6-versioned-apis.diff
        2 kB
        David Jencks
      7. myfaces-test-helloworld-osgi-pax-web.zip
        32 kB
        Leonardo Uribe

        Issue Links

          Activity

          Hide
          Felix Röthenbacher added a comment -

          myfaces-core.diff.txt is the patch for MyFaces Core 1.2.8-SNAPSHOT. This patch also changes MyFaces Impl from using MyFaces Shared 3.0.6 to MyFaces Shared 3.0.7-SNAPSHOT.

          myfaces-shared.diff.txt is the patch for MyFaces Shared 3.0.7-SNAPSHOT

          Show
          Felix Röthenbacher added a comment - myfaces-core.diff.txt is the patch for MyFaces Core 1.2.8-SNAPSHOT. This patch also changes MyFaces Impl from using MyFaces Shared 3.0.6 to MyFaces Shared 3.0.7-SNAPSHOT. myfaces-shared.diff.txt is the patch for MyFaces Shared 3.0.7-SNAPSHOT
          Hide
          Andreas Hartmann-Schneevoigt added a comment -

          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.

          Show
          Andreas Hartmann-Schneevoigt added a comment - 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.
          Hide
          Martin Marinschek added a comment -

          Hi Leonardo,

          can you (or someone in the team) take this over high priority?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Hi Leonardo, can you (or someone in the team) take this over high priority? regards, Martin
          Hide
          Leonardo Uribe added a comment -

          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

          Show
          Leonardo Uribe added a comment - 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
          Hide
          Felix Röthenbacher added a comment -

          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.

          Show
          Felix Röthenbacher added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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

          Show
          Leonardo Uribe added a comment - 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
          Hide
          Felix Röthenbacher added a comment -

          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
          Show
          Felix Röthenbacher added a comment - 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
          Hide
          Martin Marinschek added a comment -

          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

          Show
          Martin Marinschek added a comment - 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
          Hide
          Felix Röthenbacher added a comment -

          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

          Show
          Felix Röthenbacher added a comment - 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
          Hide
          Leonardo Uribe added a comment -

          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().

          Show
          Leonardo Uribe added a comment - 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().
          Hide
          Leonardo Uribe added a comment -

          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).

          Show
          Leonardo Uribe added a comment - 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 ).
          Hide
          Felix Röthenbacher added a comment -

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

          Show
          Felix Röthenbacher added a comment - > 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.
          Hide
          Felix Röthenbacher added a comment -

          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.

          Show
          Felix Röthenbacher added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.
          Hide
          Felix Röthenbacher added a comment -

          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

          Show
          Felix Röthenbacher added a comment - 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
          Hide
          Leonardo Uribe added a comment -

          Hi Felix

          Ok. I have committed it to current12 trunk in this way:

          javax.el;version="[1.0.0, 3.0.0)"

          regards,

          Leonardo Uribe

          Show
          Leonardo Uribe added a comment - Hi Felix Ok. I have committed it to current12 trunk in this way: javax.el;version="[1.0.0, 3.0.0)" regards, Leonardo Uribe
          Hide
          Ivan added a comment -

          Is there a plan of adding OSGI bundle information for 2.0.0-SNAPSHOT ?

          Show
          Ivan added a comment - Is there a plan of adding OSGI bundle information for 2.0.0-SNAPSHOT ?
          Hide
          Leonardo Uribe added a comment -

          Today I have merged this issue in 2.0.x branch, so now the bundle information is generated in 2.0.0-SNAPSHOT

          Show
          Leonardo Uribe added a comment - Today I have merged this issue in 2.0.x branch, so now the bundle information is generated in 2.0.0-SNAPSHOT
          Hide
          Ivan added a comment -

          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]" ?

          Show
          Ivan added a comment - 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] " ?
          Hide
          David Jencks added a comment -

          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.

          Show
          David Jencks added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          The example using pax web, just for historical purposes

          Show
          Leonardo Uribe added a comment - The example using pax web, just for historical purposes
          Hide
          Werner Punz added a comment -

          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.

          Show
          Werner Punz added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.
          Hide
          Hugues Malphettes added a comment -

          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.

          Show
          Hugues Malphettes added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.
          Hide
          Raj Saini added a comment -

          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.

          Show
          Raj Saini added a comment - 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.
          Hide
          Hugues Malphettes added a comment -

          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.

          Show
          Hugues Malphettes added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.

            People

            • Assignee:
              Leonardo Uribe
              Reporter:
              Felix Röthenbacher
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development