Hello Sorry for late response ;)
śr., 3 mar 2021 o 17:52 Martin Cassidy <[email protected]> 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 > <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. > "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 - [email protected] > > --- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/c781f2e3-4a09-4abd-adb3-944399df94f5n%40googlegroups.com > <https://groups.google.com/d/msgid/ops4j/c781f2e3-4a09-4abd-adb3-944399df94f5n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhpasb_P24Jco8ZCm%2BxeL3a2KGsydxXBPu5UVdAdoBqd2A%40mail.gmail.com.
