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).
In other words, OSGi is nice, but I think the current approach should remain the #1 priority. /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 >> >
