On Mar 15, 2007, at 11:32 AM, Paul McMahan wrote:
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.
That would be fantastic!
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?
I'm hoping to find a way to do that that is as easy as it was for
jetty. There I didn't need to modify the web.xml, just add a string
to a list in a gbean attribute. Right now I'm seeing if I can come
up with a suggestion for tomcat to handle object lifecycle the way we
did in MyFaces. It looks like it might provide more uniform control
over filters, servlets, and listeners than they have now, so there's
a slight chance they might bite.
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...
That's my intention, and can you point me to the searching code you
are talking about?
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.
We shouldn't do that there, I'll look for the best place, and there's
another memory leak in FactoryFinder, see MYFACES-1558
thanks!
david jencks
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
