Public Support

Hallo Anja,

wie du ja sicher weißt ist das Dependency Handling eines der Features in ADTF 3.x.
Jedes Plugin bzw. Komponente spezifiziert seine Abhängigkeiten (REQUIRED_INTERFACES), diese werden in die Plugin Description auch exportiert und vom CE entsprechend ausgewertet.
Dadurch wird sichergestellt, dass Laufzeitabhängigkeiten in der korrekten Reihenfolge mit dem geforderten Runlevel im System File gesetzt werden, hier muss der Endanwender keine Hand mehr anlegen.

Im ADTF 2.x sind uns hier bekanntlich die Hände gebunden.

Hallo Florian,
die Dependency Resolution im Configurationseditor ist zwar gut und auch schon besser geworden, löst aber nicht alle Probleme, z.B. werden die Run Level nicht berücksichtigt. Also selbst wenn das benutzt wurde, kann es zu Fehlern kommen. Dann gibt es natürlich noch Fehler der Benutzer und Entwickler, die auch zu sinnvollen Fehlermeldungen führen sollten.
Die Fehlermeldungen wegen nicht gefunden Interfaces sind aber sehr unspezifisch. Man erfährt lediglich, dass der GetObject Aufruf fehl schlug.

Sieht so aus, also ob im rpc_object_regstry.cpp die entsprechenden Exceptions abgefangen werden.
Wäre es möglich:
Das Handling mit den REQUIRED_INTERFACES so ausbauen, dass auch Runtime-Checks mit guten Fehlermeldungen beim laden/initialisieren des Moduls durchgeführt werden. Evtl. zu strikt, da man so nicht die Prüfung abhängig von dem Entsprechenden Initialisierungsschritt macht.

Deshalb alternativ: Die Fehlermeldung mit der angefragten iid bzw. cid ergänzen.
Dann ist da noch das Problem hierbei ist, dass das kein Automatismus ist.
Der Programmierer kann den Eintrag für REQUIRED_INTERFACES versehentlich weglassen und es dennoch benutzen.
In dem Fall fällt die Fehlersuche schwer, wenn man den Source Code nicht hat.

Grüße,
Anja

Hallo Anja,

die Dependency Resolution im Configurationseditor ist zwar gut und auch schon besser geworden, löst aber nicht alle Probleme, z.B. werden die Run Level nicht berücksichtigt.
Also selbst wenn das benutzt wurde, kann es zu Fehlern kommen.

Das stimmt nicht, was meinst du damit ?
In jedem Service wird ein Default Runlevel definiert, das gibt der Entwickler vor und so landet es auch in der Plugin Description.
Siehe https://support.digitalwerk.net/adtf/v3/guides/sdk_generate_plugin_description.html
Wer das ändert, bricht den Vertrag und muss sich dessen bewusst sein. Oder verstehe ich dich falsch ?

Was wir noch anbieten wollen:

• Einen Hinweis und Reset Funktion, wenn das default runlevel geändert wird (ACORE-10426)
• Dass der Launcher bzgl. noch mehr checks und Ausgabe (Abhängigkeiten, default Vergleich, etc) zur Laufzeit durchführt beim Start (ACORE-10425)

Dann gibt es natürlich noch Fehler der Benutzer und Entwickler, die auch zu sinnvollen Fehlermeldungen führen sollten.
Die Fehlermeldungen wegen nicht gefunden Interfaces sind aber sehr unspezifisch. Man erfährt lediglich, dass der GetObject Aufruf fehl schlug.

Sieht so aus, also ob im rpc_object_regstry.cpp die entsprechenden Exceptions abgefangen werden.

Das hat aber imho nichts mit Dependencies zu tun, hier wird versucht sich an ein System zu docken (Control, GUI Control), dass nicht existiert, richtig ?
Also wenn du nur mit Launcher ausführst, hättest du im Log die eigentliche Fehlermeldung davor und diese eben nicht ?

@Martin: Können wir hier besser werden ? Die leere Angabe ist sicherlich nichtssagend...

Wäre es möglich:
Das Handling mit den REQUIRED_INTERFACES so ausbauen, dass auch Runtime-Checks mit guten Fehlermeldungen beim laden/initialisieren des Moduls durchgeführt werden. Evtl. zu strikt, da man so nicht die Prüfung abhängig von dem Entsprechenden Initialisierungsschritt macht.

Das soll wie gesagt in ACORE-10425 noch tiefer gehen

