DXA 1.8 Java Application Error

Question

I am getting the below error while I run the Java DXA 1.8 application.
Can someone help me to identify the root cause of this issue?

[https-jsse-nio2-4017-exec-23] ERROR c.s.w.c.controller.PageController - Exception while processing request for: /
java.lang.NullPointerException: null
            at     com.sdl.webapp.tridion.mapping.DefaultContentProvider.getStaticContentFile(DefaultContentProvider.java:95) ~[dxa-web8-provider-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.tridion.mapping.AbstractDefaultContentProvider.getStaticContentFile(AbstractDefaultContentProvider.java:366) ~[dxa-tridion-provider-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.tridion.mapping.AbstractDefaultContentProvider.getStaticContent(AbstractDefaultContentProvider.java:309) ~[dxa-tridion-provider-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.common.impl.localization.LocalizationFactoryImpl.parseJsonFileTree(LocalizationFactoryImpl.java:239) ~[dxa-common-impl-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.common.impl.localization.LocalizationFactoryImpl.loadMainConfiguration(LocalizationFactoryImpl.java:108) ~[dxa-common-impl-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.common.impl.localization.LocalizationFactoryImpl.createLocalization(LocalizationFactoryImpl.java:84) ~[dxa-common-impl-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.tridion.AbstractTridionLocalizationResolver.createLocalization(AbstractTridionLocalizationResolver.java:101) ~[dxa-tridion-provider-1.8.0.jar:1.8.0]
            at     com.sdl.webapp.tridion.AbstractTridionLocalizationResolver.getLocalization(AbstractTridionLocalizationResolver.java:68) ~[dxa-tridion-provider-1.8.0.jar:1.8.0]
            at com.sdl.webapp.common.impl.WebRequestContextImpl.localization(WebRequestContextImpl.java:205) ~[dxa-common-impl-1.8.0.jar:1.8.0]
            at com.sdl.webapp.common.impl.WebRequestContextImpl.getLocalization(WebRequestContextImpl.java:85) ~[dxa-common-impl-1.8.0.jar:1.8.0]
            at com.sdl.webapp.common.impl.WebRequestContextImpl$$FastClassByCGLIB$$2bfec188.invoke(<generated>) ~[cglib-2.2.2.jar:1.8.0]
            at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) ~[cglib-2.2.2.jar:na]
            at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689) ~[spring-aop-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) ~[spring-aop-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at     org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) ~[spring-aop-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at     org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) ~[spring-aop-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) ~[spring-aop-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.aop.framework.Cglib2AopProxy    $DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:622) ~[spring-aop-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at com.sdl.webapp.common.impl.WebRequestContextImpl$$EnhancerByCGLIB$$b1d5d76e.getLocalization(<generated>) ~[cglib-2.2.2.jar:1.8.0]
            at     com.sdl.webapp.common.impl.interceptor.StaticContentInterceptor.preHandle(StaticContentInterceptor.java:102) ~[dxa-common-impl-1.8.0.jar:1.8.0]
            at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:914) ~[spring-webmvc-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852) ~[spring-webmvc-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882) ~[spring-webmvc-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778) ~[spring-webmvc-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) [servlet-api.jar:na]
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) [servlet-api.jar:na]
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) [catalina.jar:8.5.29]
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.29]
            at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-websocket.jar:8.5.29]
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:8.5.29]
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.29]
            at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) [spring-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) [spring-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [catalina.jar:8.5.29]
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [catalina.jar:8.5.29]
            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) [catalina.jar:8.5.29]
            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [catalina.jar:8.5.29]
            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:496) [catalina.jar:8.5.29]
            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) [catalina.jar:8.5.29]
            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) [catalina.jar:8.5.29]
            at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650) [catalina.jar:8.5.29]
            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [catalina.jar:8.5.29]
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) [catalina.jar:8.5.29]
            at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803) [tomcat-coyote.jar:8.5.29]
            at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-coyote.jar:8.5.29]
            at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1697) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:1050) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper$4.completed(Nio2Endpoint.java:630) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.Nio2Endpoint$Nio2SocketWrapper$4.completed(Nio2Endpoint.java:608) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.SecureNio2Channel$1.completed(SecureNio2Channel.java:917) [tomcat-coyote.jar:8.5.29]
            at org.apache.tomcat.util.net.SecureNio2Channel$1.completed(SecureNio2Channel.java:846) [tomcat-coyote.jar:8.5.29]
            at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) [na:1.8.0_151]
            at sun.nio.ch.Invoker$2.run(Invoker.java:218) [na:1.8.0_151]
            at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112) [na:1.8.0_151]
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_151]
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_151]
            at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-util.jar:8.5.29]
            at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]

