dev@javaserverfaces.java.net

Re: [REVIEW] ConfigureListener - check for FacesServlet before performing faces configuration steps

From: Ed Burns <Ed.Burns_at_Sun.COM>
Date: Wed, 23 Feb 2005 09:01:50 -0800

>>>>> On Thu, 17 Feb 2005 13:30:20 -0800, Ed Burns <ed.burns_at_sun.com> said:

>>>>> On Thu, 17 Feb 2005 15:42:01 -0500, Ryan Lubke <Ryan.Lubke_at_Sun.COM> said:
RL> Consider the case where JSF is installed in the common classloader of
RL> Tomcat, or SJSAS.
RL> With this configuration, the ConfigureListener will be invoked for every
RL> web application
RL> whether or not it uses JSF.

RL> This modification to ConfigureListener will process the web.xml of the
RL> current web application
RL> scanning for the presence of javax.faces.webapp.FacesServlet. If found,
RL> perform the normal
RL> application processing, otherwise return.

EB> As it turns out, an app is not required to map the FacesServlet by the
EB> spec.

To bring some closure to this issue, Ryan is implementing an RI-only
change-bundle, and I'm going to bring the following proposal to the
JSR-252-EG. This is a restatement of what we discussed earlier in the
thread, as Ryan found in the spec.

[51-StartupTime]

    The current spec, in section 10.1, says:

      Portable JSF-based web applications must include the following
      configuration elements, in the appropriate portions of the web
      application deployment descriptor. Element values that are rendered
      in italics represent values that the application developer is free to
      choose. Element values rendered in bold represent values that must be
      utilized exactly as shown.

      [...]

      Section 10.1.1 Servlet Definition

      [...]

      <servlet-class>
        [bold]javax.faces.webapp.FacesServlet[bold]
      </servlet-class>

      [...]

    Because the spec says the app must define the FacesServlet, and
    because the FacesServlet is a final class, we can use Ryan's robust
    heuristic to limit the runtime impact of a Faces Impl's config
    system on webapps that do not use faces. I'll add the following to
    section 10.3.2 Application Startup Behavior, right at the beginning.

      Implementations may check for the presence of a servlet-class
      definition for javax.faces.webapp.FacesServlet in the web
      application deployment descriptor as a means to abort the
      configuration process and save startup time for applications that
      do not use Faces technology.

Ed

-- 
| ed.burns_at_sun.com  | {home: 407 294 2468, office: 408 884 9519 OR x31640}
| homepage:         | http://javaweb.sfbay.sun.com/~edburns/
| aim: edburns0sunw | iim: ed.burns_at_sun.com