Multiple http contexts

[garpinc]

Prior to the new version in my old version essentially I had a different httpContext for every servlet. Not sure if this is ideal but it did work.

In a few of the httpContext I have listeners that get registered. What seems to be now happening is org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.visitEventListenerModelChange there is a comment:
// we have to stop the context, so existing ServletContextListeners are called
// with contextDestroyed() and new listener is added according to ranking rules of
// the EventListenerModel

so to install the listener (where all seem to have contextPath=/) it shutsdown the context which in turn appears to shutdown the contextlisteners at /. I had previously registered a spring ContextLoaderListener in a whole different bundle with a whole different httpcontext but it goes ahead and shuts that down.

Shouldn't there be a way to specify the contextPath for a particular httpContext

It appears in org.ops4j.pax.web.service.spi.model.ServiceModel.createDefaultHttpContext(String) there is someway to override the default but i don't know what effect that will him. The servlets themselves in the context have unique urls i.e: /abc /def even if these are from 2 different httpcontexts.

[grgrzybek]

Which version do you mean by "prior to the new version"? Looking at some comments from people coming from Pax Web 7, even Pax Web 8 is new (which is justified, as it's very different than Pax Web 7).

If by different httpContext you mean different org.osgi.service.http.HttpContext then you're using old (really old) Http Service Specification.

And if you look at this Chapter 102 of OSGi CMPN specification, you'll find nothing about context path at all.

org.osgi.service.http.HttpService doesn't allow to register servlets with particular context path. Same for Pax Web extension of this service, which is org.ops4j.pax.web.service.WebContainer (extends the standard with methods to register filters, listeners, error pages, JSPs, etc.)

However for many years you could actually set a context path with this ancient (comparing to the Whiteboard approach) method. You just have to ... use Whiteboard approach.

You don't have to use Http Whiteboard Specification even if Pax Web fully supports it. You can however register an org.osgi.service.http.HttpContext instance as OSGi service with additional parameters.

Here's the example which specifies the context path for this ancient org.osgi.service.http.HttpContext:

org.ops4j.pax.web/samples/samples-httpservice/http-custom-context/src/main/java/org/ops4j/pax/web/samples/custom/context/Activator.java

Lines 57 to 61 in 1aa8b2f

	// whiteboard-register this context, so we can set its context path
	Dictionary<String, Object> props = new Hashtable<>();
	props.put(PaxWebConstants.SERVICE_PROPERTY_HTTP_CONTEXT_ID, "custom");
	props.put(PaxWebConstants.SERVICE_PROPERTY_HTTP_CONTEXT_PATH, "/c.b.d");
	reg = context.registerService(HttpContext.class, httpContext, props);

But please have a look at other samples where you can do a lot more things and please switch to org.osgi.service.http.context.ServletContextHelper - the Whiteboard equivalent of org.osgi.service.http.HttpContext.

If you have more questions, please add more comments.

[grgrzybek]

There's no bug here - if you like (I like), I'll convert this issue into a discussion.

[garpinc]

I'm using org.ops4j.pax.web.service.http.HttpContext

In org.ops4j.pax.web.service.WebContainer it says

	/**
	 * Sets context paramaters to be used in the servlet context corresponding to specified http context.
	 * This method must be used before any register method that uses the specified http context, otherwise the context
	 * initialization parameters won't be taken into account (for example in {@link ServletContainerInitializer}s.
	 *
	 * @param params context parameters for the servlet context corresponding to specified http context
	 * @param httpContext http context
	 */
	void setContextParams(Dictionary<String, Object> params, HttpContext httpContext);

So what I understand from this is that if I create and instance of org.ops4j.pax.web.service.http.HttpContext then I need to call this prior to using it anywhere so I went ahead first and did this everywhere where I was creating a unique instance of org.ops4j.pax.web.service.http.HttpContext usually in a bundle where i was registering servlets, filters and eventlisteners.

But even with this isolation, and the the servlets, filters and eventlisteners on unique urls, the eventlisteners conflicted with each other on "/" even though none of the artifacts were registered on /. i.e: in one bundle I had registered a contextlistener for spring and in another bundle i registered a listener for cometd stuff and if the cometd registered after the spring one then the spring one would shutdown. The side effect being that any bundles dependent on the spring application context would also shutdown.

Furthermore to work around this I ultimately decided to centralize my servlet handling so that only one bundle registers these artifacts under on servlet context. But even so I had the same problem with the listeners. My only workaround was to register the spring contextlistener last after all the other listeners.

As I mentioned above in org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper.visitEventListenerModelChange the restart should only happen if (servletContextHandler.isStarted() && ServletContextListener.class.isAssignableFrom(eventListener.getClass())) {

BUT.. I'm not sure if I have any control of when servletContextHandler is started. i.e: maybe I can register listeners before it is started if there is someway to do that. Right now what I'm doing is waiting for WebContainer to be available and then I start registering my stuff with it.

I'm not sure what the right way to do this is. I only know that I can't find the restart of context listeners in the prior version of pax-web which is why I didn't have this issue prior to the upgrade so I'm trying to find the recommended path forward.

[grgrzybek]

Prior to upgrading you were using Pax Web 7 which violated many requirements from OSGi CMPN specification...

Right now what I'm doing is waiting for WebContainer to be available and then I start registering my stuff with it.

So you're using the old-school of registering servlets, filters and listeners using HttpService/WebContainer...

So what I understand from this is that if I create and instance of org.ops4j.pax.web.service.http.HttpContext

Did you notice that you CAN'T specify a context path when creating HttpContext instance? Because this ancient API didn't allow this!

With Whiteboard approach you can specify the target context using osgi.http.whiteboard.context.path property.