Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-3244

New Admin UI doesn't work on tomcat

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.0-ALPHA
    • Fix Version/s: 4.0-ALPHA
    • Component/s: Admin UI
    • Labels:
      None

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                thetaphi Uwe Schindler
                Reporter:
                zhygr Aliaksandr Zhuhrou
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: