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, 10:28, 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. -- -- ------------------ 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/d73c71c1-023d-4e71-88fe-f6440d84734d%40googlemail.com.
