[PAX WEB] Another unsupported (but I think important) scenario

4 views
Skip to first unread message

Grzegorz Grzybek

unread,
Feb 13, 2020, 3:40:22 AM2/13/20
to op...@googlegroups.com
Hello

Reviewing the code further, I found some example (in itests of Pax Web):

"Pax Web Whiteboard approach", where registered interfaces are Pax Web specific:

1) HttpContextMapping is registered with specified context path:

httpContextMapping = new DefaultHttpContextMapping();
httpContextMapping.setHttpContextId("alternative");
httpContextMapping.setPath("alternative");
reg = bundleContext.registerService(HttpContextMapping.class, httpContextMapping, null);

2) Servlet is registered pointing to the above context:

Servlet servlet = new WhiteboardServlet("/alias");
DefaultServletMapping servletMapping = new DefaultServletMapping();
servletMapping.setServlet(servlet);
servletMapping.setAlias("/alias");

String httpContextId = httpContextMapping.getHttpContextId();
servletMapping.setHttpContextId(httpContextId);
reg = bundleContext.registerService(ServletMapping.class, servletMapping, null);

3) servlet should be available at "/alternative/alias" path - and it is.

"OSGi CMPN Whiteboard approach", where standard interfaces are registered:

1) ServletContext helper registration with specific path:

Dictionary<String, String> contextProps = new Hashtable<>();
contextProps.put("osgi.http.whiteboard.context.name", "my-context");
contextProps.put("osgi.http.whiteboard.context.path", "/myapp");

CDNServletContextHelper context = new CDNServletContextHelper();
reg = bundleContext.registerService(ServletContextHelper.class, context, contextProps);

2) Servlet is registered pointing to the above:

Dictionary<String, String> props = new Hashtable<>();
props.put("osgi.http.whiteboard.context.select", "(osgi.http.whiteboard.context.name=my-context)");
props.put("osgi.http.whiteboard.servlet.pattern", "/myservlet");
props.put("servlet.init.myname", "value");
reg = bundleContext.registerService(Servlet.class, new MyServlet(), props);

3) servlet should be available at "/myapp/myservlet" - and it is.

But imagine opposite - first servlet is registered pointing to "default" context (HttpContextMapping or ServletContextHelper) and then "default" context is overriden by new registration with higher ranking (as allowed per spec) *but with context path specified*.
This should lead to re-registration of already registered contexts from "/" context path to new context path - but Pax Web doesn't do it.

My changes for now allow to implement such scenario.

regards
Grzegorz Grzybek
Reply all
Reply to author
Forward
0 new messages