Web Filter which applies to all

[Martin Cassidy]

Hi,

I'm fairly new to PAX web, so apologies is this is a stupid question.

I've got a couple of bundles registering various filters/resources/jsps successfully.

I'd like to be able to put sitemesh filter and a spring security filter on the front of all of them at a global level. I'm wanting to do this from some sort of global bundle. 

I was able to find this: https://groups.google.com/g/ops4j/c/iKvj-qu7gS4 which suggests that if I use the shared context I can do that, unfortunately it doesn't work properly. The example itself is fine, but when I try and use more complex filters which require other classes, it doesn't work.

I'm using tomcat.

As far as I can tell the global bundle creates the shared context, and registers its filters. The other bundles grab the shared context reference when it becomes available and attempt to register their own filters. The ResourceDelegatingBundleClassLoader that is being used within tomcat only includes the global bundle, so a ClassNotFound exception is thrown whenever another bundle tries to register a filter.

Am I missing something here or is there a better way of doing this?

I've noticed that in osgi 7.0, section 140.10 this is achievable, but I don't think I can do that with the latest pax web version?

Thanks!

[Grzegorz Grzybek]

Hello

Sorry for late response ;)

śr., 3 mar 2021 o 17:52 Martin Cassidy <martin....@gamma.co.uk> napisał(a):

Hi,

I'm fairly new to PAX web, so apologies is this is a stupid question.

I've got a couple of bundles registering various filters/resources/jsps successfully.

I'd like to be able to put sitemesh filter and a spring security filter on the front of all of them at a global level. I'm wanting to do this from some sort of global bundle. 

Are you using Whiteboard approach:

bundleContext.registerService(Servlet.class, ...)

or HttpService approach:

httpService.registerServlet("/alias", ...)

?

 

I was able to find this: https://groups.google.cohelloworld/hsm/g/ops4j/c/iKvj-qu7gS4 which suggests that if I use the shared context I can do that, unfortunately it doesn't work properly. The example itself is fine, but when I try and use more complex filters which require other classes, it doesn't work.

I'm using tomcat.

"shared" context is a Pax Web specific concept and is related to HttpService, where "context" is a mandatory argument of methods like httpService.registerServlet(alias, servlet, params, HttpContext). With "whiteboard" approach, as defined by the specification, every "context" is shared by default - especially because you don't have to specify it (through "osgi.http.whiteboard.context.select" service registration property).

The problem is that Pax Web (before work-in-progress version 8) automatically "takes over" a context when first Whiteboard element is registered into it. see org.ops4j.pax.web.extender.whiteboard.internal.WebApplication#registerHttpContext().

With PaxWeb 8, there's clear distinction between:

• Container-specific javax.servlet.ServletContext implementation (1:1 with specific context path like "/my-context" or "/")
• org.osgi.service.http.context.ServletContextHelper specific javax.servlet.ServletContext (1:1 with a bundle that registered the ServletContextHelper, but also N:1 with the above javax.servlet.ServletContext)
• Whiteboard element (e.g., a particular Servlet service) specific javax.servlet.ServletContext which delegates to the above, but with getClassLoader() specific to a bundle registering the Servlet.

there's quite a lot of JavaDocs explaining the separation in https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-spi/src/main/java/org/ops4j/pax/web/service/spi/model/OsgiContextModel.java

If you see ClassLoading problems then yes - it's because Pax Web 7 implementation of Whiteboard is not complete... I'd have to see particular ClassCastExceptions or NoClassDefFoundExceptions to judge.

 

As far as I can tell the global bundle creates the shared context, and registers its filters. The other bundles grab the shared context reference when it becomes available and attempt to register their own filters. The ResourceDelegatingBundleClassLoader that is being used within tomcat only includes the global bundle, so a ClassNotFound exception is thrown whenever another bundle tries to register a filter.

The ResourceDelegatingBundleClassLoader was completely rewritten in Pax Web 8 because I saw exactly these kinds of problems...

Am I missing something here or is there a better way of doing this?

I've noticed that in osgi 7.0, section 140.10 this is achievable, but I don't think I can do that with the latest pax web version?

Unfortunately you have to wait for Pax Web 8...

See completely new set of itests like https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/controller/ServerControllerBasicRegistrationTest.java#L708

See for example the test which I'm especially proud of:

assertThat(httpGET(port, "/c1/s"), endsWith("S(1)"));
assertThat(httpGET(port, "/c2/s"), endsWith("S(1)"));
assertThat(httpGET(port, "/c3/s"), endsWith("S(2)"));

// servlet#5 registered to /c2 and /c4 - ranked higher than s#1 in /c2, so:
//  - s#1 is deactivated in /c1 and /c2
//  - s#3 is activated in /c1
//  - s#5 MAY be activated in /c2 and /c4, but in /c2, s#4 is ranked higher than s#5
//  - s#4 is ranked lower than s#2 in /c3, so it won't be activated ANYWHERE
//  - s#5 will thus be activated in /c2 and /c4
view.registerServlet(Arrays.asList(wcc2, wcc4), new ServletModel.Builder()
.withRegisteringBundle(bundle)
.withServletName("s1")
.withUrlPatterns(new String[] { "/s" })
.withServletReference(s15)
.withServiceRankAndId(1, ++serviceId)
.build());

assertThat(httpGET(port, "/c1/s"), endsWith("S(3)"));
assertThat(httpGET(port, "/c2/s"), endsWith("S(5)"));
assertThat(httpGET(port, "/c3/s"), endsWith("S(2)"));
assertThat(httpGET(port, "/c4/s"), endsWith("S(5)"));

kind regards

Grzegorz Grzybek

 

Thanks!

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/c781f2e3-4a09-4abd-adb3-944399df94f5n%40googlegroups.com.