Deshalb alternativ: Die Fehlermeldung mit der angefragten iid bzw. cid ergänzen.

Wie gesagt, ich denke das Problem hier ist dass gar kein ADTF System besteht, das per RPC angesrochen wird

Dann ist da noch das Problem hierbei ist, dass das kein Automatismus ist.
Der Programmierer kann den Eintrag für REQUIRED_INTERFACES versehentlich weglassen und es dennoch benutzen.
In dem Fall fällt die Fehlersuche schwer, wenn man den Source Code nicht hat.

Das hat man an so vielen Stellen in der Programmierung, das gibt aber C++ ohne Reflection leider nicht her und wir wollen nicht den Code parsen.
Das sind Makros die einfach verwendet werden müssen im ADTF Kontext (analog zu Header includes), gilt ja auch für ADTF_PLUGIN.
Wir haben versucht, dass hier zu dokumentieren:

• https://support.digitalwerk.net/adtf/v3/adtf_html/page_versioned_namespaces.html

Hallo Anja,

ich habe für aussagekräftigere Fehlermeldungen das Ticket https://www.cip.audi.de/jira/browse/ACORE-10428 erstellt. Dadurch sollte man jetzt immer zumindest die ID des gesuchten Interfaces in der Fehlermeldung bekommen (und auch die Object IDs der abgefragten Objekte).

Grüße,

Martin

Hallo Anja,

Martin wrote:

ich habe für aussagekräftigere Fehlermeldungen das Ticket https://www.cip.audi.de/jira/browse/ACORE-10428 erstellt. Dadurch sollte man jetzt immer zumindest die ID des gesuchten Interfaces in der Fehlermeldung bekommen (und auch die Object IDs der abgefragten Objekte).

nach Umsetzung von ACORE-10428 sieht die Meldung nun so aus:

ADTF Runtime Exception

Exception occurred while running adtf:
Result code '-20 '(ERR_NOT_FOUND) - default_streaming_graph.Demo Virtual Clock Input: No object with the requested interface found:
'logging.system.adtf': Object does not implement interface 'reference_clock.giant.streaming.adtf.iid'.
'license_manager.system.adtf': Object does not implement interface 'reference_clock.giant.streaming.adtf.iid'.
'macro_resolver.system.adtf': Object does not implement interface 'reference_clock.giant.streaming.adtf.iid'.
'rpc_object_server_registry.system.adtf': Object does not implement interface 'reference_clock.giant.streaming.adtf.iid'.
'session_manager.system.adtf': Object does not implement interface 'reference_clock.giant.streaming.adtf.iid'.
'ADTF Kernel Service': Object does not implement interface 'reference_clock.giant.streaming.adtf.iid'.
[File: c:\dev\acore\source\src\libraries\ucom3\src\runtime.cpp] [Line: 1244] [Func: adtf::ucom::catwo::detail::cRuntime::cRuntimePrivate::GetObject]
[File: c:\dev\acore\source\src\examples\src\adtf\streaming_services\sources\virtual_clock\demo_virtual_clock.cpp] [Line: 62] [Func: cDemoVirtualClock::StartStreaming]
[File: c:\dev\acore\source\src\libraries\streaming3\src\streaming_graph.cpp] [Line: 387] [Func: adtf::streaming::catwo::cStreamingGraph::SetStateImpl]
[File: c:\dev\acore\source\src\plugins\adtf_core\session_manager.cpp] [Line: 75] [Func: set_session_streaming_state]
[File: c:\dev\acore\source\src\plugins\adtf_core\session_manager.cpp] [Line: 169] [Func: cSessionManager::RuntimeHook]

Und sollte in diesem Fall Aufschluss geben, dass kein Objekt (Service) geladen ist, der die Version der Reference Clock bereitstellt, welche von Demo Virtual Clock angefragt wird.

Hallo Anja,

Natürlich arbeiten wir hier partnerschaftlich zusammen, das steht hoffentlich außer Frage.

Auf jeden Fall

Martins Vorschläge passen soweit für uns, du warst schneller mit deiner Antwort als ich die Rückmeldung hatte.
Zu dem weiteren offenen Punkt. Ich denke das ist hier ein Missverständnis das aus der Geschichte mit den Toolboxen resultierte und sich nun ja aufgelöst hat, bzw. auf Grund von Martins und deiner weitern Antwort gelöst hat.

Gut, dann schließe ich das Ticket damit ab