[SOLR-3244] New Admin UI doesn't work on tomcat

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.0-ALPHA
• Fix Version/s: 4.0-ALPHA
• Component/s: Admin UI
• Assignee: Uwe Schindler
• Reporter: Aliaksandr Zhuhrou
• Created: 14/Mar/12 09:37
• Updated: 16/Feb/17 15:55
• Resolved: 14/Mar/12 20:30

Description

I am currently unable to open admin interface when using war deployment under tomcat server.
The stack trace:

SEVERE: Servlet.service() for servlet [LoadAdminUI] in context with path [/solr] threw exception
java.lang.NullPointerException
at java.io.File.<init>(File.java:251)
at org.apache.solr.servlet.LoadAdminUiServlet.doGet(LoadAdminUiServlet.java:50)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:292)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1815)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Tomcat version: Apache Tomcat/7.0.23
Java version: jdk1.7.0_02

I did some debugging and found that the problem related that
it delegates the resolving of resource path to the org.apache.naming.resources.WARDirContext which simply returns null for any input parameters:

/**

• Return the real path for a given virtual path, if possible; otherwise
• return <code>null</code>.
  *
• @param path The path to the desired resource
  */
  @Override
  protected String doGetRealPath(String path) {
  return null;
  }

Need to check specification, because it may be actually the tomcat bug. We may try use the getResourceAsStream(java.lang.String path) method which should work even for war.

Issue Links

• is part of: SOLR-3238 Sequel of Admin UI