hbarthel
New Responder

API vs. Nicht-API in fs-api.jar

Jump to solution

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

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
Windmüller
Crownpeak employee
Crownpeak employee

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

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

View solution in original post

0 Kudos
6 Replies
pavone
I'm new here

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

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

0 Kudos
hbarthel
New Responder

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

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

0 Kudos
Windmüller
Crownpeak employee
Crownpeak employee

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

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

0 Kudos
hbarthel
New Responder

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

In dem Fall sollte man das Halbzeug fs-api.jar zurück ziehen, verwirrt nur.

0 Kudos
ronlange
I'm new here

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

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

0 Kudos
ChKo
Returning Observer

Re: API vs. Nicht-API in fs-api.jar

Jump to solution

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

0 Kudos