need to fiddle with it. The default case statement, "do nothing"
is all fine here.
Facter::Util::Resolution.with_env is long time gone since
Facter > 2.x. That was even longer before introduced by me.
Remove that OpenBSD special case in the java_version fact,
and assume that $PATH is properly set in order to find
the 'java' binary.
Additionally confine the java_default_home and java_libjvm_path
to OpenBSD kernel as well. Add some flesh to the java_default_home
fact to allow it to find the java binary.
Previous value of 8M caused JVM to crash on servers with more then 40G of RAM
Tested on databases servers up to 1.5T of RAM, 12M seems to be sufficient
* dirname containing base directory of java
* e.g. java binary is `${::java_default_home}/jre/bin/java`
* dirname containing `libjvm.so`
* Most people will use this for LD_LIBRARY_PATH
The other method for running which java doesn't work on OSX, as java is installed as an empty shim when not installed in the base OSX image:
```
vagrant:~ vagrant$ java
No Java runtime present, requesting install.
vagrant:~ vagrant$ /usr/libexec/java_home --failfast
Unable to find any JVMs matching version "(null)".
vagrant:~ vagrant$
```
We can use the `/usr/libexec/java_home --failfast` command to check if
java is actually present first.
Originally-by: Peter Souter <peter.souter@puppetlabs.com>
Add info about OpenBSD support to README.md and metadata.json
Add a note about OpenBSD java_version fact to README.markdown.
Fixup wording on context in one of the java patch level regression tests.
No mentioning of OpenBSD in metdata.json
Cleanup wording of context as suggested by @elyscape
update contexts as suggested by @elyscape
Uses the `java_version` fact and gets the patch level by splitting after `_`
This would be useful if you want to make sure you're not accidentally downgrading the version of Java to a lower patch level (I've noticed some package managers don't notice this too well)
Adapted from the many found on Github, simply runs `java -version` and strips the results. From what I can find there aren't many edge cases for the result `java -version 2>&1` could return, so this should be fairly compatible.
