Package org.ops4j.pax.web.jsp

Class JasperInitializer

  • All Implemented Interfaces:
    javax.servlet.ServletContainerInitializer
    public class JasperInitializer
extends org.apache.jasper.servlet.JasperInitializer

    Pax Web extends original initializer, so it is possible to override the TldScanner.

    This initializer is declared in /META-INF/services/javax.servlet.ServletContainerInitializer for pax-web-extender-war purpose. For Whiteboard and HttpService purposes, it is used directly to configure the context(s) when JSP support is required.

    According to Servlet specification 8.3 "JSP container pluggability", JSP processing/parsing/setup is no longer performed by "Servlet container" itself and instead can be delegated to "JSP container" using ServletContainerInitializer mechanism.

    Neither Whiteboard (CMPN 140) nor HttpService (CMPN 102) specifications say anything about JSPs. The only relevant specification is "128 Web Applications Specification" which defines WABs (Web Application Bundles), but there is not many details about how exactly JSPs (and TLDs) should be supported.

    So we start with the asumption that CMPN 128 specification is about supporting WARs in OSGi runtime in very similar way to how they work in JavaEE environments. The most important common ground is how to use classloaders to find necessary resources. Details of how TLDs should be located are described inline below. Here's the outline: in JavaEE, WAR is associated with single classloader, which includes:

    • /WEB-INF/classes directory
    • each of the /WEN-INF/lib/*.jar
    In Whiteboard (HttpService), there's no such thing as WAR, there's only ServletContextHelper (HttpContext), which are customized internally into OsgiContextModel. These can be mixed in many ways with dynamic servlets, filters and other web elements. However, when we finally get to pax-web-extender-war, we have to marks some instance of OsgiContextModel as a context associated with WAB/WAR.

    Because there should be no such thing as classpath in OSGi application (only a mesh of bundles), an entry point to searching for TLDs should be a bundle. When this initializer is being passed an OsgiServletContext (associated with single OsgiContextModel) we'll get the owner bundle of such context (model). If it's a different implementation of ServletContext we'll look for osgi-bundlecontext context attribute according to "128.6.1 Bundle Context Access". When there's no such attribute, we'll explicitly do nothing.

    • Field Detail

      • LOG

        public static final org.slf4j.Logger LOG

    • Constructor Detail

      • JasperInitializer

        public JasperInitializer()

    • Method Detail

      • onStartup

        public void onStartup​(Set<Class<?>> types,
                      javax.servlet.ServletContext context)
               throws javax.servlet.ServletException
        Specified by:
        onStartup in interface javax.servlet.ServletContainerInitializer
        Overrides:
        onStartup in class org.apache.jasper.servlet.JasperInitializer
        Throws:
        javax.servlet.ServletException

      • newTldScanner

        protected org.apache.jasper.servlet.TldScanner newTldScanner​(javax.servlet.ServletContext context,
                                                             boolean namespaceAware,
                                                             boolean validate,
                                                             boolean blockExternal)
        Overrides:
        newTldScanner in class org.apache.jasper.servlet.JasperInitializer