10.2. Allgemeine, bekannte Probleme

Der grafische Installer gestattet es dem Nutzer eine benutzerdefinierte JAAS Security Domain zur Sicherung von Domains und Invokers festzulegen, aber sichert die Tomcat Konsole immer mit der JAAS Security Domain "jmx-console", selbst wenn sie nicht existiert. Um eine benutzerdefinierte JAAS Security Domain zu verwenden, legen Sie den Namen während der Installation im "JMX Security"-Bildschirm fest. Ist der Installer fertig, bearbeiten Sie die jboss-as/server/$PROFILE/deploy/ROOT.war/WEB-INF/jboss-web.xml-Datei. Im <security-domain>-Element ersetzen Sie den Namen "jmx-console" durch den Namen der Security Domain, die Sie während der Installation verwendet haben. Dies sichert die Tomcat Konsole mit derselben benuterdefinierten JAAS Security Domain, die die Admin Konsole sowie andere Konsolen und Invoker sichert, die Sie während der Installation gewählt haben.

Das Web-Profil beinhaltet inkorrekter Weise eine Recovery-Einstellung für JBoss Messaging, die nicht Teil des Web-Profils ist. Dies führt zu ClassNotFoundExceptions in server.log.

Um dieses Problem zu umgehen, entfernen Sie die folgenden Zeilen aus jbossts-properties.xml:

<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1"
            value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>

<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1"
            value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/>

Die Speicherorte von jbosssx.jar, jboss-javaee.jar, jboss-security-spi.jar und jbosssx-server.jar haben sich in dieser Release aufgrund eines Security Fix geändert. In dieser Release befinden sie sich in jboss-as/lib/. Skripte, die vom Speicherort von jbosssx.jar abhängen, sollten entsprechend dieser Änderung aktualisiert werden.

Das Deployment von Resteasy-guice Applikationen schlägt wegen einer java.lang.SecurityException fehl. Eine der folgenden ähnliche Fehlermeldung wird angezeigt: java.lang.SecurityException: class "org.jboss.resteasy.examples.guice.hello.DefaultGreeter$$FastClassByGuice$$70fd68d0"'s signer information does not match signer information of other classes in the same package"

Ein Patch für dieses Problem wurde zusammen mit JBoss Enterprise Application Platform 5.1.0 veröffentlicht und kann von der Red Hat Support-Seite heruntergeladen werden.

Andere Agent-aktivierte Tools könnten auf eine Klasse stoßen, die ein Feld, eine Methode, einen Konstruktor oder anderes noch nicht von Javassist geladenes enthält. In diesem Fall wird eine javassist.NotFoundException gemeldet, wenn der Advisor diese Methode zu manipulieren versucht. Diese Ausnahme sollte ignoriert und das Feld als nicht existent betrachtet werden.

Ein org.jboss.ejb3.stateless.StatelessDelegateWrapper kann keinem org.jboss.system.ServiceMBean zugewiesen werden, wenn ein Monitor mit org.jboss.console.plugins.monitor.CreateThresholdMonitorServlet erstellt wird. Der Monitor wird als Attribut statt als ein <depends> erstellt und schlägt bei einem Neustart daher fehl. Sie umgehen dieses Problem, indem Sie die erstellte *-service.xml manuell ändern, um dem Monitor das ordnungsgemäße Deployment nach dem Neustart zu ermöglichen.

Der ServiceMetaDataParser.parseValueFactoryParameter() berücksichtigt nur das erste Child des <parameter>-Elements. Ist das <null/> Child-Element also von Zeilenumbrüchen ('Enter' oder Leerzeichen) umgeben, so wird der Node als Textwert behandelt und der Parameter wird später nicht ordnungsgemäß substituiert. Folgendes führt zu einem Fehler:

<parameter>
      <null/>
      </parameter>

<parameter>
      <null/>
      </parameter>

Sie umgehen das Problem indem Sie sicherstellen, dass sich kein Leerzeichen in <parameter>-Elementen befindet:

      <parameter><null/></parameter>

      <parameter><null/></parameter>

Wenn java.sql.Date.valueOf versucht Daten des Formats yyyy-mm-dd zu parsen, meldete der TCK-Test eine java.lang.IllegalArgumentException. Der Grund hierfür war eine Regression in der aktuellsten Sun JVM, Sun JDK 1.6.0_18-b07 (weitere Informationen finden Sie unter http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6898593). Die Lösung für dieses Problem besteht in einem Downgrade zu Sun JDK 1.6.0_17-b04.

Jedes Mal, wenn ein org.jboss.mail.MailService konfiguriert und an ein JNDI gebunden wird, werden die SessionObjectFactories-Properties überschrieben. Das bedeutet, dass wenn mehrere MailService-Konfigurationen existieren, alle an JNDI gebundenen MailServices die Properties des zuletzt konfigurierten MailService in ihrer Session haben.

