Beiträge von Admiral_Zott

    Bist du dir sicher, dass nur die ältere Version exportiert wird, oder nimmst du immer nur die falsche Datei zum Testen? Versuch einfach mal die Version von deinem Projekt zu erhöhen und Exportiere dann nochmal. Dort sollte ja dann die neue Version mit im Namen der Datei stehen. Wenn dass nicht funktioniert, kannst du ja mal folgenden Build verwenden und mal schauen, ob es damit funktioniert.

    Zu beachten hierbei ist, dass der tag <mainClass>${project.groupId}.${project.artifactId}.Main</mainClass> auf deine Hauptklasse zeigen muss, in der du dein Plugin startest.

    Außerdem werden zwei Dateien generiert. Eine ohne die zusätzlichen Dependencies und eine mit. Hierbei solltest du die mit den Dependencies verwenden, da dort auch dein javax.mail mit kompiliert wird.

    Bei der Dependency von javax.mail solltest du mal noch den scope compile hinzufügen. Dadurch wird die Dependency beim kompilieren mit "verpackt".

    XML
    1. <dependency>
    2. <groupId>javax.mail</groupId>
    3. <artifactId>javax.mail-api</artifactId>
    4. <version>1.6.0</version>
    5. </dependency>

    Das sähe dann in etwa so aus:

    XML
    1. <dependency>
    2. <groupId>javax.mail</groupId>
    3. <artifactId>javax.mail-api</artifactId>
    4. <version>1.6.0</version>
    5.             <scope>compile</scope>
    6. </dependency>

    Ach ja, und du könntest mal die Version von javax.mail auf 1.6.2 updaten. Laut https://mvnrepository.com/arti…mail/javax.mail-api/1.6.2 ist die die aktuelle.

    Wie zM4xi schon geschrieben hat, BASE64 ist eine Lösung, aber meiner Meinung nach keine schöne. Durch die Konvertierung von Dateiformaten (dazu gehören auch .pdf und alle Bilder) entsteht ein String der eine 1,5fache Größe des ursprünglichen Dokuments hat. Dies zieht Speicherplatz und performance. Sinnvoller wäre es die Datei, wie du schon die Idee hattest, in ein Dateisystem zu schieben und nur noch den Pfad in einer Datenbank zu speichern. Eine andere Alternative ist der Datentyp BLOB. Dieser ist dafür gedacht, Datei direkt in Datenbanken zu speichern. Hierbei hast du auch nicht mehr den unschönen Nachteil der 1,5fachen Speichergröße.


    Zur Filterung ist JSON auch eine Lösung, aber leider nicht wirklich performant, da die JSON immer wieder vom Programm encoded und decoded werden muss. Zudem werden sehr viele Daten doppelt auftreten, wie JD1992 schon sagte. Hier würde ich auf einzelne Bits setzten, die du in der Datenbank setzt. Diese kannst du dann mit den Bitwise Operatoren (&,|,^) wieder auslesen. Vorteil ist hier, dass du nur eine sehr kleine Datenmenge hast, die du speichern musst und das Auslesen und Auflösen sehr sehr performant ist.

    Habe mir mal deine Klasse gezogen und mal bisschen bearbeitet. Ist sogar nen bisschen abstrakter geworden als gedacht :)

    Funktioniert jetzt auf jeden Fall alles. Bei der PropertiesConfiguration musst du vielleicht nochmal drüber schauen. Da klappt noch nicht ganz alles mit Maps usw (ist aber nur ne Kleinigkeit)


    Ach ja, configuration.tar einmal zum downloaden :D

    Habe das gerade mal mit verschiedenen Datentypen durchgetestet und bin auf keine Probleme gestoßen. Hast du auch eine aktuelle Gson version?


    Als Ausgabe habe ich wie erwatet folgendes bekommen: {"IntArray":[23,42],"HashMap":{"one":1,"two":2},"ArrayList":["eins","zwei"],"Int":1337}

    Du kannst auch einfach php7.1 neben 7.2 installieren. Einfach dann in deiner Apache2 Config den Pfad zu PHP ändern. Ausführen direkt in der Console kannst du es dann mit php7.1 --version.

    Wenn du die Objekt Value in einer Map updaten willst, kannst du das einfach machen, ohne diese dann wieder zurück zu schreiben.

    Code
    1. Map<Integer, ArrayList<String>> map = new HashMap<>();
    2. ArrayList<String> arrayList = map.get(20);
    3. arrayList.add("Test Message");

    Dies funktioniert durch die Pointer die auf das ArrayList Objekt zeigen. Wenn du mal den Debug Modus in deiner IDE startest, siehst du, dass arrayList und der 20te Eintrag in deiner Map die selbe Id haben.

    Bitte prüf mal deinen Code auf Objekte, die du Statisch in Variablen speichert.
    Diese können Memory-Leaks produzieren. Wie schon gabriel2029 erwähnt hat, solltest du hier diese Variablen nur in einer WeakReference speichern. Am besten übergibst du diese schon bei der Initialisierung des Runnables und speicherst das Objekt in die WeakReference.

    Ich glaube auch, dass der Craft Scheduler Thread nicht nur in deinen Runnables läuft. Um den Server am leben zu halten läuft immer irgend ein (oder mehrere) Thread der auf etwas lauscht.


    // EDIT

    Noch böser wird der ganze Spaß, wenn du den Timer asynchron laufen lässt und das Objekt auf einmal null ist. Da ist eine WeakReference das beste was du machen kannst. Solltest du natürlich dann auf null checken. reference.get() != null

    Um es ein bisschen performanter zu gestalten, könntest du nen async Timer mit laufen lassen und ca alle 10 Sekunden prüfen, ob sich ein Spieler in z.B. einem 50 Block Radius um deine Region befindet. Wenn ja, steckst du den in eine Liste und prüfst mit dem MoveEvent ob er nun die Region betritt oder halt nicht.

    Das zweite was einiges an Performance zieht, ist deine Instance von SuperAPI die du in deinem Objekt zwischenspeicherst. Sowas verursacht Leaks und kostet Rechenzeit.