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

New Admin UI doesn't work on tomcat

    XMLWordPrintableJSON

    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

        1. SOLR-3244.patch
          2 kB
          Uwe Schindler

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: