Bereitstellen von Java @Schedule mit Wildfly 8.1.0 Finale

Ich versuche, die @Schedule Anmerkung mit dem folgenden Code zu testen:Bereitstellen von Java @Schedule mit Wildfly 8.1.0 Finale

import javax.ejb.Schedule; 
import javax.ejb.Singleton; 
import javax.ejb.Startup; 

@Singleton 
@Startup 
public class TimerTest { 

    public TimerTest() { 

    } 

    @Schedule(second = "*", minute = "*", hour = "*") 
    public void sayHello() { 
     System.out.println("Hello"); 
    } 

}

Allerdings, wenn ich es in die eigenständige Instanz von Wildfly 8.1.0 bereitstellen (final) Ich erhalte die folgenden Fehlermeldungen in den Protokollen:

2014-09-23 08:38:03,076 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: Failed to start service 
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] 
    at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] 
Caused by: java.lang.NullPointerException 
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959) 
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710) 
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202) 
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] 
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] 
    ... 3 more 

2014-09-23 08:38:07,098 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "test-server.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test-server.war\".component.TimerTest.ejb3.timerService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test-server.war\".component.TimerTest.ejb3.timerService: Failed to start service 
    Caused by: java.lang.NullPointerException"}} 

2014-09-23 08:38:07,145 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report 
JBAS014777: Services which failed to start:  service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: Failed to start service 

JBAS014777: Services which failed to start:  service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService

Irgendwelche Ideen, was könnte dies verursachen?

Quelle

2014-09-23 cardori

Anwendungsserver sollten niemals NullPointerException so werfen, also sollten Sie dies JBoss als Fehler melden. Basierend auf dem "doSTimeoutMethodMatch" könnte ich vermuten, dass der Server versucht, sicherzustellen, dass sich Ihr '@ Schedule' seit seiner ersten Erstellung in einer persistenten Datenbank nicht geändert hat. Versuchen Sie vielleicht, die Tabellen der Zeitgeberdatenbanken (oder was auch immer) zu bereinigen, und versuchen Sie dann, die Anwendung erneut zu implementieren? –

Ich habe etwas recherchiert und die Timer sind im Standalone \ data \ timer-service-data-Ordner gespeichert. Das Entfernen des Timers, der sich hier befindet und das erneute Bereitstellen, hat das Problem tatsächlich behoben. Danke für die Hervorhebung (Ich habe seit einiger Zeit damit zu kämpfen) – cardori

Ich würde wahrscheinlich immer noch das Problem an JBoss melden. Ungeachtet des Inhalts dieser Datei sollte diese NPE nicht auftreten. –

Ich habe das schon einmal gesehen. Wenn Sie in Ihrem WildFly-Verzeichnis eine eigenständige Bereitstellung durchgeführt haben, wird das Verzeichnis standalone/data/timer-service-data angezeigt. Es gibt wahrscheinlich einige alte TimerService-Daten in diesem Verzeichnis. Fahren Sie den Server herunter, löschen Sie diese Daten und versuchen Sie es erneut.

Dies sind wahrscheinlich Daten aus einem Testlauf, der nicht abgeschlossen wurde, bevor der Server heruntergefahren wurde. Denken Sie daran, dass der TimerService persistent ist. Wenn also ausstehende Tasks beim Herunterfahren des Servers ausgeführt werden, wird versucht, diese Tasks zuerst zu übernehmen. Wenn Sie Ihren Krieg aktualisiert haben, werden diese Timer-Prozesse wahrscheinlich nicht mehr den Prozessen im Krieg entsprechen.

Quelle

2015-06-10 15:40:15

Bereitstellen von Java @Schedule mit Wildfly 8.1.0 Finale

Antwort

Verwandte Themen