In isolierten Deployments wird eine ClassNotFoundException gemeldet, wenn der Applikationsserver versucht, ein mit dem Timer assoziiertes info-Objekt zu deserialisieren . Dies geschieht, weil der falsche Klassenlader (threadContextClassLoader) zur Deserialisierung des Objekts verwendet wird.

Beim Zugriff auf die Admin-Konsole werden WARN-Nachrichten mit dem Text "Cannot get the process table information without native support" in den Protokollen generiert. Sie können diese Nachrichten problemlos ignorieren. In einer zukünftigen Release der Admin-Konsole werden diese Nachrichten in INFO geändert .

Ein Fehler bei JVM-Implementierungen bedeutet, dass die JVM abstürzen kann wenn während des Hot Deployments ein unvollständiges Deployment durch eine neue Version des Deployments überschrieben wird. Ein Deployment kann einen Formatierungsfehler in einem Deployment Deskriptor enthalten. Beim Deployment kommt dieser Fehler zum Tragen und das Deployment schlägt fehl. Wird ein korrigiertes Deployment über das fehlerhafte Deployment kopiert um es zu ersetzen, so ist es möglich, dass die JVM während des Hot Deployments der neuen Version abstürzt. Sie umgehen das Problem, indem Sie das alte, unvollständig deployte Archiv entfernen, ehe Sie das neue, korrigierte Deployment in das deploy-Verzeichnis kopieren.

Das jboss_init_hpux-Skript übernimmt keine Umgebungsvariablen, wenn es in der GNU Bash Shell ausgeführt wird. Dies hängt zusammen mit JBPAPP-2036: https://jira.jboss.org/jira/browse/JBPAPP-2306.

Die -e- und -H-Argumente des shutdown.sh-Skripts können nicht dazu verwendet werden, die JVM direkt zu beenden.

Wird der Server über ein Desktop-Symbol gestartet, so wird der standardmäßige Javasatz der Maschine verwendet. Dies kann zu Ausnahmen führen, wenn eine andere Java-Version als JDK 1.6 als Standard eingestellt ist. Benutzer sollten sicherstellen, dass JDK 1.6 als standardmäßige Java-Version eingestellt ist, ehe Sie versuchen die JBoss Enterprise Application Platform über das Desktop-Symbol zu starten.

Das Setzen der hibernate.bytecode.provider-Systemeigenschaft in jpa-deployers-jboss-beans.xml ist unzuverlässig. Fügen Sie zur Umgehung dieses Problems -Dhibernate.bytecode.provider=cglib zur $JAVA_OPTS in jboss-as/bin/run.conf hinzu.

Es wurden eine hohe CPU-Auslastung sowie eingeschränkte Leistung und Transaktionsdurchsatz beobachtet, wenn MySQL 5.0.41 mit optimierten Einstellungen wie in JBQA-2610 beschrieben verwendet wird. Wir empfehlen, auf MySQL 5.0.86 zu aktualisieren und optimierte Einstellungen wie unter JBQA-2610 beschrieben anzuwenden, um die CPU-Auslastung zu begrenzen und die Leistung zu erhöhen.

Sobald das JBAS-7049-Problem allerdings wie beschrieben umgangen wird, ergibt sich dadurch ein neues Problem. Der Start eines Servers, auf dem unter Verwendung von Open JDK 6 der Sicherheits-Manager ausgeführt wird, wird immer noch fehlschlagen, diesmal mit einem "access denied"-Fehler. Derzeit gibt es keine Möglichkeit, dieses Problem zu umgehen.

Beim Einsatz von IBM JDK 6 besteht ein Problem im policy.provider, der in ${JAVA_HOME}/jre/lib/security/java.security definiert ist. Standardmäßig wird org.apache.harmony.security.fortress.DefaultPolicy verwendet, und dies sollte policy.provider=sun.security.provider.PolicyFile sein. Führen Sie zur Behebung dieses Problems diese Anpassung manuell aus.

Der MySQL JDBC-Treiber implementiert XA Recovery derzeit nicht einwandfrei.

Der Server-Manager funktioniert beim Einsatz von Open JDK 6 nicht ordnungsgemäß, da eine NullPointerException-Überprüfung in Open JDK 6 fehlt. Um dieses Problem zu umgehen, kommentieren Sie die java.security.debug-Anweisung in der imports/server-config.xml-Datei aus.

Die IBM-Distribution von JDK 6 unterstützt das SSLv2Hello-Protokoll nicht und generiert einen ERROR [AbstractKernelController], wenn dies verwendet wird. Es wird derzeit davon abgeraten, dieses Protokoll zu verwenden.