Verbesserung
Wichtig
Detail
Fehlerbehebung
Detail
#25612
Modell Editor zeigt bei Änderungen von Referenzen Verknüpfungsenden in der Attributtabelle an
#26484
In-App Template für Grid und Tabellen: Funktion "Prüfer für Benutzung als Listenelement" bekommt Komponentenmodell nicht
#26569
Fehlende Constraint-Violation beim Löschen von Objekten die von Pflichtfeldern referenziert werden
#26884
Deklarative Formulare: Fehlendes GUI update bei programmatischen Änderungen eines List-wertigen Property
#26885
Constraints an deklarativen Formularen mit Argumenten aus einer Container-Referenz führen bei neuen Elementen zu Fehlern
#26890
Überschriebene Eigenschaften werden beim Booten aus Modelldefinition nicht richtig initialisiert
#26922
Mit generierten Fachklassen erhält ein Default-Provider eines Attributs in einer Nicht-Struktur-Klasse keinen Create-Context
Fehlerbehebung
Abhängig von der Größe des erzeugten WARs und der Maschine, auf der der Build läuft, scheint die WAR-Erzeugung unverhältnismäßig viel Speicher zu allokieren - deutlich mehr, das die Größe des erzeugten Ergebnisses.
Für die WAR-Erzeugung wird u.a. das maven-archiver Plugin benutzt, das seinerseits das plexus-archiver Plugin verwendet.
Es wird berichtet (https://stackoverflow.com/questions/54406918/maven-war-plugin-version-cause-oom), dass plexus-archiver ab Version 2.9.1 Probleme mit exzessivem Speicherverbrauch hat. Angeblich sind diese zwar behoben (https://issues.apache.org/jira/browse/MSOURCES-94), können aber immer noch beobachtet werden:
Caused by: java.lang.OutOfMemoryError: Java heap space at org.codehaus.plexus.archiver.zip.ByteArrayOutputStream.needNewBuffer (ByteArrayOutputStream.java:153) at org.codehaus.plexus.archiver.zip.ByteArrayOutputStream.write (ByteArrayOutputStream.java:192) at org.apache.commons.io.output.ThresholdingOutputStream.write (ThresholdingOutputStream.java:232) at org.codehaus.plexus.archiver.zip.DeferredScatterOutputStream.writeOut (DeferredScatterOutputStream.java:44) at org.apache.commons.compress.archivers.zip.StreamCompressor$ScatterGatherBackingStoreCompressor.writeOut (StreamCompressor.java:291) at org.apache.commons.compress.archivers.zip.StreamCompressor.writeCounted (StreamCompressor.java:273) at org.apache.commons.compress.archivers.zip.StreamCompressor.deflate (StreamCompressor.java:264) at org.apache.commons.compress.archivers.zip.StreamCompressor.deflateUntilInputIsNeeded (StreamCompressor.java:257) at org.apache.commons.compress.archivers.zip.StreamCompressor.writeDeflated (StreamCompressor.java:238) at org.apache.commons.compress.archivers.zip.StreamCompressor.write (StreamCompressor.java:205) at org.apache.commons.compress.archivers.zip.StreamCompressor.deflate (StreamCompressor.java:184) at org.apache.commons.compress.archivers.zip.ScatterZipOutputStream.addArchiveEntry (ScatterZipOutputStream.java:100) at org.apache.commons.compress.archivers.zip.ParallelScatterZipCreator$4.call (ParallelScatterZipCreator.java:237) at org.apache.commons.compress.archivers.zip.ParallelScatterZipCreator$4.call (ParallelScatterZipCreator.java:233) at java.util.concurrent.FutureTask.run (FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628) at java.lang.Thread.run (Thread.java:829)
Lösung
Downgrade auf maven-archiver 3.0.0 und plexus-archiver 2.9.1.
Test
- Bauen eines großen WAR (150M) mit einer VM, mit Max-Memory-Limit von 256M. Abhängig von der Maschine reicht auch ein viel größerer Speicher von 1G nicht aus, um das WAR zu bauen.