You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 10, 2024. It is now read-only.
Problem:
If StructurizrPlantUMLExporter is compiled into a native binary with graalvm, it crashes at runtime since AWT classes are not available,
Context:
The plant UML exporter uses java.awt.image.BufferedImage to determine the icon size but this is not available on the classpath currently in graalvm builds.
There is currently an UnsatisfiedLinkError that is thrown when this happens but since the try/catch handler in the method that uses BufferedImage is only catching Exception, this isn't caught.
Solution:
I believe the simplest solution is to simply catch ANY Throwables inStructurizrPlantUMLExporter#calculateIconScale
This will allow the process to continue on, without completely failing. Possibly we could just also just swallow UnsatisfiedLinkErrors rather than printing the stacktrace in that case, since this is a known error and not one we'd want to spam the logs for.
The text was updated successfully, but these errors were encountered:
Problem:
If StructurizrPlantUMLExporter is compiled into a native binary with graalvm, it crashes at runtime since AWT classes are not available,
Context:
The plant UML exporter uses java.awt.image.BufferedImage to determine the icon size but this is not available on the classpath currently in graalvm builds.
There is currently an UnsatisfiedLinkError that is thrown when this happens but since the try/catch handler in the method that uses BufferedImage is only catching Exception, this isn't caught.
Solution:
I believe the simplest solution is to simply catch ANY Throwables in
StructurizrPlantUMLExporter#calculateIconScale
This will allow the process to continue on, without completely failing. Possibly we could just also just swallow UnsatisfiedLinkErrors rather than printing the stacktrace in that case, since this is a known error and not one we'd want to spam the logs for.
The text was updated successfully, but these errors were encountered: