[PAX-WEB] Warning "failed to parse and instantiate of javax.servlet.ServletContainerInitializer in classpath"

[Alain Picard]

I am getting a few hundred of these in my log. I have found and read the following post 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

[Jean-Baptiste Onofré]

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

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
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 ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/e9436f50-0e74-473c-a9bc-02b9e35a845dn%40googlegroups.com.

[Alain Picard]

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

[Jean-Baptiste Onofré]

Hi,

I would check the TCCL and the import. It’s hard to say without knowing the weaving.

Regards

JB

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/ee728336-67f8-4b6e-8359-bf330215e5dcn%40googlegroups.com.

[Grzegorz Grzybek]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/ee728336-67f8-4b6e-8359-bf330215e5dcn%40googlegroups.com.

[Alain Picard]

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

[Grzegorz Grzybek]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/66c20463-7401-411f-ba62-7b6a79c5ee04n%40googlegroups.com.

[paul stanley]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhqw-Nh1FZ9guuLGX-agm3UyyUaeG5N866jzUKaECp%2B0vA%40mail.gmail.com.