NPE in Spring Integration LoggingHandler - java

I'm facing some weird NPE with no details thrown by org.springframework.integration.handler.LoggingHandler. The previous log entry is 2 minutes before which is also strange.
Does anyone have any idea what can be the reason behind it?
2017-07-25 18:33:38.561 DEBUG o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of singleton bean 'markEodPositionsAsProcessedChannel'
2017-07-25 18:35:36.985 ERROR o.s.integration.handler.LoggingHandler : org.springframework.messaging.MessageHandlingException: nested exception is java.lang.NullPointerException
at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:96)
at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:89)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:109)
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:127)
at org.springframework.integration.dispatcher.AbstractDispatcher.tryOptimizedDispatch(AbstractDispatcher.java:116)
at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:148)
at org.springframework.integration.dispatcher.UnicastingDispatcher.access$000(UnicastingDispatcher.java:53)
at org.springframework.integration.dispatcher.UnicastingDispatcher$3.run(UnicastingDispatcher.java:129)
at org.springframework.integration.util.ErrorHandlingTaskExecutor$1.run(ErrorHandlingTaskExecutor.java:55)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException

The code you talk about looks like:
public T processMessage(Message<?> message) {
try {
return this.delegate.process(message);
}
catch (Exception e) {
throw new MessageHandlingException(message, e);
}
}
The clearly means that delegate.process() throws NPE somehow.
According to the StackTrace you have some Service Activator to call your POJO service method. And that looks like exactly your method already throws that NPE.
I also believe that there is something else in the StackTrace after Caused by: java.lang.NullPointerException.
You see that as an ERROR in your logs, because you have some polling flow starting from some source - Inbound Channel Adapter. And any exception thrown downstream are caught by the error handler in the Poller Ednpoint and sent to the errorChannel with the LoggingHandler as a default subscriber.
See Reference Manual for more info.

Related

What is the difference between LOGGER.error(exception.getMessage()) and LOGGER.error(exception.getMessage(), exception)

Like in this picture
I know that both of them works fine but I just wanted to know how are they different from each other? PS: I am a beginner.
A LogEvent can contain both a message and an exception. If you use the first form:
LOGGER.error(exception.getMessage());
only the error message will be recorded and you'll have a similar output in your logs (depends upon the layout):
[ERROR] - Exception message.
If you use the second form:
LOGGER.error(exception.getMessage(), exception);
you'll have both a message and an exception. This typically outputs the stack trace in the logs:
[ERROR] - Exception message.
java.lang.RuntimeException: Exception message.
at pl.copernik.log4j.Log4j2Test.run(Log4j2Test.java:19) [classes/:?]
at pl.copernik.log4j.Log4j2Test.main(Log4j2Test.java:15) [classes/:?]
Since you can always configure Log4j 2.x to suppress stack traces from the output (see alwaysWriteExceptions in the PatternLayout documentation), the second form is always better, as it provides more information.
Remark: Since the stack trace always prints the error's message, I'd suggest a third form:
LOGGER.error("An unexpected condition occurred while performing foo: {}",
exception.getMessage(), exception);
This way you can explain the context, when the exception occurred:
[ERROR] - An unexpected condition occurred while performing foo: Exception message.
java.lang.RuntimeException: Exception message.
at pl.copernik.log4j.Log4j2Test.run(Log4j2Test.java:19) [classes/:?]
at pl.copernik.log4j.Log4j2Test.main(Log4j2Test.java:15) [classes/:?]

Using Log4j2 to reduce Java stack trace logging

