Great, that works! And I learned about the Configuration Admin architecture too. Question: is this doable with other HttpServices like WAB or the karaf console as well? For example, in a separate file, I tried bundle.symbolicName = org.apache.karaf.webconsole.console which I got from its HttpContext entry in the karaf services console. Not sure if I'm using the correct bundle name and/or if it's supported.
Thanks On Wednesday, April 28, 2021 at 12:32:49 PM UTC-5 [email protected] wrote: > Hello > > Pax Web 7.2.19 should be fine. I can't check the code at the moment, but > what I spotted is that you've created "etc/org.ops4j.pax.web.context.cfg" > file which is "org.ops4j.pax.web.context" PID. You have to create a > "factory PID", so please create a > "etc/org.ops4j.pax.web.context-somename.cfg" file - dash ("-") in a PID > makes it a factory PID and that's what the context processing needs. > > regards > Grzegorz Grzybek > > śr., 28 kwi 2021 o 18:44 Andrew Lienhard <[email protected]> napisał(a): > >> I should add: I'm using pax web 7.2.19 via karaf 4.2.10 >> >> On Wednesday, April 28, 2021 at 11:37:10 AM UTC-5 Andrew Lienhard wrote: >> >>> Thanks for the response Grzegorz! I ran across that keycloak OSGI >>> adapter yesterday and was starting down a similar path to >>> unregister/reregister the corresponding servlets but your PID approach is >>> clearly much better. To that end, I created a >>> etc/org.ops4j.pax.web.context.cfg file in our karaf (specifically, unomi) >>> environment. I see it listed in the karaf configuration under that PID, but >>> it doesn't appear to be getting applied. Am I missing something? Also, does >>> this approach work for multiple contexts? Do we create additional PIDs for >>> each? >>> >>> karaf/configuration >>> >>> PID = org.ops4j.pax.web.context >>> BundleLocation = ? >>> bundle.symbolicName = org.apache.cxf.cxf-rt-transports-http >>> context.id = default >>> felix.fileinstall.filename = file:/PATH/etc/org.ops4j.pax.web.context.cfg >>> >>> javax.servlet.context.tempdir = /PATH/data/pax-web-jsp >>> login.config.authMethod = BASIC >>> login.config.realmName = myrealm >>> org.osgi.service.http.port = 8181 >>> security.constraint1.roles = foo >>> security.constraint1.url = /* >>> >>> >>> Thanks! >>> >>> On Wednesday, April 28, 2021 at 12:10:31 AM UTC-5 [email protected] >>> wrote: >>> >>>> Hello >>>> >>>> Unfortunately, big changes are coming only to Pax Web 8 and I don't see >>>> a chance to change this critical part of Pax Web 7 (so Pax Web's >>>> HttpServiceContexts extends different class or implements this method you >>>> need). >>>> >>>> If you're trying to "apply security-constraints", you may try >>>> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing >>>> >>>> - I implemented it some time ago to be able to override a "context" >>>> created >>>> by CXF, but it should apply to "contexts" created within the scope of WABs >>>> as well. >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> wt., 27 kwi 2021 o 18:17 Andrew Lienhard <[email protected]> >>>> napisał(a): >>>> >>>>> Hi. I added a jetty-web.xml to a WEB-INF, which is being read, but as >>>>> noted in other posts here the HttpServiceContext doesn't implement all of >>>>> the methods in WebAppContext. The one I'd like to use is >>>>> overrideDescriptor. >>>>> <Configure class="org.eclipse.jetty.webapp.WebAppContext"> >>>>> >>>>> <Set name="overrideDescriptor"><SystemProperty name="jetty.home" >>>>> default="."/>./etc/override-web.xml</Set> >>>>> </Configure> >>>>> >>>>> Outcome: >>>>> Exception while configuring webApp! >>>>> java.lang.NoSuchMethodException: class >>>>> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.setOverrideDescriptor(class >>>>> >>>>> java.lang.String) >>>>> >>>>> Is there a workaround? >>>>> >>>>> Context: we're trying to apply a security-constraint to override what >>>>> the various deployed web apps may have set in our karaf container. I >>>>> suspect our solution will be to use an Apache front-end. >>>>> >>>>> Thanks in advance! >>>>> >>>>> -- >>>>> -- >>>>> ------------------ >>>>> 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/9013094a-e73a-49a9-9b69-1b82bce2c225n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/ops4j/9013094a-e73a-49a9-9b69-1b82bce2c225n%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/56312d06-4aa6-445d-86b5-6f7d8b1b3049n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ops4j/56312d06-4aa6-445d-86b5-6f7d8b1b3049n%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/52cbce11-521d-4050-a240-197927d92020n%40googlegroups.com.
