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
>
|