Tomcat v7.0 Load Exception - Markierung des Servlets als nicht verfügbar

Question

Neuinstallation von Tomcat v7.0 und Eclipse. Versuch, die SSI-Servlet-Unterstützung zu laden. Habe context.xml und web.xml gemäß Tomcat-Anweisungen geändert.

context.xml (relevante Fragmente gezeigt):

<Context reloadable="true" privileged="true"> 

    <!-- Default set of monitored resources --> 
    <WatchedResource>WEB-INF/web.xml</WatchedResource> 


</Context> 

web.xml (relevante Fragmente gezeigt):

<servlet> 
     <servlet-name>ssi</servlet-name> 
     <servlet-class> 
      org.apache.catalina.ssi.SSIServlet 
     </servlet-class> 
     <init-param> 
      <param-name>buffered</param-name> 
      <param-value>1</param-value> 
     </init-param> 
     <init-param> 
      <param-name>debug</param-name> 
      <param-value>0</param-value> 
     </init-param> 
     <init-param> 
      <param-name>expires</param-name> 
      <param-value>666</param-value> 
     </init-param> 
     <init-param> 
      <param-name>isVirtualWebappRelative</param-name> 
      <param-value>0</param-value> 
     </init-param> 
     <load-on-startup>4</load-on-startup> 
    </servlet> 

    <servlet-mapping> 
     <servlet-name>ssi</servlet-name> 
     <url-pattern>*.shtml</url-pattern> 
    </servlet-mapping> 

Aber ich bin immer noch die folgende Last Ausnahme beim Abrufen:

Mar 23, 2012 12:06:00 PM org.apache.catalina.core.StandardContext loadOnStartup 
SEVERE: Servlet threw load() exception 
java.lang.SecurityException: Restricted class org.apache.catalina.ssi.SSIServlet 
    at 

org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:548) 
     at org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:539) 
    at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:509) 
    at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:124) 
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1136) 
    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080) 
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5001) 
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5289) 
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) 
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1525) 
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1515) 
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) 
    at java.util.concurrent.FutureTask.run(FutureTask.java:166) 
    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) 

Mar 23, 2012 12:06:00 PM org.apache.catalina.core.ApplicationContext log 
INFO: Marking servlet ssi as unavailable 

Ich habe alles versucht, was mir einfällt. Kann jemand beraten, wie man das repariert? danke!

Answer 1

So bestätigen nur (wie dies funktioniert für mich):

• herunterladen Tomcat 7.0.26 (zip)
• Entpackte
• Geänderte $ {TOMCAT_HOME) /conf/web.xml
  • uncommented die SSI-Servlet Definition Strecken Linie 276
  • uncommented die SSI Servletzuordnung um die Linie 370
• Geänderte $ {} TOMCAT_HOME /conf/tomcat-users.xml
  • Added Rolle für die Admin-GUI
  • Added Benutzer admin mit Admin-gui Rolle

• Added ein einfaches ssi.shtml Seite $ {TOMCAT_HOME}/webapps/Host-Manager:

  < - # printenv - >

• gestartet Tomcat , Keine Fehler, http://localhost:8080/host-manager/ssi.shtml Werke als

Schließlich erwartet - Sie context.xml der Web-Anwendung bearbeiten, nicht die web.xml in $ {TOMCAT_HOME}/conf folder - ich denke, so wie Ihr Beispiel hat das WatchedResource Element

Answer 2

Ich habe das gleiche Problem mit einem anderen Paket: CGI anstelle von SSI. Ich werde durch die Lösung gehen, die ich gefunden habe, um den Fehler zu überwinden.

Wie bei OP, hatte ich eine saubere Installation von Tomcat 7.0.27. Ich habe CGI getestet. Arbeiten durch die Ersteinrichtung des folgend ich wurde immer:

SEVERE: Servlet /TestTomcatApp threw load() exception 
java.lang.SecurityException: Restricted class org.apache.catalina.servlets.CGIServlet 
at  org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:548 ) 

der so ziemlich identisch mit dem OP ist mit Ausnahme der Klasse beteiligt.

I "Tomcat Restricted DefaultInstanceManager" gesucht und befindet [diesen Quellcode java] [1]:

private void [More ...] checkAccess(Class<?> clazz, Properties restricted) { 
    while (clazz != null) { 
     if ("restricted".equals(restricted.getProperty(clazz.getName()))) { 
      throw new SecurityException("Restricted class" + clazz); 
     } 
     clazz = clazz.getSuperclass(); 
    } 
} 

Die Eigenschaften der Klasse (die von der Codepage Heiß verknüpft sein können referenziert) den Code angegeben war sehr wahrscheinlich eine .properties-Datei lesen. So konnte ich mich auf catalina.properties und catalina.policy konzentrieren. Nach einer sorgfältigen Lektüre der Dokumentation in diesen beiden Dateien sowie Verweise auf die [Tomcat Security Doc] [2] Ich erkennen ich ein Stipendium Erklärung an die catalina.policy Datei hinzuzufügen hatte:

// The Manager application needs access to the following packages to support the 
// session display functionality. These settings support the following 
// configurations: 
// - default CATALINA_HOME == CATALINA_BASE 
// - CATALINA_HOME != CATALINA_BASE, per instance Manager in CATALINA_BASE 
// - CATALINA_HOME != CATALINA_BASE, shared Manager in CATALINA_HOME 
grant codeBase "file:${catalina.base}/webapps/manager/-" { 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.ha.session"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager.util"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.util"; 
    **permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.servlets.CGIServlet";** 

}; 
grant codeBase "file:${catalina.home}/webapps/manager/-" { 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.ha.session"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.manager.util"; 
    permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.util"; 
    **permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.servlets.CGIServlet"; 
};** 

(Meine Ergänzungen bolded)

Nach dem Neustart von Tomcat ging der Fehler weg.

HINWEIS: Ich erkannte, dass dieses gesamte Problem durch die Sicherheitsprobleme beim Ausführen bestimmter Module auf Tomcat verursacht werden muss. Meine Verwendung dient ausschließlich dem Testen auf einer einzelnen Maschine, und in diesem Modus wird keine Produktion erwartet.

[1] http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.0/org/apache/catalina/core/DefaultInstanceManager.java#DefaultInstanceManager.checkAccess%28java.lang.Class%29

[2] http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html#Configuring_Tomcat_With_A_SecurityManager

Answer 3

I hinzugefügt, um das Attribut zu privileged="true" Kontext Element in der context.xml Datei an der Wurzel. Es hat die Sicherheitsausnahme für CGI für mich gelöst.

Ich fand, dass durch this site.