Answer 1

Let me explain how to interpret such a Stack Trace:

• The exception is a NullPointerException, meaning that the code tried to dereference a pointer which is null. This generally means the code is not robust enough: it did not expect that a pointer could get a null value, but it did.
• The first line in the Stack Trace reveals where this exception occurred: in method DefaultContentProvider.getStaticContentFile, defined in source file DefaultContentProvider.java at line 95.
  • The class is deployed as part of JAR dxa-web8-provider-1.8.0.jar (which reveals both the version of DXA and the name of the project)
• Subsequent lines give information about the context of where the exception occurred.
  • Interesting lines are LocalizationFactoryImpl.loadMainConfiguration and LocalizationFactoryImpl.createLocalization.
  • So, apparently, the exception occured when trying to load a "main configuration" as part of creating a "Localization". Indeed, DXA loads configuration data (stored in the CD Content Store and cached on file system) when a new Localization is initialized.
  • If we got this far, apparently the Localization has already been resolved. So, there does not seem to be an issue with Topology Manager and/or Discovery Service. The problem lies in loading the configuration data.
• Now let's go back to that first line and find the source code to get a better idea of what happened.
  • Since we're talking about a problem in the DXA Java Web Application (Framework), the source code can be found here: https://github.com/sdl/dxa-web-application-java
  • Since the DXA version is 1.8.0, we should be using the release/1.8 branch.
  • Since the artifact was dxa-web8-provider-1.8.0.jar, we should look into dxa-web8-provider
  • The fully qualified name of the class is com.sdl.webapp.tridion.mapping.DefaultContentProvider. This helps us to navigate to the class in GitHub: https://github.com/sdl/dxa-web-application-java/blob/release/1.8/dxa-framework/dxa-web8-provider/src/main/java/com/sdl/webapp/tridion/mapping/DefaultContentProvider.java
  • Now, let's see what's at line 95: writeToFile(file, pathInfo, binaryData.getBytes());
  • OK, so it's trying to write binary data to a file. There is only one thing on this line that can cause a NullPointerException: binaryData.getBytes(). That is: if binaryData is null, you will get a NullPointerException.
  • So, how did binaryData get null? We have to look at preceding lines to see how binaryData got set. At line 92 we find: BinaryData binaryData = binaryContentRetriever.getBinary(publicationId, itemId, binaryMeta.getVariantId());
• Altogether, we now have a pretty good picture:
  • As part of Localization intialization, some configuration data is loaded in the form of a Binary in the CD Content Store, which then gets written/cached to file system.
  • However, it seems the Binary cannot be retrieved from CD Content Store and the CD API returns a null pointer.
  • The DXA code does not expect this null pointer and this results in a NullPointerException.

Question remains: why can that Binary not be found in the CD Content Store? Typical reasons for this are:

• The CM Publication is not published to CD yet. In particular: this kind of Configuration data (stored as Binaries in CD) is published by the "Publish Settings" Page.
  • Actually, if the Binary was not published at all, we wouldn't have gotten this far in the code, because then there would not even have been metadata about the binary (see line 92 and earlier in the source code: before trying to retrieve the Binary data, some metadata about the binary is retrieved first).
• The CD Deployer is configured to store Binaries on file system instead of in the CD Content Store (database).
  • This seems to be the most plausible explanation of how such an exception can occur.