[
https://issues.apache.org/jira/browse/MYFACES-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773136#action_12773136
]
Leonardo Uribe commented on MYFACES-2290:
-----------------------------------------
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.
> Add OSGi bundle information and bundle classloader / activator
> --------------------------------------------------------------
>
> Key: MYFACES-2290
> URL: https://issues.apache.org/jira/browse/MYFACES-2290
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
> Affects Versions: 1.2.8-SNAPSHOT
> Environment: OSGi (Equinox, Apache Felix, ...)
> Reporter: Felix Röthenbacher
> Assignee: Leonardo Uribe
> Priority: Critical
> Attachments: MYFACES-2290-no-activator-2.patch,
> MYFACES-2290-no-activator.patch, myfaces-core.diff.txt,
> myfaces-shared.diff.txt, myfaces-test-helloworld-osgi-springdm.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
