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 ofHttpService
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) inorg.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 ofWebContainerContext
interface.- Since:
- 0.5.3, March 30, 2009
- Author:
- Alin Dreghiciu ([email protected])
-
-
Nested Class Summary
Nested Classes Modifier and Type Interface Description static class
WebContainerContext.DefaultContextIds
Default context identifiers.
-
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 backportsServletContextHelper.finishSecurity(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
into oldHttpContext
org.osgi.framework.Bundle
getBundle()
Actual bundle on behalf of which theWebContainerContext
was created.String
getContextId()
Returns the name (identifier) of this context.default String
getRealPath(String path)
Method matchingServletContext.getRealPath(String)
andServletContextHelper.getRealPath(String)
, but not available in originalHttpContext
.Set<String>
getResourcePaths(String path)
ComplementHttpContext.getResource(String)
(that matchesServletContext.getResource(String)
), so we have a method matchingServletContext.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?
-
-
-
Method Detail
-
getResourcePaths
Set<String> getResourcePaths(String path)
Complement
HttpContext.getResource(String)
(that matchesServletContext.getResource(String)
), so we have a method matchingServletContext.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 inServletContext.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.
- In Whiteboard scenario we delegate to
-
getRealPath
default String getRealPath(String path)
Method matching
ServletContext.getRealPath(String)
andServletContextHelper.getRealPath(String)
, but not available in originalHttpContext
.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 returnnull
. 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 backportsServletContextHelper.finishSecurity(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
into oldHttpContext
- 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 mappingsContextRelated.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 chosingMultiBundleWebContainerContext
has to be aware of opening an access to all bundles sharing such context.- Returns:
- name of the Context
- standard (Whiteboard)
-
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 theWebContainerContext
was created. It SHOULD benull
for shared contexts.- Returns:
-
-