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
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
You may want to take a look at the "tomcat" cookbook vs "tomcat6". It's
install process is less complicated as it relies on the underlying OS
package system to do the install vs installing from source. It also as
an explicit "depends" on the java cookbook which ensures a JVM is installed.
I somewhat fixed the attribute issue with OHAI-227 [0], but I actually think
we need a simple attribute like ["languages"]["java"]["flavor"] which just
contains something like sun, openjdk, harmony etc. Until this is officially
fixed in the Ohai gem, you can write your own Ohai plugin (that creates the
proper java/runtime java/hotstop attributes) and distribute it to your nodes
using the Ohai cookbook [1][2].
Seth
--
Opscode, Inc.
Seth Chisamore, Technical Evangelist
T: (404) 348-0505 E: schisamo@opscode.com
Twitter, IRC, Github: schisamo
http://tickets.opscode.com/browse/OHAI-227
http://cookbooks.opscode.com/cookbooks/ohai
https://github.com/opscode/cookbooks/blob/master/ohai/README.md
On Fri, Jan 28, 2011 at 7:45 AM, Avishai Ish-Shalom avishai@fewbytes.comwrote:
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