[chef] Re: Re: rewriting my tomcat LWRP, how best to group options?


Chronological Thread 
  • From: Bryan Berry < >
  • To:
  • Subject: [chef] Re: Re: rewriting my tomcat LWRP, how best to group options?
  • Date: Sun, 15 Apr 2012 16:21:48 +0200

Hey Edward,

thanks for the encouragement ;)

it wouldn't be terribly difficult to add support for multiple
datasources. At first I will only support one and I will try to get to
additional ones when i get the chance. i could add support for passing
an array to context_template

to have multiple i think it would be better to have something like
this than passing an array of hashes to  datasource

datasource "foo" do
 ...
end
# creates tomcat_home/conf/Catalina/localhost/foo.xml

datasource "bar" do
 ...
end
# creates tomcat_home/conf/Catalina/localhost/bar.xml


you could however easily add an additional datasource by templating an
additional context file in tomcat_home/conf/Catalina/localhost/


for  -XXgofaster  that would belong under the xx_opts

Of the two apis which I have presented, which do you prefer?

in regards to supporting additional functionality like jms, e-mail etc.

I think that would be best served by something like this

context_template :mix_of_stuff => "your_jms_template.erb"

and that could create tomcat_home/conf/Catalina/localhost/mix_of_stuff.xml

I haven't yet dealt w/ e-mail and jms settings so will have to think
about how best to handle those w/ an lwrp

thanks for your feedback!

On Sun, Apr 15, 2012 at 4:08 PM, Edward Sargisson 
< >
 wrote:
> Hi Bryan,
> I'm looking forward to seeing what the new cookbook looks like because I
> greatly rely on your good work!
>
> Firstly, would you be able to make the datasource take an array so that we
> can have multiples? In my setup, I use Liquibase to automatically upgrade
> the database. I use a special, slightly more privileged but not super, user
> to actually do that upgrade and thus have two datasources.
>
> As for jvm options, I would suggest surfacing most options with little
> translation (option 2 below). There are the very basic knobs to turn (which
> you've nicely surfaced) like heap size, GC, etc. However, if I want to twist
> another knob then I'm going to want to know exactly what I'm doing. i.e.
> maybe a page in the docs for Tomcat says use -XXgofaster so I'm going to
> want to know I've added -XXgofaster without having to read the cookbook.
> Having done similar things in JBoss and Websphere AS I definitely prefer to
> know what's going on.
>
> Lastly, what about context settings for JMS, email, etc. While I doubt you
> need to write them in right now it would be nice to have a spot in your
> model where they'd fit so that somebody can add it later.
>
> Cheers,
> Edward
>
>
>
> On Sun, Apr 15, 2012 at 6:46 AM, Bryan Berry 
> < >
>  wrote:
>>
>> I am rewriting my tomcat lwrp and here is what I have in mind, partly
>> inspired by Andrea Campi's work
>https://github.com/andreacampi/application_java
>>
>> tomcat "liferay" do
>>   gc do
>>     min           "256m"
>>     max           "512m"
>>     max_perm_size "256m"
>>     algorithm     "UseConcMarkSweepGC"
>>   end
>>   profiling do               # JMX
>>     port            "98204"
>>     ssl             false
>>     authentication  false
>>   end
>>  datasource do
>>    driver 'org.gjt.mm.mysql.Driver'
>>    database 'name'
>>     port 5678
>>     username 'user'
>>     password 'password'
>>     max_active 1
>>     max_idle 2
>>     max_wait 3
>>   end
>>   ports dof
>>     http      8080
>>     https     8443  # defaults to nil and not used
>>     ajp       8009
>>     shutdown  8005
>>   end
>>
>> end
>>
>> Commandline JVM options that don't fit into the above api would have
>> to be crammed into an attribute like "additional_opts" or
>> node['tomcat']['additional_opts']
>>
>> the issue I have is whether to group the options to be used by java
>> virtual machine by function or by category.
>>
>> Here is a different take on the  tomcat lwrp, the uses a 'jvm' block
>> with the xx_opts and d_opts which correspond to -XX, and -D options.
>> thoughts?
>>
>> tomcat "pentaho" do
>>      path     "/opt/pentaho"
>>      version         "7"
>>      user            "pentaho"
>>      unpack_wars     true
>>      auto_deploy     true
>>      environment     { }
>>      jvm do
>>        xms           "256m"
>>        xmx           "512m"
>>        max_perm_size "256m"
>>        xx_opts       { }
>>        d_opts        { }
>>        additional_opts [    ]
>>      end
>>      datasource do
>>        driver 'org.gjt.mm.mysql.Driver'
>>        database 'name'
>>        port 5678
>>        username 'user'
>>        password 'password'
>>        max_active 1
>>        max_idle 2
>>        max_wait 3
>>      end
>>      ports do
>>        http      8080
>>        https     8443  # defaults to nil and not used
>>        ajp       8009
>>        shutdown  8005
>>      end
>>    end
>>
>> the JVM has so many bloody options that this may be the  more feasible
>> solution. also w/ the xx_opts, and d_opts I can use simpler options
>> hash like
>>
>> node['tomcat']['xx_opts'] = { 'ParallelGCThreads':'',
>> '+UseConcMarkSweepGC':'', 'CompileThreshold' : '10000' }
>> node['tomcat']['d_opts'] = { 'user.timezone': 'UTC',  'file.encoding':
>> 'UTF8'}
>>
>> would convert to -XX:ParallelGCThreads -XX:+UseConcMarkSweepGC
>> -XX:CompileThreshold=10000 -Duser.timezone=UTC -Dfile.encoding=UTF8
>
>



Archive powered by MHonArc 2.6.16.

§