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

[Edward Sargisson < >]

Hi Bryan,

I fear I'm a little confused. In Tomcat6, my understanding is that you have to have a single context for each web app. Thus, the two (or more) data sources have to be included in the same file so your comments about foo.xml don't make sense to me. What have I missed?

I prefer the xx_opts method. It's much clearer what's happening.

Agree that allowing a context template for complex configs is a nice solution.

Cheers,

Edward

On Sun, Apr 15, 2012 at 7:21 AM, Bryan Berry < "> > wrote:

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
>
>