Pax Web

so you are trying to register multiple servlets and filters to a common httpContext? why don't you use the whiteboard extender then?
I think it's much easier to use.

Thanks for the advice with the WhiteBoard. I used that before in some simple case but now I try to apply it to my case. The shared HttpContext I think is a problem so I can not use that but fortunately I have resources only in one bundle now but I have to get them from multiple soon.

I debug now the WhiteBoard and It does not play well in a multi bundle game.

In org.ops4j.pax.web.extender.whiteboard.internal.ExtenderContext the code

public WebApplication getWebApplication( final Bundle bundle,
final String httpContextId )
{
final ContextKey contextKey = new ContextKey( bundle, httpContextId );
WebApplication webApplication = m_webApplications.get( contextKey );

The context is not shared between the bundles because the ContextKey and the org.ops4j.pax.web.extender.whiteboard.internal.tracker.AbstractTracker use

final WebApplication webApplication = m_extenderContext.getWebApplication(
serviceReference.getBundle(),
webElement.getHttpContextId()
);

The workaround is I have to pick one single bundle and us the BundleContext of that to register the service. I can not use declarative service (SCR) to register my services and us the Pax WhiteBoard patter to register WebElement.

FrameworkUtil.getBundle(ContextRegistrator.class).getBundleContext().registerService(ServletMapping.class.getName(), servletMapping, null);

I can test the 1.1.3-SNAPSHOT and give you feedback on how it work if try to fix this shared HttpContext between multi bundle with WhiteBoard scenario.

I have some additional problems when I shut down the system I get NPE exceptions.
org.ops4j.pax.web.service.jetty.internal.JettyServerImpl

public void removeServlet(final ServletModel model) {
LOG.debug("Removing servlet [" + model + "]");
// jetty does not provide a method fro removing a servlet so we have to
// do it by our own
// the facts bellow are found by analyzing ServletHolder implementation
boolean removed = false;
final ServletContextHandler context = m_server.getContext(model.getContextModel()
.getHttpContext());

Here the "context" is null and the next line throws NPE.

I also get NPE from org.ops4j.pax.web.service.jetty.internal.JettyServerImpl.removeFilter(JettyServerImpl.java:321)

BTW I use Pax Web 1.1.1 because when I change to 1.1.2 I missing requirement 63.0 osgi.wiring.package; (&(osgi.wiring.package=javax.servlet)(version>=2.3.0)(!(version>=3.0.0))) In 1.1.1 the OPS4J Pax Web - Jetty Bundle (1.1.1) exported the package so I didn't looked into the problem so I changed back to 1.1.1

This is another issue I solve later.

have you tried sharing the http-context between the bundles as a service?
If you don't provide the httpContext a default one is created. I think the main issue is about sharing the httpContext.
The spec says nothing about it, so maybe registering a "common" httpcontext as a service and referencing this one might work

I suggest also taking a look at the whiteboard sample project:

• https://github.com/ops4j/org.ops4j.pax.web/blob/master/samples/whiteboard/src/main/java/org/ops4j/pax/web/extender/samples/whiteboard/internal/Activator.java

Yes I did register the HttpContext as a service in my first example and then I used the HttpService to register my servlet from different bundles. As you may not know (It was new to me) the different bundles gets different instance of org.ops4j.pax.web.service.internal.HttpServiceStarted and the private final Bundle m_bundle; value is different in each instance (There is a service factory so when you use SCR or getService() it different per bundle)

When I use bundel#1 to register the the servlet I get the HttpService@instance-1 and I register the servlet and I use the shared HttpContext. Then I can access to the servlet but there is no filter.

When I use bundle#2 to register the filter I get the HttpService@instance-2 and I register the filter and I use the shared HttpContext. Then I try to access to the same servlet but then the servlet is gone and the new HttpServiceContext handles the request and this context has the filter but not the servlet.

If I activate the bundel#1 again then I'm back to have the servlet in the HttpServiceContext but not the filter.

All your examples using the same single bundle and then it works well but try a sample where it's separated and you will see.

My working example is available:

Firs I create the HttpContext
https://svn.forgerock.org/openidm/trunk/openidm-httpcontext/src/main/java/org/forgerock/openidm/http/ContextRegistrator.java

Your example was the previous:
https://svn.forgerock.org/openidm/trunk/openidm-httpcontext/src/main/java/org/forgerock/openidm/http/ContextRegistrator.java?p=898

When I register the filter:
https://svn.forgerock.org/openidm/trunk/openidm-filter/src/main/java/org/forgerock/openidm/filter/AuthFilter.java

Your example was the previous:
https://svn.forgerock.org/openidm/trunk/openidm-filter/src/main/java/org/forgerock/openidm/filter/AuthFilter.java?p=898

When I register the servlet:
https://svn.forgerock.org/openidm/trunk/openidm-restlet/src/main/java/org/forgerock/openidm/restlet/Servlet.java

Your example was the previous:
https://svn.forgerock.org/openidm/trunk/openidm-restlet/src/main/java/org/forgerock/openidm/restlet/Servlet.java?p=898

To do as you do in your example from multiple bundles I need to register the HttpContext as a service AND I need to register the org.ops4j.pax.web.service.WebContainer service instance from the httpcontext bundle and use that instance to register later the filters and the servlets.

you might also take a look at this thread on the mailinglist:

• http://lists.ops4j.org/pipermail/general/2012q1/007379.html

I suggest to ask the mailinglist first before entering a bug

The original bug I issued was not discussed and it's not fixed. The DefaultSharedHttpContext implementation.

#1 getDefaultSharedHttpContext method is "package private"
#2 if( ( !!allowReAsssociation ) && currentBundle != null && currentBundle != bundle ) should be if( ( !allowReAsssociation ) && currentBundle != null && currentBundle != bundle )

this will introduce new behavior for the whiteboard extender.
see also here http://wiki.osgi.org/wiki/WebExperience for inspiration

@Laszlo
do you have a simple test that can be used for integration test to verify that the expected behavior can be achieved?

I try to write an integration test. I read the http://wiki.osgi.org/wiki/WebExperience and I'm interested in the context.shared=true implementation. In my use-case I have a bundle that registers the shared HttpContext and register an authentication filter. I'd like to use this shared HttpContext from my second Bundle and register my REST servlet so it's protected by the authentication filter. I use Vaadin UI and I have a bundle with my UI application and there is the vaadin bundle with /VAADIN resource folder.

Bundle #1
Register shared HttpContext (path="/MyApp",contextId="MyApp-context",context.shared="true",parameters={..})
Register authentication Filter (urlPatterns=["/MyApp/*/secured/*"],contextId="MyApp-context",servletNames=[],ranking=1)

Bundle #2
Register REST Servlet (servletName="MyREST",alias=null,urlPatterns=["/MyApp/REST/*"],contextId="MyApp-context",initParams={..})

Bundle #3
Register UI Servlet (servletName="MyUI",alias=null,urlPatterns=["/MyApp/UI/*"],contextId="MyApp-context",initParams={..})
TODO - HttpContext#getResource(String) should have access to the resources in Bundle #3!
TODO - How to access resources from Vaadin.jar#/VAADIN as /MyApp/VAADIN/ (Use ResourceMapping (alias="/MyApp/VAADIN",path="bundle://54/VAADIN"))


Bundle #3 and #4 (Vaadin JAR)
Register UI Servlet (servletName="MyUI",alias=null,urlPatterns=["/MyApp/UI/*","/MyApp/VAADIN/*"],contextId="MyApp-context",initParams={..})
The Shared HttpContext should have access to the resources in both bundle and it may open the backdoor mentioned in the wiki page.

Alternative solution could be if I have to programatically call the DefaultSharedWebContainerContext#registerBundle(Bundle) method on Bundle #3 and #4 before I register the UI servlet.

What do think about the case?

@Laszlo, about your Vaadin problem, take a look at my optimizations of Kai Toetders OSGI-Vaadin Demo at https://github.com/ANierbeck/osgi-vaadin-demo this might be helpful for you.

Regarding the shared-context. Since I'm out of time right now I have to push this to either a 2.0.x or a 2.1.x