[
https://issues.apache.org/jira/browse/MYFACES-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771125#action_12771125
]
Felix Röthenbacher commented on MYFACES-2290:
---------------------------------------------
> 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.
> 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.patch, myfaces-core.diff.txt,
> myfaces-shared.diff.txt
>
>
> 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.
