Ralph, are you going to work on this issue?
On Mon, Oct 17, 2016 at 2:04 PM, Mikael Ståldal
wrote:
> So this issue is triggered by the fact that the Kafka client library we
> use itself does logging via SLF4J during initialization. And in this
> particular web
So this issue is triggered by the fact that the Kafka client library we use
itself does logging via SLF4J during initialization. And in this particular
web configuration, org.slf4j.LoggerFactory.getLogger(Class) return
null during Configuration.start().
On Sat, Aug 20, 2016 at 12:13 AM, Bill
Ralph,
thanks! created jira:
https://issues.apache.org/jira/browse/LOG4J2-1535
I guess I still wanted the ClassLoaderContextSelector, as I wanted
each webapp to have it's own config (log to different target etc), but
just shared same jars. so the intention is to have all log related
jars in
So they are being kicked off by the webapp initialization. That follows what I
was thinking. I have a suspicion I may have to put in some code to check if the
logging classes are in the same ClassLoader as the current ClassLoader. If they
aren’t we probably need to kick off logging
Never mind. I was looking in the wrong place. They are there.
Ralph
> On Aug 19, 2016, at 2:04 PM, Ralph Goers wrote:
>
> I didn’t get an attachment. I believe the mailing list manager strips
> attachments.
>
> Ralph
>
>> On Aug 19, 2016, at 1:52 PM, Bill Okara
I didn’t get an attachment. I believe the mailing list manager strips
attachments.
Ralph
> On Aug 19, 2016, at 1:52 PM, Bill Okara wrote:
>
> Hi Gary,
>
> actually the full stack was attached in that email already, please let
> me know if you can't find them...
>
sorry Ralph, the last reply was for you (didn't read the sender carefully)
On Fri, Aug 19, 2016 at 2:52 PM, Bill Okara wrote:
> Hi Gary,
>
> actually the full stack was attached in that email already, please let
> me know if you can't find them...
> (Attachments:
Hi Gary,
actually the full stack was attached in that email already, please let
me know if you can't find them...
(Attachments: stacktrace_webinf.txt (5 kb) stacktrace_tomcatlib.txt (7 kb) )
Yeah, that's kinda my understanding (or guess) too. That is, by
putting the log related jars in
I have a suspicion the key part of the stack trace isn’t included. I am
guessing that the code that causes the first call to the Kafka appender is in
your web app. This causes the ClassLoaderContextSelector to initialize Log4j
for the web app ClassLoader. Kafka itself is in tomcat/lib. When
thanks for guiding me through this, Gary!
Attached are 2 stack dumps, one is with the log related jars packaged
in WEB-INF/lib, the other is having the jars provided in tomcat/lib,
and below are what I noticed; that is,
in WEB-INF/lib case, when initializing the
private static final Logger log =
On Fri, Aug 19, 2016 at 8:56 AM, Bill Okara wrote:
> Hi Gary,
>
> it turned out that the first NullPointerException is caused by the
> same reason, that is, in:
>
> private KafkaProducer(ProducerConfig config, Serializer
> keySerializer, Serializer valueSerializer) {
>
Hi Gary,
it turned out that the first NullPointerException is caused by the
same reason, that is, in:
private KafkaProducer(ProducerConfig config, Serializer
keySerializer, Serializer valueSerializer) {
try {
log.trace("Starting the Kafka producer");
the log in
Hello Bill,
What you could do is start the whole thing in a debugger and put a
breakpoint
in org.apache.kafka.clients.producer.KafkaProducer.KafkaProducer(ProducerConfig,
Serializer, Serializer) here:
} catch (Throwable t) {
// call close methods if internal objects are
Thanks, Gary,
you're probably right, the log in log.info seems to be the culprit.
By doing the 'trace' in log4j2.xml, it seems that the initialization
for the WebappClassLoader actually finished OK, but when initializing
for the Parent Classloader, it's when the NullPointerException
happened.
Based on the stack trace, it looks like the Slf4j logger in KafkaProducer
is null:
log.info("Closing the Kafka producer with timeoutMillis = {} ms.",
timeUnit.toMillis(timeout));
It does not look like timeUnit can be null, so it must be log.
The root problem of course if that we have an
tried again, seemed like the .out extension got filtered out by mail server...
On Thu, Aug 18, 2016 at 4:41 PM, Bill Okara wrote:
> attach the catalina.out again, didn't seem to go through last time...
>
>
> On Thu, Aug 18, 2016 at 4:33 PM, Bill Okara
Hi,
When trying out the log4j2 Kafka appender, it works ok if all the
log4j2/kafka-client related jars are packaged in the webapp's
WEB-INF/lib, like:
>ls WEB-INF/lib/
jackson-core-2.8.1.jar
log4j-core-2.6.2.jar
lz4-1.3.0.jar
kafka-clients-0.10.0.1.jar
log4j-slf4j-impl-2.6.2.jar
17 matches
Mail list logo