Closed miba072 closed 4 years ago
@miba072 I can't seem to replicate this on my end. Can you please provide an example recipe which replicates this?
I just found out that it seems to be somehow related to custom URLs. If I use it like this then it works as intended:
adoptopenjdk_install 8 do
variant 'hotspot'
default true
alternatives_priority 1
end
However if I specify a custom URL then it starts exhibiting the issue I mentioned: (URL changed)
adoptopenjdk_install 8 do
variant 'hotspot'
url 'https://internal.asset.path/to/java/OpenJDK8U-jdk_x64_linux_hotspot_8u232b09.tar.gz'
checksum 'b830c55431faeefd955d7baf4b25571faccfcc79f600848e9fd937dc9fe6ae2a'
default true
alternatives_priority 1
end
I am seeing this as well. I believe the problem is here.
The URL we use is similar to the example @miba072 posted and when I parse the URI in irb the same way the line above does, I get java
as the output. Enforcing a folder structure on people using custom URLs is probably not a great idea.
Here's output for reference:
Working (default URL)
irb(main):006:0> uri.path
=> "/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u242b08.tar.gz"
irb(main):007:0> uri.path.split('/')[-2]
=> "jdk8u242-b08"
Not working (custom URL)
irb(main):003:0> uri.path
=> "/artifactory/java/OpenJDK8U-jdk_x64_linux_hotspot_8u265b01.tar.gz"
irb(main):004:0> uri.path.split('/')[-2]
=> "java"
Thanks for the feedback. I'll need to take a look at this closer and see what the best fix might be.
Thanks @ramereth! I was trying to think about solutions a bit this afternoon. Seems like we might need to revive the functionality of this method.
I was able to reproduce this by doing the following:
adoptopenjdk_install '8' do
variant 'hotspot'
url 'http://ftp.osuosl.org/pub/osl/sous-chefs/OpenJDK8U-jdk_x64_linux_hotspot_8u232b09.tar.gz'
checksum '7b7884f2eb2ba2d47f4c0bf3bb1a2a95b73a3a7734bd47ebf9798483a7bcc423'
default true
alternatives_priority 1
end
Can everyone please see if #632 resolves your problem?
Can everyone please see if #632 resolves your problem?
Just tried it out. Works perfectly!
Can everyone please see if #632 resolves your problem?
Just tried it out. Works perfectly!
Ah nuts. I mistakenly ran the test for 8 only. Didn't seem to work for 11 on my end 🤔
@bkonick What does the filename for 11 look like? OpenJDK11U-jdk_x64_linux_hotspot_11u###b##.tar.gz
? I think I know what the problem is with how I handled it.
:speaking_head: Foreword
When using the adoptopenjdk_install resource it fails to honor the java_home property correctly.
:ghost: Brief Description
Installing adoptopenjdk 8 with the default java_home settings leads to $JAVA_HOME being set to "/usr/lib/jvm/java-8-adoptopenjdk-hotspot/chef" which is a directory that doesn't exist. The installation actually resides in "/usr/lib/jvm/java-8-adoptopenjdk-hotspot/jdk8u232-b09".
Setting the java_home property in the resource to e.g. "/usr/lib/jvm/default-java" sets $JAVA_HOME to said path but doesn't actually install java there or create a symlink to the installation directory, which happens to be "/usr/lib/jvm/jdk8u232-b09" in that case.
:pancakes: Cookbook version
java 8.3.0
:woman_cook: Chef-Infra Version
chef 16.3.38
:tophat: Platform details
CentOS 7
Steps To Reproduce
Steps to reproduce the behavior:
Alternatively:
:police_car: Expected behavior
My expectation would be that java is either installed to java_home or that a symlink is created to the install directory.