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.
