Major
Detail
Major
Detail
#26382
Error messages "Duplicate tag name..." when starting an application in the IDE from a TL-Studio
#26405
TTypeRewriter logs warning "Unable to resolve items by external reference" also unnecessarily
#26431
Changed superclass relationship leads to changed attribute list in the form editor only after a restart
#26484
In-app template for grid and tables: Function "Verifier for use as list item" does not get component model
#26536
When rendering HTML from TLScript expressions, configured renderers are not taken into account
#26797
Transaction with user input: invisible properties of the form model cannot be assigned values (initialized)
#26885
Constraints on declarative forms with arguments from a container reference lead to errors for new elements
#26921
ClassCastException when evaluating security rules that refer to (non-structuredElement) singletons of a module.
#26922
With generated subject classes, a default provider of an attribute in a non-structure class does not get a create context
#26988
In-app documentation generator does not extract documentation for overwritten config properties
#27027
Declarative forms: SelectField disappears after upload if option list depends on mandatory property
#27042
MaintenanceJspBase should write to the log first, then to the client, instead of the other way around.
Bugfix
Depending on the size of the generated WAR and the machine running the build, WAR generation seems to allocate a disproportionate amount of memory - significantly more than the size of the generated result.
One of the tools used for WAR generation is the maven-archiver plugin, which in turn uses the plexus-archiver plugin.
It is reported(https://stackoverflow.com/questions/54406918/maven-war-plugin-version-cause-oom) that plexus-archiver as of version 2.9.1 has problems with excessive memory consumption. Supposedly these are fixed(https://issues.apache.org/jira/browse/MSOURCES-94), but can still be observed:
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)
Solution
Downgrade to maven-archiver 3.0.0 and plexus-archiver 2.9.1.
Test
- Build a large WAR (150M) with a VM, with max memory limit of 256M. Depending on the machine, even a much larger memory of 1G is not enough to build the WAR.