David, the new lifecycle framework which allows Geronimo to handle instantiating JSF managed beans and also perform dependency injection is a tremendous improvement for the myfaces integration. Thanks for all your help and direction on this. IIUC the myfaces integration for jetty is now functionally complete and we're ready to focus on stamping out the bugs in that assembly. I will also work on improving the test case at testsuite/web-testsuite/test-myfaces so that we can keep an eye on overall JSF functionality (including dependency injection) as we move forward.
For the tomcat assembly, I'm particularly curious about what kind of changes you have in mind for selectively adding the myfaces context listener only to webapps that require JSF support. Am I understanding your intentions correctly? If so should we merge the context listener into their web.xml if and only if the Faces servlet is present? Also, do you intend to add the myfaces classes directly to the webapp's classloader instead of the current approach which relies on them being available in a parent configuration of the tomcat and jetty configs? If so then we could reconsider the specialized MultiParentClassLoader searching for TLDs that we have in place right now. We might end up deciding to leave that in place but we should at least think about it... One more thing I wanted to make you aware that Kevan recently found a memory leak in Geronimo caused by the myfaces FactoryFinder holding a reference to a webapp's classloader after the webapp has been stopped. Since at that time JSF support was provided for all webapps (regardless of whether or JSF was actually required) we decided to call javax.faces.FactoryFinder.releaseFactories() whenever a webapp is stopped. See TomcatWebAppContext:517 and JettyWebAppContext:359. If JSF support is selectively applied to webapps then we may need to be more careful about calling that method. Also since this is a static method the classloader configuration will also affect how/when/where we call this method. Best wishes, Paul On 3/14/07, David Jencks <[EMAIL PROTECTED]> wrote:
I have the jetty-myfaces integration working with the object lifecycle contract we negotiated with the myfaces team, and I've straightened out the classloaders so that myfaces is included only if you in fact are using jsf. I'm about to commit this work, but it will break the tomcat jsf integration a bit for a couple of days. The reason is that the current integration relies on myfaces being in the same classloader as tomcat, which is obviously not compatible with the idea of adding myfaces to the app classloader only if its needed. You should be able to make a jsf app work by pretending it's not a jsf 1.2 app, i.e. including the myfaces ServletContextListener in your web.xml explicitly. We don't really have any good tests but dependency injection into jsf managed beans should be working in jetty now (after my commit). I'm going to look into dependency injection in tomcat next, and then hook up myfaces similarly, so this "outage" should be pretty short. thanks david jencks
