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 <[EMAIL PROTECTED]> wrote:
On 3/15/07, David Jencks <[EMAIL PROTECTED]> 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
