public interface WebContainerContext
extends org.osgi.service.http.HttpContext
HttpContext extension that adds:
HttpContext (knowing that single bundle using such context
is part of the identity)ServletContext.getResourcePaths(String)
method.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.
| Modifier and Type | Interface and Description |
|---|---|
static class |
WebContainerContext.DefaultContextIds
Default context identifiers.
|
| Modifier and Type | Method and 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?
|
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:
ServletContextHelper.getResourcePaths(java.lang.String)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.
path - the path name for which to return resource paths. Just as in
ServletContext.getResourcePaths(String), the path must start with /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.
path - void finishSecurity(javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
ServletContextHelper.finishSecurity(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
into old HttpContextrequest - response - String getContextId()
Returns the name (identifier) of this context.
Such context may then be referenced using:
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=name)
service registration property (140.3 Common Whiteboard Properties)osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.httpservice=name)
service registration property (140.10 Integration with Http Service Contexts)httpContext.id=name service registration propertyContextRelated.getContextSelectFilter() on registered mappingsContextRelated.getContextId() on registered mappingsThere'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.
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.
org.osgi.framework.Bundle getBundle()
WebContainerContext was created. It SHOULD be null for
shared contexts.Copyright © 2006–2024 OPS4J - Open Participation Software for Java. All rights reserved.