I'd like Log4j2 to output a complete Java stack trace only once when an exception is first raised and not repeat that information as exceptions are propagated up the call chain. I'm trying to figure out what custom Log4j2 components would implement this minimal call chain logging strategy.
I'm creating a custom layout based on PatternLayout and wondering if I need to create my own PatternSelector. Before I get too far down this path, I'd love advice from those that understand the internals of Log4j2 (v2.13.3).
The following pseudocode illustrates the problem.
m0() {try {m1();} catch (Exception e) {log.error("emsg0", e);} }
m1() {try {m2();} catch (Exception e) {log.error("msg1", e); throw new Exception("emsg1", e);} }
m2() {try {m3();} catch (Exception e) {log.error("msg2", e); throw new Exception("emsg2", e);} }
m3() {_log.error("msg3"); throw new Exception("emsg3"); }
Here are the log records when the real code runs:
14:08:47.425 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg3
14:08:47.426 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg2
java.lang.Exception: emsg3
at edu.utexas.tacc.log4j2.Log4j2TestA.m3(Log4j2TestA.java:24)
at edu.utexas.tacc.log4j2.Log4j2TestA.m2(Log4j2TestA.java:22)
at edu.utexas.tacc.log4j2.Log4j2TestA.m1(Log4j2TestA.java:19)
at edu.utexas.tacc.log4j2.Log4j2TestA.m0(Log4j2TestA.java:17)
at edu.utexas.tacc.log4j2.Log4j2TestA.main(Log4j2TestA.java:14)
14:08:47.431 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg1
java.lang.Exception: emsg2
at edu.utexas.tacc.log4j2.Log4j2TestA.m2(Log4j2TestA.java:23)
at edu.utexas.tacc.log4j2.Log4j2TestA.m1(Log4j2TestA.java:19)
at edu.utexas.tacc.log4j2.Log4j2TestA.m0(Log4j2TestA.java:17)
at edu.utexas.tacc.log4j2.Log4j2TestA.main(Log4j2TestA.java:14)
Caused by: java.lang.Exception: emsg3
at edu.utexas.tacc.log4j2.Log4j2TestA.m3(Log4j2TestA.java:24)
at edu.utexas.tacc.log4j2.Log4j2TestA.m2(Log4j2TestA.java:22)
... 3 more
14:08:47.432 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg0
java.lang.Exception: emsg1
at edu.utexas.tacc.log4j2.Log4j2TestA.m1(Log4j2TestA.java:20)
at edu.utexas.tacc.log4j2.Log4j2TestA.m0(Log4j2TestA.java:17)
at edu.utexas.tacc.log4j2.Log4j2TestA.main(Log4j2TestA.java:14)
Caused by: java.lang.Exception: emsg2
at edu.utexas.tacc.log4j2.Log4j2TestA.m2(Log4j2TestA.java:23)
at edu.utexas.tacc.log4j2.Log4j2TestA.m1(Log4j2TestA.java:19)
... 2 more
Caused by: java.lang.Exception: emsg3
at edu.utexas.tacc.log4j2.Log4j2TestA.m3(Log4j2TestA.java:24)
at edu.utexas.tacc.log4j2.Log4j2TestA.m2(Log4j2TestA.java:22)
at edu.utexas.tacc.log4j2.Log4j2TestA.m1(Log4j2TestA.java:19)
... 2 more
Here's what I'd rather see:
14:08:47.425 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg3
14:08:47.426 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg2
java.lang.Exception: emsg3
at edu.utexas.tacc.log4j2.Log4j2TestA.m3(Log4j2TestA.java:24)
at edu.utexas.tacc.log4j2.Log4j2TestA.m2(Log4j2TestA.java:22)
at edu.utexas.tacc.log4j2.Log4j2TestA.m1(Log4j2TestA.java:19)
at edu.utexas.tacc.log4j2.Log4j2TestA.m0(Log4j2TestA.java:17)
at edu.utexas.tacc.log4j2.Log4j2TestA.main(Log4j2TestA.java:14)
14:08:47.431 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg1
java.lang.Exception: emsg2
Caused by: java.lang.Exception: emsg3
14:08:47.432 [main] ERROR edu.utexas.tacc.log4j2.Log4j2TestA - msg0
java.lang.Exception: emsg1
Caused by: java.lang.Exception: emsg2
Caused by: java.lang.Exception: emsg3
Any guidance is appreciated,
Rich
You would need to create a custom ThrowablePatternConverter. But doing this probably isn't a good idea. In real life where apps run for a long time (days, weeks, or months) you might not see the exception for long periods of time and only seeing a 1 line caused by might get a bit frustrating since the root caused by exception is typically the most interesting one.
In addition, caching the exceptions and trying to do matching would make processing the exceptions pretty slow.
I think the best solution to this problem is to take njzk2's advice and either log or throw an exception, but don't do both. As long as the code is reasonably well structured, each exception will get logged exactly once and Log4j2 will record the complete exception chain in an acceptable way.

