private void doAction() throws IllegalStateException, IOException, AuthenticationFailedException, TimeoutException
{
OriginateAction originateAction;
ManagerResponse originateResponse;

originateAction = new OriginateAction();

if (sSipServer != null)
{
log.info(“OriginateTo: ” + sCallMethod + “/” + sCallerNumber + “@” + sSipServer);
originateAction.setChannel(sCallMethod + “/” + sCallerNumber + “@” + sSipServer);
}
else
{
log.info(“OriginateTo: ” + sCallMethod + “/” + sCallerNumber);
originateAction.setChannel(sCallMethod + “/” + sCallerNumber);
}
originateAction.setContext(sContext);
originateAction.setExten(sCalleeNumber);
originateAction.setPriority(iPriority);
originateAction.setTimeout(iTimeOut);
originateAction.setAsync(true);

// connect to Asterisk and log in
managerConnection.login();

// send the originate action and wait for a maximum of 30 seconds for Asterisk
// to send a reply
originateResponse = managerConnection.sendAction(originateAction, 30000);

// print out whether the originate succeeded or not
log.info(“originateResponse: ” + originateResponse.getResponse());

// and finally log off and disconnect
managerConnection.logoff();
}

EDIT: Hat sich alles erledigt, ich hatte nur eine Variable falsch gesetzt << … damn Millisekunden … ^^

Hat man mal ein dynamisches Webprojekt in Eclipse mit Tomcat 6 angelegt und will nun zurück auf Tomcat 5.5, kann das scheinbar nicht ganz so einfach sein. Will man nämlich in den Projekt Facets einfach die Dynamic Web Modul API von 2.5 auf 2.4 ändern, geht dies nicht. Man kann es zwar auswählen, doch nicht bestätigen, da Eclipse die Übernahme der Optionen verweigert.

Doch lässt sich dies ganz einfach Lösen. Einfach nicht den Einstellungs-Dialog von Eclipse nutzen und schon wird alles ganz einfach. In Eclipse einfach den Navigator-View auf machen und im betroffenen Projekt den Ordner “.settings” öffnen. Hier finden wir nun einiges Konfigurationsdateien, die zwar ganz nett sind, die Interessante ist aber “org.eclipse.wst.common.project.facet.core.xml“. Diese öffnen wir und ändern dort einfach den Parameter “<installed facet=”jst.web” version=”2.5″/>“. Hier nur die 2.5 gegen 2.4 austauschen, speichern und fertig. Und schon haben wir unsere Servlet API geändert. Jetzt sollte das Projekt auch wieder im Tomcat 5.5 laufen.

export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \

Danach hat man erstmal grob Zugang zum Tomcat. Natürlich sollte man das noch mit SSL und nem Passwort absichern. Doch ich wollte erstmal die grundsätzliche Funktionalität Testen. Doch jegliche Versuche damit schlugen fehl. Ersteinmal sei auch gesagt, dass ein “export” davor muss und kein “set“, wie manche schreiben. Bei einer normalen Tomcat Installation ist es damit dann auch schon getan. Doch bei Gentoo muss das ganze nicht in die catalina.sh eingetragen. Trägt man es dort ein, wird es schlicht und einfach ignoriert. Also wohin nun damit? Für den an Gentoo gewöhnten Admin ist es klar das das nach “/etc/conf.d/tomcat-5.5” muss, für einen Debian/Ubuntu Admin ist dies allerdings nicht ganz so klar. Und auch Google verschwieg mir dies Information. Ich hatte mich dann nur daran erinnert das neulich beim Apache ähnlich schritte vollführt werden mussten. Da war es dann auf einmal auch ganz logisch, das dies beim Tomcat ähnlich sein würde. Doch darauf kam ich erst nach einer deprimierenden Suche und vielen im Nachhinein unnötigen Test.

In die “/etc/conf.d/tomcat-5.5” muss nun eben das ganze ohne “export” am Anfang eingetragen werden. Wenn man in der Datei ein wenig nach unten geht, findet man auch schon eine dafür vorbereitet Stelle, um die Daten dort einzufügen. Natürlich können sie innerhalb der Datei überall stehen, doch ein wenig Ordnung schadet ja auch nicht. Also hab ich dann dort Folgendes eingefügt:

export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \

Nachdem ich also alles in “/etc/conf.d/tomcat-5.5” eingetragen hatte, den Tomcat zum X. mal neu gestartet hatte, konnte ich mich nun endlich per jconsole auf diesen verbinden und mir das innere der JVM ansehen.

<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter" />

Und damit wären wir auch schon fertig! Jetzt wird beim kompilieren mit dem “javac task” immer ECJ genommen anstatt der Compiler des System-JDK.

Und wenn man mal “fehlerhafte” Klassen kompilieren will, kann man jetzt das “javac Flag” “failonerror” auf “off” setzten. Anders als der Standard Java Compiler, welcher den build-Prozess dann zwar als erfolgreich markiert, aber nichts macht, kompiliert ECJ auch fehlerhafte Klassen. Also zum Beispiel Klassen wo wiederum andere Klassen importiert werden, welche aber nicht im “Classpath” stehen. Denn ECJ bietet das Feature “proceedOnError”, welche durch ”failonerror=off” gesetzt wird.

<javac failonerror="off"> blubb </javac>

Doch ein wenig versteckt biete Sun alle seine Versionen doch noch an. Es gibt sogar ein nettes Interface was einem dies leicht zugänglich macht:  Das SUN Java Archive