Package org.ops4j.pax.web.service

Interface WebContainerContext

  • All Superinterfaces:
    org.osgi.service.http.HttpContext
    All Known Subinterfaces:
    MultiBundleWebContainerContext
    public interface WebContainerContext
extends org.osgi.service.http.HttpContext

    HttpContext extension that adds:

    • identity (String ID) to HttpContext (knowing that single bundle using such context is part of the identity)
    • missing resource-access method matching ServletContext.getResourcePaths(String) method.
    • shared flag

    All methods returning a context in WebContainer extension of HttpService return implementations of this interface.

    No extension of the original HttpContext should specify such things as context path, virtual hosts or parameters - these (to match Whiteboard specification) should be specified using service registration paremeters or (legacy Pax Web method) in org.ops4j.pax.web.service.whiteboard.HttpContextMapping service or (legacy and not recommended) org.ops4j.pax.web.service.whiteboard.ServletContextHelperMapping.

    Internally, Pax Web will wrap Whiteboard's ServletContextHelper instances in some implementation of WebContainerContext interface.

    Since:
    0.5.3, March 30, 2009
    Author:
    Alin Dreghiciu ([email protected])

    • Field Summary

      • Fields inherited from interface org.osgi.service.http.HttpContext

        AUTHENTICATION_TYPE, AUTHORIZATION, REMOTE_USER

    • Method Summary

      All Methods Instance Methods Abstract Methods Default Methods 
      Modifier and Type Method Description
      void finishSecurity​(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response)
      Method that backports ServletContextHelper.finishSecurity(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) into old HttpContext
      org.osgi.framework.Bundle getBundle()
      Actual bundle on behalf of which the WebContainerContext was created.
      String getContextId()
      Returns the name (identifier) of this context.
      default String getRealPath​(String path)
      Method matching ServletContext.getRealPath(String) and ServletContextHelper.getRealPath(String), but not available in original HttpContext.
      Set<String> getResourcePaths​(String path)
      Complement HttpContext.getResource(String) (that matches ServletContext.getResource(String)), so we have a method matching ServletContext.getResourcePaths(String).
      boolean isShared()
      Should this context (as defined in "102 Http Service" specification, not in "140 Whiteboard Service" specification) be allowed to be used by different bundles?

      • Methods inherited from interface org.osgi.service.http.HttpContext

        getMimeType, getResource, handleSecurity

    • Method Detail

      • getResourcePaths

        Set<String> getResourcePaths​(String path)

        Complement HttpContext.getResource(String) (that matches ServletContext.getResource(String)), so we have a method matching ServletContext.getResourcePaths(String).

        from ServletContext javadoc: Returns a set of all the paths (String objects) to entries within the web application whose longest sub-path matches the supplied path argument. A specified path of "/" indicates the root of the web application.

        Whether this method reaches to embedded JARs, attached fragments or reachable bundles is dependant on the implementation and actual Pax Web component used:

        • In Whiteboard scenario we delegate to ServletContextHelper.getResourcePaths(java.lang.String)
        • In HttpService scenario

        Even if not specified by OSGi CMPN, this method also returns resources relative to all /WEB-INF/lib/*.jar!/META-INF/resources/ if the bundle is WAB.

        Parameters:
        path - the path name for which to return resource paths. Just as in ServletContext.getResourcePaths(String), the path must start with /
        Returns:
        a set of the resource paths (String objects) or null if no resource paths could be found or if the caller does not have the appropriate permissions.

      • getRealPath

        default String getRealPath​(String path)

        Method matching ServletContext.getRealPath(String) and ServletContextHelper.getRealPath(String), but not available in original HttpContext.

        As in Javadoc for ServletContext.getRealPath(String): Resources inside the /META-INF/resources directories of JAR files bundled in the application's /WEB-INF/lib directory must be considered only if the container has unpacked them from their containing JAR file, in which case the path to the unpacked location must be returned. Thus default (in Pax Web) implementations of the contexts return null. There's no point to deal with real path in OSGi environment.

        Parameters:
        path -
        Returns:

      • finishSecurity

        void finishSecurity​(javax.servlet.http.HttpServletRequest request,
                    javax.servlet.http.HttpServletResponse response)
        Method that backports ServletContextHelper.finishSecurity(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) into old HttpContext
        Parameters:
        request -
        response -

      • getContextId

        String getContextId()

        Returns the name (identifier) of this context.

        Such context may then be referenced using:

        • standard (Whiteboard) osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=name) service registration property (140.3 Common Whiteboard Properties)
        • standard (Whiteboard) osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.httpservice=name) service registration property (140.10 Integration with Http Service Contexts)
        • legacy (Pax Web specific) httpContext.id=name service registration property
        • ContextRelated.getContextSelectFilter() on registered mappings
        • ContextRelated.getContextId() on registered mappings

        There's security concern related to String identification of context - both for HttpService.registerServlet(java.lang.String, javax.servlet.Servlet, java.util.Dictionary<?, ?>, org.osgi.service.http.HttpContext) and whiteboard approach. If (as Pax Web allows) shared context is used, there should be no way of accessing resources from one bundle by another bundle. Whiteboard specification is more clear about it - resources are loaded from the bundle registering (publishing) ServletContextHelper service and there's assumed sharing of the context between bundles. That's why user chosing MultiBundleWebContainerContext has to be aware of opening an access to all bundles sharing such context.

        Returns:
        name of the Context

      • isShared

        boolean isShared()

        Should this context (as defined in "102 Http Service" specification, not in "140 Whiteboard Service" specification) be allowed to be used by different bundles?

        In Whiteboard Service scenario (to wrap ServletContextHelper) the context should be shared by default and there's no real way to make a context not shared.

        In Http Service scenario, but default, a context is not shared. It means that if a web element is being registered through such context, but with different bundle, exception should be thrown.

        Returns:

      • getBundle

        org.osgi.framework.Bundle getBundle()
        Actual bundle on behalf of which the WebContainerContext was created. It SHOULD be null for shared contexts.
        Returns: