matthiasforberg
Occasional Collector

usage of deprecated method getStoreElement() - aber wo?

Jump to solution

Hallo,

mit jedem Klick im Sitearchitect wird in unserem Projekt dreimal(!) folgende Warnung in der Konsole ausgegeben bzw. ins Server-Log geschrieben:

WARN  27.09.2018 17:00:55.569 (de.espirit.firstspirit.impl.access.ScriptContextImpl): usage of deprecated method 'ClientScriptContext.getStoreElement()', please use 'ClientScriptContext.getElement()'

Ich habe zigmal alle Skripte geprüft, in allen Kanälen und den Einblendelogiken, es wird definitiv nicht ein einziges getStoreElement() verwendet. Die Vermutung liegt nahe, dass das in irgendeinem der installierten Module steckt. Aber in welchem??? Wie finde ich das raus? Gibt es da eine Möglichkeit, ohne alles decompilieren zu müssen? Die "Erweiterte Protokollierung" gibt mir auch nicht mehr aus.

Viele Grüße
Matthias

1 Solution

Accepted Solutions
eginger
Returning Observer

Ich würde einfach mal ins Blaue raten, das es die Einblendelogik der Freigabe/Löschworkflows/etc. ist.

Die "neue" FS Suche kann man an der Stelle auch wieder vergessen:

fs_suche.png

View solution in original post

5 Replies
thmarx
I'm new here

Hallo Matthias,

ja, das ist wirklich nicht.

Da es ein ScriptContext ist, würde ich vermuten, es ist entweder direkt in einem Skript oder in einer Executable, die in einem Skript ausgeführt wird, verwendet wird. Oder vielleicht irgendeine Klasse, die in einem Skript verwendet wird.

Was helfen würde, wenn du mehr Logging posten könntest, evtl. kann man an dem was vor und hinter dieser Warning geloggt wird erkennen, wo genau es herkommt.

Gruß

Thorsten

0 Kudos
mikula
Crownpeak employee

Welche FS Version habt ihr im Einsatz?
Welche Module habt ihr im Einsatz?
Sind die Module alle auf aktuellem Stand?

0 Kudos

Hallo Matthias,

kannst du das lokal oder auf einem Dev-System nachstellen? Falls dies der Fall ist, würde sich anbieten für den FirstSpirit-Server einfach mal das Remote-Debugging anzuwerfen. Du kannst, sofern du z.B. IntelliJ verwendest und das server.jar als Dependency irgendwo drin hast, die ScriptContext-Datei mal öffnen (direkt das class-File), und die Logausgabe suchen. Dort setzt du einen Breakpoint, klickst im SiteArchitect, und solltest so an den StackTrace kommen, der dich (hoffentlich) dort hin führt, wo das Problem her kommt.

Ich gebe zu, dass das nicht wirklich extrem elegant ist, aber zumindest kannst du so die Ursache feststellen. Remote-Debugging auf einem System, auf dem Redakteure tätig sind, bietet sich natürlich nicht an (das unterbricht möglicherweise alle Verbindungen, die gerade laufen, wenn du am Breakpoint stehen bleibst).

Das remote-Debugging kannst du einschalten, indem du in der fs-wrapper.conf folgendes hinzufügst:

wrapper.java.additional.9=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

Dann müsstest du den fs-server herunter- und wieder hochfahren, und kannst dann auf Port 5005 den Server erreichen.

Viele Grüße,

Lena

0 Kudos
eginger
Returning Observer

Ich würde einfach mal ins Blaue raten, das es die Einblendelogik der Freigabe/Löschworkflows/etc. ist.

Die "neue" FS Suche kann man an der Stelle auch wieder vergessen:

fs_suche.png

Danke, danke, danke!!! :smileycool:

Die Basic Workflows waren es tatsächlich! Und die werden von der Suche nicht gefunden, wenn ich nach "getStoreElement" suche.

Vielen herzlichen Dank!
Matthias

0 Kudos