Jan-Kees van Andel schrieb:
I like the OSGi support very much, as long as the standard, classpath based, approach doesn't break or in other ways degrades in quality (i.e. performance).
Standard class loading isn't affected by my solution. The bundle classloader is bypassed when not running in an OSGi container.
In other words, OSGi is nice, but I think the current approach should remain the #1 priority.
This is clearly a priority. Yet, it would be nice to have MyFaces available as a bundle which can be deployed to an OSGi container without any need for custom modifications to get it running. - Felix
/Jan-Kees 2009/7/9 Bernhard Huemer <[email protected]>:Hi, as I've announced something similar a few weeks ago (due to a disease, however, I didn't have the time to contribute these changes yet), I'm wondering how you implemented that with "some modifications"? For example, Facelets built-in components (<h:form>, ...) didn't work for me as Facelets doesn't know how to parse bundles. Of course, a bundle is basically just a plain JAR file, but the resource URL of those JAR files start with "bundle://" instead of "jar://" or something similar which Facelets doesn't recognize properly, hence it won't the taglibs. Additionally the default Facelets view resource loader assumes that the views can be accessed using the ExternalContext (i.e. it's assuming that it's deployed within a proper WAR file, which isn't the case). Therefore I had to implement a custom Facelets resource loader as well. How do you know which bundle to use for class loading when parsing an expression string like "#{bean.propery}", where bean is a managed bean? Don't you map beans to bundles somehow? At least I assume that you don't based on the statement that the class loading problem requires just some "small modifications to ClassUtil". Additionally I've struggled with the dependencies of MyFaces as well, for example, all those common-* projects, as they don't provide bundle information within their manifest files and hence aren't recognized by the OSGi container. However, somehow these classes have to be accessible and therefore I have created another Maven plugin that embeds these dependencies if the developer wants to create a OSGi compatible MyFaces build. Basically it just creates a folder called "/META-INF/lib/" similar to "/WEB-INF/lib/" and uses the manifest file statement "Bundle-ClassPath" to load those libraries. ... Don't get me wrong, if you really just require a few changes, then feel free to contribute them, but I doubt that those changes are sufficient. However, in order to ensure that we're not talking at cross-purposes, please describe your execution environment a little bit more. It seems that you're using Equinox, does Equinox provide an OSGi HTTP service implementation on it's own? How does deployment work, i.e does the OSGi HTTP service implementation know how to parse a web.xml file, or do you have to register the FacesServlet programmatically somehow? regards, Bernhard Am 9. Juli 2009 06:22 schrieb Felix Röthenbacher <[email protected]>:Hi I recently made some modifications to MyFaces Core and MyFaces Trinidad to get it running in an OSGi container (Equinox) together with Facelets. I wonder if there is any interest in adding bundle metadata to MyFaces Core and Trinidad to make them runnable in an OSGi environment? If so, I could finalize my modifications and submit a patch with the necessary changes. Basically, the changes include: - adding bundle information in MANIFEST.MF (uses Maven bundle plugin) - assure that classes and resources are loaded with proper class loaders The changes to MyFaces core are minor, e.g. adding a bundle activator and small modifications to ClassUtil for class loading. Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to load classes and resources. Currently, often Thread.currentThread.getContextClassLoader() is used directly, which doesn't work well in an OSGi environment. WDYT? - Felix
