geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <>
Subject Re: I'm going to break "automatic" tomcat jsf support for a couple of days
Date Thu, 15 Mar 2007 15:32:51 GMT
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,

On 3/14/07, David Jencks <> 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

View raw message