I've encountered this and other java identification bugs before. I
worked around them by writing my own function for java flavor
identification, but i'm not a java man and I doubt my function will work
with the multitude of java versions out there.
This is a bug in Ohai and should be fixed. I'll check if there are any
open tickets, but we need someone who can test against as many JVMs as
possible.
Regards,
Avishai
On 01/28/2011 12:12 PM, Andreas Kollegger wrote:
> Hi all,
>
> I've just started writing a chef cookbook for provisioning Neo4j. It's naive but functional at the moment. In studying and trying out other cookbooks, I had a problem with the tomcat6.
>
> This chunk of code...
>
> if languages[:java]
> set_unless[:tomcat6][:with_snmp] = !languages[:java][:runtime][:name].match(/^OpenJDK/)
> else
> set_unless[:tomcat6][:with_snmp] = false
> end
>
> Caused a problem because languages[:java][:runtime] does not exist. Browsing with `shef` I discovered this...
>
> chef:attributes > languages[:java][:hotspot][:name]
> => "OpenJDK Client VM"
>
> So, I modified the check for OpenJDK to look like this...
>
> if languages[:java][:runtime]
> set_unless[:tomcat6][:with_snmp] = !languages[:java][:runtime][:name].match(/^OpenJDK/)
> elsif languages[:java][:hotspot]
> set_unless[:tomcat6][:with_snmp] = !languages[:java][:hotspot][:name].match(/^OpenJDK/)
> else
> set_unless[:tomcat6][:with_snmp] = false
> end
>
> Which works but seems a bit hack-ish. Is there a predictable structure to the languages[:java] attribute? What creates it?
>
> Cheers,
> Andreas
>
Archive powered by MHonArc 2.6.16.