Paul, We don't use Pax-logging, so I doubt that this would be responsible.
As for adding the import statement, I will try it as a test, but to me that violates my bundle scope, and we might have to live with those until the fix is out in version 8. Alain On Monday, February 15, 2021 at 5:29:17 PM UTC-5 [email protected] wrote: > It's worth checking which logback implementations you have in your > deployment. Pax-logging-logback implements the api, but does expose the > api or ship the SCI service file. If the bundle is found before the one > that ships the SCI file then it could be causing the CNF. > > Failing that the workaround of manually adding the import statement should > work. Although I took the different approach of using a bundle extender to > register all the SCIs in the system and instantiate them when required. > > I hope that helps. > Paul > On 15 Feb 2021, at 10:28, Grzegorz Grzybek <[email protected]> wrote: > >> Hello >> >> Thanks for checking! Does it work if you add relevant Import-Package to >> your bundle? >> >> All I can say is that in Pax Web 8, it'll be done correctly: >> https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-extender-war/src/main/java/org/ops4j/pax/web/extender/war/internal/model/BundleWebApplication.java#L1139-L1149 >> >> >> // a list of instantiated (using correct bundle) SCIs >> final List<ServletContainerInitializer> detectedSCIs = new >> LinkedList<>(); >> >> // container SCIs - loaded from respective bundles >> containerSCIURLs.forEach((b, urls) -> { >> for (URL url : urls) { >> loadSCI(url, b, detectedSCIs); >> } >> }); >> >> // WAB SCIs - loaded from WAB itself >> wabSCIURLs.forEach(url -> { >> loadSCI(url, bundle, detectedSCIs); >> }); >> >> regards >> Grzegorz Grzybek >> >> pon., 15 lut 2021 o 11:22 Alain Picard < [email protected]> >> napisał(a): >> >>> Hi, >>> Grzegorz, I did that and it is a ClassNotFoundException. >>> >>> Here is the first one: >>> java.lang.ClassNotFoundException: >>> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer cannot be >>> found by org.ops4j.pax.web.pax-web-jetty_7.2.21 >>> >>> and in this case the bundle is: >>> com.castortech.iris.zk.geomap_1.0.0.qualifier since the error is for the >>> 2nd attempt on the server. >>> >>> Kind of obviously, our bundle doesn't import packages or require bundle >>> from logback. >>> >>> Alain >>> On Monday, February 15, 2021 at 1:51:35 AM UTC-5 [email protected] >>> wrote: >>> >>>> Hello >>>> >>>> Alain, the problem is that the logging statement that prints this >>>> message is: >>>> >>>> } catch (ClassNotFoundException | InstantiationException | >>>> IllegalAccessException | IOException e) { >>>> log.warn("failed to parse and instantiate of >>>> javax.servlet.ServletContainerInitializer in classpath"); >>>> } >>>> >>>> So the actual exception is swallowed. Is there a chance you put a >>>> breakpoint in this line: >>>> https://github.com/ops4j/org.ops4j.pax.web/blob/web-7.2.21/pax-web-api/src/main/java/org/ops4j/pax/web/utils/ServletContainerInitializerScanner.java#L136 >>>> >>>> and check what the exception really is? >>>> >>>> By the way - in Pax Web 8 I've completely rewritten how the SCIs are >>>> discovered, instantiated and used across all the contexts, but there's no >>>> strict date for Pax Web 8 release yet... >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> sob., 13 lut 2021 o 16:18 Alain Picard < [email protected]> >>>> napisał(a): >>>> >>>>> Bonjour Jean-Baptiste, >>>>> >>>>> This is not running under Karaf, just running as a standard PDE OSGi >>>>> project and it is using Pax Web (7.2..21) with Jetty (9.4.36) >>>>> >>>>> Here's a small snippet of the log, with some failed, 1 success and 1 >>>>> skipped. >>>>> 09:18:11.955 [paxweb-config-1-thread-1] ::: INFO >>>>> o.o.p.w.u.ServletContainerInitializerScanner - will add >>>>> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to >>>>> ServletContainerInitializers >>>>> 09:18:11.957 [paxweb-config-1-thread-1] ::: WARN >>>>> o.o.p.w.u.ServletContainerInitializerScanner - failed to parse and >>>>> instantiate of javax.servlet.ServletContainerInitializer in classpath >>>>> 09:18:11.958 [paxweb-config-1-thread-1] ::: INFO >>>>> o.o.p.w.u.ServletContainerInitializerScanner - will add >>>>> org.eclipse.jetty.websocket.server.NativeWebSocketServletContainerInitializer >>>>> >>>>> to ServletContainerInitializers >>>>> 09:18:11.962 [paxweb-config-1-thread-1] ::: INFO >>>>> o.o.p.w.u.ServletContainerInitializerScanner - added >>>>> ServletContainerInitializer: >>>>> org.eclipse.jetty.websocket.server.NativeWebSocketServletContainerInitializer >>>>> 09:18:11.962 [paxweb-config-1-thread-1] ::: INFO >>>>> o.o.p.w.u.ServletContainerInitializerScanner - will add >>>>> org.apache.jasper.servlet.JasperInitializer to >>>>> ServletContainerInitializers >>>>> 09:18:11.962 [paxweb-config-1-thread-1] ::: INFO >>>>> o.o.p.w.u.ServletContainerInitializerScanner - Skipt >>>>> org.apache.jasper.servlet.JasperInitializer, because specialized handler >>>>> will be present >>>>> 09:18:11.962 [paxweb-config-1-thread-1] ::: INFO >>>>> o.o.p.w.u.ServletContainerInitializerScanner - will add >>>>> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to >>>>> ServletContainerInitializers >>>>> >>>>> Let me know if I can provide more detailed information or perform >>>>> additional debugging. >>>>> >>>>> Alain >>>>> On Saturday, February 13, 2021 at 9:55:49 AM UTC-5 >>>>> [email protected] wrote: >>>>> >>>>>> Hi Alain, >>>>>> >>>>>> Are you using Karaf or you are running it on your own ? >>>>>> >>>>>> That would be great if you describe a bit the environment, especially >>>>>> which Pax projects are you using (pax logging, pax web, …). >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> Le 13 févr. 2021 à 14:48, Alain Picard < >>>>>> [email protected]> a écrit : >>>>>> >>>>>> I am getting a few hundred of these in my log. I have found and read >>>>>> the following post <https://groups.google.com/g/ops4j/c/NC6V4YgEdis> >>>>>> from 2015 but that is not really answering the question. >>>>>> >>>>>> First it would be great to update the log message to provide some >>>>>> context like: >>>>>> log.warn("failed to parse and instantiate of >>>>>> javax.servlet.ServletContainerInitializer ({}) in classpath of context >>>>>> bundle {}", className, bundle); >>>>>> >>>>>> But I seem to be having issue with a couple of cases. A few dealing >>>>>> with Atmosphere and most from >>>>>> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer. When >>>>>> looking at the bundle, those bundles are not even aware of logback and >>>>>> will >>>>>> not find the class, and it's not visible to the server bundle either. >>>>>> More >>>>>> than likely that bundle is transitively reachable, but that doesn't >>>>>> imply >>>>>> downstream visibility, which is what is required for the bundle or >>>>>> server >>>>>> bundle to load the class. >>>>>> >>>>>> I'm not sure at that point why that would trigger a warning and or >>>>>> why we would want to apply our search transitively in the first place, >>>>>> but >>>>>> I might be missing some obvious use cases. >>>>>> >>>>>> Thanks for enlightening me. >>>>>> >>>>>> Cheers, >>>>>> Alain >>>>>> >>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> 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/e9436f50-0e74-473c-a9bc-02b9e35a845dn%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/ops4j/e9436f50-0e74-473c-a9bc-02b9e35a845dn%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/ee728336-67f8-4b6e-8359-bf330215e5dcn%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/ops4j/ee728336-67f8-4b6e-8359-bf330215e5dcn%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/66c20463-7401-411f-ba62-7b6a79c5ee04n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/ops4j/66c20463-7401-411f-ba62-7b6a79c5ee04n%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/CAAdXmhqw-Nh1FZ9guuLGX-agm3UyyUaeG5N866jzUKaECp%2B0vA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/ops4j/CAAdXmhqw-Nh1FZ9guuLGX-agm3UyyUaeG5N866jzUKaECp%2B0vA%40mail.gmail.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/d6f557cc-a16e-4626-968e-354fbb5110a3n%40googlegroups.com.
