quarkus: Quarkus Awt extension doesnt work after upgrading to 3.2.3-Final when using native build

Describe the bug

We use Font class from java-awt to parse the font. After upgrading the quarkus from 3.0.3 to 3.2.3-Final. The feature is broken and i get the error “no awt in java.library.path” with the exception "“java.lang.UnsatisfiedLinkError”.

Expected behavior

The expected is to not to get the exceptions and should be able to use Font class from java.awt

Actual behavior

i get the error “no awt in java.library.path” with the exception "“java.lang.UnsatisfiedLinkError”.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 31 (21 by maintainers)

Most upvoted comments

@aylwyne Just use a Quarkus version >=3.4.0. The build adds the necessary files automatically to the function.zip.

Thanks. I somehow missed the comment a few back linking to the specific fix in 3.4.0.

Hello @Karm , ah perfect, thanks for your support.

@Karm I created a small reproducer here which tries to convert some HTML into a PDF. When you compile this natively, upload the function.zip to AWS and run the lambda, you get the above mentioned UnsatisfiedLinkError.

Hello @gefloh, the problem is indeed just the missing libraries. I used your code to create my own AWS Lambda and it fails the way you described:

Screenshot 2023-09-04 at 12-59-04 awttest - Lambda

✔️

When I manually added the .so files and re-uploaded the Lambda, it all went well:

OK-Screenshot 2023-09-04 at 13-09-49 awttest - Lambda

…returning it me a bunch base64 encoded bytes. When I decoded it and jammed it into a .pdf file, it opened just fine for me, showing a caption “Test”:

screenshot

I’ll proceed and fix this in Quarkus presently.

@gefloh Thx. I’ll take a look with my AWS.

I have managed to solve the bug for our case that @billapepper was asking about.

In our case we had this in our docker native build in a file called .dockerignore

*
!target/*-runner
!target/*-runner.jar
!target/lib/*
!target/quarkus-app/*

When the native build runs it adds the native libraries to the builds /target directory.

When the Dockerfile.native was building the copy command

COPY target/*.so /work

It was ignoring the *.so files due to the * in .dockerignore.

I have updated the .dockerignore file to

*
!target/*.so
!target/*-runner
!target/*-runner.jar
!target/lib/*
!target/quarkus-app/*

Now the native libraries are included in our docker image and the AWT processing for image resizing works.

As a note a lot of the examples in https://github.com/quarkusio/quarkus-quickstarts/tree/main for example https://github.com/quarkusio/quarkus-quickstarts/blob/main/spring-web-quickstart/.dockerignore have the same incorrect setup, as a lot of people possibly copy these examples as a starting point, might be worth checking there to make sure that the *.so files are actually being included in your docker image under /work.

One thing to note the files in the AWT example https://github.com/quarkusio/quarkus-quickstarts/blob/main/awt-graphics-rest-quickstart/.dockerignore actually has the allow in the docker ifgnore for the *.so libraries

@gefloh Could you whip up a small reproducer project I can use with my AWS account? AWS Lambda is a Linux running somewhere and we must copy the needed libs alongside the main Quarkus application executable to it.