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/CAAdXmhqxMeFKHhhrvEd-wDpgpKmwLwoq93xGZh-5w%3Di%3DY39YoQ%40mail.gmail.com.