hide runtime exception in RabbitMQ listener

I used some exception to reject the message in some cases that intentionally happened but shown the exception in the console which looks not alright for the first glance.
how can I hide that specific exception from logging on console/file
I'm Using spring-boot and the default loggers!
public static class UndispatchException extends
AmqpRejectAndDontRequeueException{
public UndispatchException() {
super("Dispatch still looking for a driver");
}
}
here the listner
#RabbitListener(queues = TEST_QUEUE)
public void handle(Dispatch in) {
if(in.isRequeue()){
log.debug("will reject the message");
throw new UndispatchException();
}
log.debug("won't reject the message");
}
here is the log I want to hide it! which mandetory to have to requeue the message in some cases!
2018-05-15 18:41:11.494 WARN 2709 --- [cTaskExecutor-1] s.a.r.l.ConditionalRejectingErrorHandler : Execution of Rabbit message listener failed.
org.springframework.amqp.rabbit.listener.exception.ListenerExecutionFailedException: Listener method 'public void com.amqp.handleException.demo.DemoApplication.handle(com.amqp.handleException.demo.DemoApplication$Dispatch)' threw exception
at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.invokeHandler(MessagingMessageListenerAdapter.java:140) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.onMessage(MessagingMessageListenerAdapter.java:106) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:856) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:779) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.access$001(SimpleMessageListenerContainer.java:105) [spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$1.invokeListener(SimpleMessageListenerContainer.java:208) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.invokeListener(SimpleMessageListenerContainer.java:1349) [spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.executeListener(AbstractMessageListenerContainer.java:760) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.doReceiveAndExecute(SimpleMessageListenerContainer.java:1292) [spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.receiveAndExecute(SimpleMessageListenerContainer.java:1262) [spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer.access$1800(SimpleMessageListenerContainer.java:105) [spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1518) [spring-rabbit-1.7.7.RELEASE.jar:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: com.amqp.handleException.demo.DemoApplication$UndispatchException: Dispatch still looking for a driver
at com.amqp.handleException.demo.DemoApplication.handle(DemoApplication.java:47) ~[classes/:na]
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_111]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_111]
at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:180) ~[spring-messaging-4.3.15.RELEASE.jar:4.3.15.RELEASE]
at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:112) ~[spring-messaging-4.3.15.RELEASE.jar:4.3.15.RELEASE]
at org.springframework.amqp.rabbit.listener.adapter.HandlerAdapter.invoke(HandlerAdapter.java:49) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
at org.springframework.amqp.rabbit.listener.adapter.MessagingMessageListenerAdapter.invokeHandler(MessagingMessageListenerAdapter.java:126) ~[spring-rabbit-1.7.7.RELEASE.jar:na]
... 12 common frames omitted
In your logging configuration, set the log level for
org.springframework.amqp.rabbit.listener.ConditionalRejectingErrorHandler
to ERROR (that message is logged at WARN level).
With Spring Boot, you can simply add...
logging.level.org.springframework.amqp.rabbit.listener.ConditionalRejectingErrorHandler=ERROR
...to your application.properties (or .yml) file.
EDIT
If you wish to do something different (such as log certain exceptions) you can make a copy of the ConditionalRejectingErrorHandler and make changes in the handleError() method. The code is here.
You would then configure the listener container (or listener container factory) with your custom error handler.

Web-service client on Websphere throws NullPointer on method calling

We've been using
jaxws-spring
WebSphere 8.5.5.2
for our web-services interactions, and now we get stuck with such "cause" when we call any web-method on the client-side -
ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root cause appServlet:
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:948)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:827)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:812)
.....
Caused by: javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
at org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils.createSystemException(MethodMarshallerUtils.java:1363)
at org.apache.axis2.jaxws.marshaller.impl.alt.MethodMarshallerUtils.demarshalFaultResponse(MethodMarshallerUtils.java:1089)
at org.apache.axis2.jaxws.marshaller.impl.alt.DocLitWrappedMethodMarshaller.demarshalFaultResponse(DocLitWrappedMethodMarshaller.java:680)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.getFaultResponse(JAXWSProxyHandler.java:626)
....
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:946)
at org.apache.axis2.jaxws.message.databinding.JAXBUtils.getJAXBContext(JAXBUtils.java:445)
at org.apache.axis2.datasource.jaxb.JAXBDSContext.getJAXBContext(JAXBDSContext.java:228)
at org.apache.axis2.datasource.jaxb.JAXBDSContext.getJAXBContext(JAXBDSContext.java:161)
at org.apache.axis2.datasource.jaxb.JAXBDSContext.marshal(JAXBDSContext.java:396)
at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:189)
at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:371)
at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:295)
at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerialize(OMSourcedElementImpl.java:781)
at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:967)
at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:283)
at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.internalSerialize(SOAPEnvelopeImpl.java:245)
at org.apache.axiom.om.impl.llom.OMSerializableImpl.serializeAndConsume(OMSerializableImpl.java:207)
at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:74)
Web-service client initialisation comes out with no any errors -
URL service_endpoint;
service_endpoint = new URL(endpoint);
service = new UDHandlersServiceImpl(service_endpoint, SERVICE_QNAME).getUDHandlersServiceImplPort();
NullPointerException occurs after calling any method of "service". And it doesn't even reach server side - because it doesn't have any logs there. Furthermore - such situation occurs only on the WebSphere - we deployed our client application on the Tomcat (server remained on websphere) and it worked fine. One more thing - SoapUI does not have any problems interacting with server side too.
We tried to switch classLoadings to parentLast for client application - with no success.
Also I can't even find sources for "org.apache.axis2.jaxws.message.databinding.JAXBUtils.getJAXBContext(JAXBUtils.java:445)". I googled it and didn't find this version of JAXBUtils. But even if i did, i think, it wouldnt be useful...
I hope someone can help us with that unobvious problem.
Thanks beforehand.
===== updated======
When we remove jaxb libraries from endorsed dir (or appServer/classes) problem seems to disappear but in case of arising webExceptions(faults) server throws
Caused by: java.lang.ClassCastException: com.ibm.xml.xlxp2.jaxb.JAXBContextImpl incompatible with com.sun.xml.bind.api.JAXBRIContext
at com.sun.xml.ws.fault.SOAPFaultBuilder.<clinit>(SOAPFaultBuilder.java:565)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:237)
and returns no answer to the client.
We've realized that our exceptions didn't contain 3 required methods -
//============required==================
public DocumentValidationException(String message, ErrorsBean errorsBean, Throwable cause) {
super(message, cause);
this.errorsBean = errorsBean;
}
public ErrorsBean getFaultInfo() {
return errorsBean;
}
public DocumentValidationException(String message, ErrorsBean errorsBean) {
super(message);
this.errorsBean = errorsBean;
}
//======================================
so, now it does.
And also we had some wrong target namespaces in it at the #WebFault annotations.
Here is the link with similar problem - https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014076927#77777777-0000-0000-0000-000014083314

How do I get a Java WebService to actually show me exceptions from the proxy object?

I'm chasing what should be a simple NullPointerException but a webservice proxy keeps swallowing the error.
The WS is exposed through a simple client library, that client then calls the WS. Somewhere in the WS theres an NPE and I can't find it because the stack trace only shows "$Proxy.someMethod" instead of the cause of the issue.
How can I get the stack trace from the proxy object? Is there a good strategy to log or handle these exceptions?
...
Caused by: javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:187)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:116)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:254)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:224)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:117)
******** I need the trace from this line *********
at $Proxy43.myMethod(Unknown Source)
*****************
at com.mypackage.client.MyClient.aMethod(MyClient.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161)
... 17 more
I've done some reading and it seems like this has to do with checked vs. unchecked exceptions. So if I were throwing an IOException I'd get the stack trace, but since there is a NullPointerException bubbling up its not giving me the trace.
Wrap your service in a try/catch block and throw the exception that's defined as the fault element of the called service in your WSDL. That way the client will get a useable stacktrace.

Categories