geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: I'm going to break "automatic" tomcat jsf support for a couple of days
Date Thu, 15 Mar 2007 18:01:07 GMT
One more thing I just thought of, regarding adding the myfaces classes
directly to a webapp's classloader...

The JSF 1.2 spec says :
"Note that Faces is a part of the Java EE platform as of Faces 1.2. A
web application
therefore does not need to bundle a Faces implementation anymore when
it runs on a web
container that is Java EE technology compliant. Should a Faces
implementation be
bundled with a web-application, it will simply be ignored as the Faces
implementation
provided by the platform always takes precedence."

This prompted me to add org.apache.myfaces.* to the list of
non-overrideable classes for webapps deployed into tomcat or jetty.
javax.* was of course already in that list.  See
tomcat6-deployer/src/plan/plan.xml:73 and
jetty6-deployer/src/plan/plan.xml:91.   If we move the myfaces classes
from the parent config to the webapp's classloader then would this
configuration of non-overrideable classes actually prevent them from
being seen?

Earlier on when I first started looking at myfaces I was seeing lots
of problems due to jasper and myfaces living in separate classloaders.
 I think there are some assumptions about having a relatively flat
classloader hierarchy in the overall myfaces/jasper/tomcat design that
can lead to some difficulties in a more complex classloader like
Geronimo's.

Best wishes,
Paul

On 3/15/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
> On 3/15/07, David Jencks <david_jencks@yahoo.com> wrote:
> > > 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?
>
> The specialized TLD searching code that I am referring to was introduced here:
> http://svn.apache.org/viewvc?view=rev&revision=517712
>
> The basic problem was that by default Jasper looks for TLDs in the
> webapp's classloader and then looks for TLDs in its parent
> classloaders by calling ClassLoader.getParent().    This technique
> works in standalone tomcat and in other containers that have simpler
> ClassLoader structure.  But in Geronimo this technique does not locate
> the JSF TLDs in classloaders of the webapp's parent configurations
> because those classloaders can only be reached via Geronimo's
> MultiParentClassLoader.getParents().
>
> If we now decide to add the MyFaces jars (and their dependencies?)
> directly to the webapp's classloader at deployment time then I think
> Jasper's default technique for locating TLDs might suddenly work.  But
> that doesn't necessarily mean we should remove the specialized TLD
> searching that Geronimo now provides to Jasper because it allows
> Jasper to find, for example, the JSTL TLD in a webapp's parent
> configurations.
>
> Best wishes,
> Paul
>

Mime
View raw message