Closed c0d1ngm0nk3y closed 1 year ago
We added the usage of os.Tempdir()
....
@dmikusa is there a release planned for libjvm?
I was kind of hoping to get https://github.com/paketo-buildpacks/libjvm/issues/158 sorted before cutting a release, but if this one is urgent for you we can move ahead without doing that.
Hi @dmikusa can you release paketo-buildpacks/adoptium with this new version of libjvm? I am using adoptium buildpack and it is not using the latest released version of this libjvm library.
Cheers, Jagrut
We're bumping libpak first, so we can get in a fix there too. The libjvm release should be out shortly. Then we can bump the buildpacks. 🤞 it'll be in this Friday's release.
@tojagrut I just cut releases for all of our JVM provider buildpacks. If you're using one directly you can get that now. Otherwise, we'll bump the composite to include this fix on Friday as part of the normal release cycle.
@loewenstein SAP Machine buildpack is released & includes this fix, and also the other @c0d1ngm0nk3y patched around dependency comparison.
Hello, It looks like this change caused some issues in applications where users used to provide -Djavax.net.ssl.trustStore in JAVA_TOOL_OPTIONS. As you can see below user provided parameter is ignored because of the appended -Djavax.net.ssl.trustStore=/tmp/truststore at the end of JAVA_TOOL_OPTIONS. Is there any workaround to fix this?
P.S. Just found a way - setting BPI_JVM_CACERTS env variable fixes the issue.
@beytularedzheb Please open a new issue, and we can discuss it. Include some details about your use case and why you are setting that flag. Thanks
fixes #281
Summary
In case the truststore is readonly (readonly filesystem), it is copied to
/tmp
and used from there. That allows loadingcacerts
even with a readonly filesystem.If
/tmp
is also readonly, it will still not fail, but warn the user about this. This is the previous behaviour.Use Cases
Container is started with a readonly filesystem for security reasons.
Checklist