Hi again, > Hope you have recovered and all is well.
Thanks, I'm fine at the moment. :-D > Here you are talking about using Facelets as a bundle, which is another > story. My mail referred to modifications to MyFaces Core and Trinidad. > My expression "some modifications" is related to MyFaces Core and Trinidad, > not Facelets. > > I'm not sure what you mean with h:form is a built-in Facelets component? > I assume that you mean Facelets needs a way to parse taglibs from > other bundles like Myfaces Core and Trinidad. Just a short summary > of the way I deal with Facelets. First, I didn't find a bundled version > for Facelets version 1.1.14. So I re-package it myself adding the necessary > metadata. Neither have I changed anything about Facelets, but somehow one has to adapt its usage in an OSGi container, because it won't work without. However, if I'm not mistaken you are using Facelets as a bundle since you've repackaged it in order to add the necessary metadata, but nevermind. > Facelets uses the ContextClassLoader quite often. Luckily, there are > well defined entry points into the Facelets bundle which is the > FaceletViewHandler. I wrote a wrapper for FaceletViewHandler which sets > the ContextClassLoader of the current thread to an appropriate bundle > classloader. Hence, resources are loaded through this bundle classloader. Okay, that's something I've missed so far, however, as I've already mentioned there is another problem. Even if Facelets uses the correct bundle classloader it won't find any taglibs because of the resource URL format. I don't know if this is standard OSGi behaviour or not, but resources within an OSGi bundle start with "bundle://" instead of "jar://" which Facelets doesn't recognize and hence doesn't parse (at least that's the case for Apache Felix). That's what I've meant by saying that those built-in components didn't work for me as Facelets wasn't even able to parse its internal taglib files and so the HTML output contained non-processed "<h:form>" tags and so on. > Class loading for beans is done through the bundle classloader. If > you declare your bean packages properly in your MANIFEST.MF this > class loader will find it. Let's clarify this, please. First of all I assume that there are separate bundles for the MyFaces API, the MyFaces implementation and your web application (Facelets, etc. doesn't matter in this case). The MyFaces implementation bundle is responsible for instantiating the beans, but which bundle classloader are you talking about then? - The web application bundle classloader: During start-up the web application bundle somehow initializes MyFaces and in the course of this the web application somehow "injects" its own bundle classloader to, among others, the managed bean facility so that it has got access to the bean classes. However, if that would be the case, there's no need to declare anything in the manifest file, hence I doubt that you've chosen this approach. If I'm mistaken, please feel free to correct me, then we can discuss this approach in more detail (Btw. I've chosen this approach). - The MyFaces implementation bundle classloader: The managed bean facility, again amongst others, uses the bundle classloader of its own bundle. In doing so it has got access only to the classes within the implementation bundle - which doesn't help at all regarding managed beans - and to packages being exported by other bundles. That would explain your need for declaring bean packages properly in the manifest file. However, again, if I'm not mistaken exporting packages is not sufficient as MyFaces will have to import them as well. Are you suggesting that web application developers have to "customize" the MyFaces implementation bundle by adapting the imports every time they create new managed beans? > - Equinox as OSGi container > - HTTP service is provided by Tomcat. Could also be Jetty but > I didn't manage to setup a working environment in combination > with JSP (though PAX web apparently provides one). > - I use Spring DM tools for WAR deployment. A similar solution > exists from PAX Web for Jetty. So, you don't use the OSGi HTTP service API [1] at all? Seems that your OSGi environment is capable of parsing a web.xml file, which I think isn't standard behaviour. However, I think it's acceptable if it works for major OSGi containers (haven't tried Equinox and the Spring DM tools yet). Additionally it seems that you're more or less talking about the deployment of a WAR file, i.e. the whole web application consists of a single archive file with the only difference that you don't have to embed the dependencies within it as OSGi is responsible for resolving dependencies. However, I've intended to adapt MyFaces in a way so that it's possible to split even the web application into separate bundles, where each bundle is able to define its own JSF configuration file, etc. In doing so, each bundle provides just a part of the resulting web application, which means that you can reuse these parts in different web applications. However, I'm not too sure if such a feature is really required or if I've over-engineered the whole OSGi support thingy a little bit. regards, Bernhard [1]: http://www.osgi.org/javadoc/r4v41/org/osgi/service/http/HttpService.html Am 10. Juli 2009 03:20 schrieb Felix Röthenbacher <froethenbac...@apache.org>: > Bernhard Huemer schrieb: >> >> 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"? > > Hope you have recovered and all is well. > >> >> 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. > > Here you are talking about using Facelets as a bundle, which is another > story. My mail referred to modifications to MyFaces Core and Trinidad. > My expression "some modifications" is related to MyFaces Core and Trinidad, > not Facelets. > > I'm not sure what you mean with h:form is a built-in Facelets component? > I assume that you mean Facelets needs a way to parse taglibs from > other bundles like Myfaces Core and Trinidad. Just a short summary > of the way I deal with Facelets. First, I didn't find a bundled version > for Facelets version 1.1.14. So I re-package it myself adding the necessary > metadata. > > Facelets uses the ContextClassLoader quite often. Luckily, there are > well defined entry points into the Facelets bundle which is the > FaceletViewHandler. I wrote a wrapper for FaceletViewHandler which sets > the ContextClassLoader of the current thread to an appropriate bundle > classloader. Hence, resources are loaded through this bundle classloader. > >> >> 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". > > Class loading for beans is done through the bundle classloader. If > you declare your bean packages properly in your MANIFEST.MF this > class loader will find it. > >> >> 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. >> >> ... > > I use bundled versions of these libraries rather than embedding them > in my war bundle. You can find these bundles in various bundle repositories. > >> >> 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? > > Your question seems to be geared towards how to setup and run a working > OSGi environment. Despite this is probably not the right mailing list > just a few hints: > > - Equinox as OSGi container > - HTTP service is provided by Tomcat. Could also be Jetty but > I didn't manage to setup a working environment in combination > with JSP (though PAX web apparently provides one). > - I use Spring DM tools for WAR deployment. A similar solution > exists from PAX Web for Jetty. > > Actually, from my own experience, setting up a running OSGi environment > for your needs can be quite tricky and cumbersome. > > > - Felix > >> >> regards, >> Bernhard >> >> Am 9. Juli 2009 06:22 schrieb Felix Röthenbacher >> <froethenbac...@apache.org>: >>> >>> 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 >>> > >
