Search the FirstSpirit Knowledge Base
Hallo Community,
überall sieht man, dass gegen fs-access.jar oder fs-client.jar implementiert wird. Nutzt man dann aber Klassen, die angeblich nicht zur API gehören, hört man vom Support oder hier oft, dass man sich doch an die API halten soll.
Also habe ich ein neues Modul begonnen, das ich strikt gegen die API impl. wollte und scheitere schon bei einem leeren Executable:
import java.io.Writer;
import java.util.Map;
import de.espirit.firstspirit.access.script.Executable;
public class FsApiTest implements Executable {
@Override
public Object execute(Map<String, Object> arg0) throws ExecutionException {
return null;
}
@Override
public Object execute(Map<String, Object> arg0, Writer arg1, Writer arg2) throws ExecutionException {
return null;
}
}
Die ExecutionException fehlt in der API. Was ist der Sinn der fs-api.jar?
Danke und Gruß
Heiko
Hallo Heiko,
aktuell ist fs-api nicht abgeschlossen. Das ist uns bekannt, wir arbeiten dran.
Als Alternative kann das fs-isolated-runtime verwendet werden. Dies arbeitet nicht nur gegen die API und sollte die fehlenden Klassen enthalten.
Grüße
Stephan
Hallo Heiko,
da hast du recht, das ist etwas ungeschickt. Du kannst diese und weitere Unstimmigkeiten, die dir auffallen sollten gerne an unseren Tech. Support. melden.
In diesem konkreten Fall kannst du das throws Statement natürlich einfach weg lassen, weil ExecutionException keine Checked Exception ist.
Viele Grüße
Tim
Hallo Tim,
jeder vernünftige Compiler meldet dann, dass die Exception-Klasse implizit vom Interface Executable benötigt wird. Ist also auch nicht kompilierbar.
Ich sag' mal so: wenn der fs-api-Versuch schon am Anfang scheitert, wo soll das enden, wenn ich anfange, sowas an den Support zu melden?
Interessant wäre, wie die fs-api.jar gebaut wird. Sie kann ja kein eigenes Artefakt sein, denn sie ist in sich nicht schlüssig und sollte von der Qualitätssicherung abgedeckt sein.
Gruß
Heiko
Hallo Heiko,
aktuell ist fs-api nicht abgeschlossen. Das ist uns bekannt, wir arbeiten dran.
Als Alternative kann das fs-isolated-runtime verwendet werden. Dies arbeitet nicht nur gegen die API und sollte die fehlenden Klassen enthalten.
Grüße
Stephan
In dem Fall sollte man das Halbzeug fs-api.jar zurück ziehen, verwirrt nur.
Hallo Stephan,
wir stellen hier gerade unsere Module alle auf isolated um und ich muss dir leider widersprechen. Wir bauen gegen die fs-isolated-runtime, dennoch sind Klassen wie beispielsweise ExecutionException weiterhin nicht-öffentliche API und werden dadurch vom FSM-Checker bemängelt. Eine echte Altertive ist das nicht...
Grüße
Ron
Hallo Ron,
da ExecutionException keine checked Exception mehr ist, sollte das eigentlich kein Problem sein.
Einfach die Verwendung "throws ExecutionException" entfernen und schon sollte es passen.
Gruß,
Christopher