Questions & Answers

SOLVED
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

Type a product name