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

[Andrea Campi < >]

Hi Bryan and all,

On Sun, Apr 15, 2012 at 3:46 PM, 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

first of all, thanks for the pointer but it was Noah who came up with
the DSL; I'm "just" finish up what he started and shepherding it into
the repo.


I haven't had time to work on Java apps since we talked, but I do have
some opinions.


First of all, I like what you're doing but I think it doesn't belong
in the Tomcat cookbook.
Looking at your examples, I would say every option except perhaps the
ports would make sense for a standalone non-web-app.
And what about running on JBoss or Jetty? What about JRuby or Scala apps?

The goal of the application cookbook is to abstract away commonalities
and provide a single language to as many frameworks as reasonable,
while still allowing specific configuration.

Without getting too specific, my main point here is: let's join effort
and make sure we don't invent almost the same thing twice.



Concerning multiple database connections:
that's something I thought about for Rails and other frameworks. I
looked back at enhancement requests tickets and while there have been
requests to support apps with *no* SQL database, I couldn't find any
requesting more than one.
In the end I decided not to add any special logic, and put in an
option to specify a custom template (akin to your context_template).

When I doubt I go with the 80/20 rule: 80% or more people will be
covered by the logic for one DB connection; 80% of the remaining will
be able to get by with a custom template; the remaining setups will
probably have very specific needs anyway, and may as well implement
their custom logic by editing the cookbook.




To answer your questions:

> tomcat "pentaho" do
...
>      jvm do
>        xms           "256m"
>        xmx           "512m"
>        max_perm_size "256m"
>        xx_opts       { }
>        d_opts        { }
>        additional_opts [    ]
>      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

I'd rather go this way for a simple reason: many of these settings are
not really per-app, they are more per-site or per-node.
A nice DSL is very convenient, but for stuff like file.encoding I just
want to set it on a role and be done with it.


Ditto for your last example:

> jvm do
>  xx_opts do
>     use_conc_mark_sweep_gc    true      # becomes   -XX:+UseConcMarkSweepGC 
>  on command line
>       allow_user_signal_handlers  false    #  becomes  
> -XX:-AllowUserSignalHandlers
>       max_heap_free_ratio                70        # becomes  
> -XX:MaxHeapFreeRatio=70
>   end
> end

I want to be able to grep for UseConcMarkSweepGC anywhere; remembering
that I have to spell that as use_conc_mark_sweep_gc just here is extra
mental burden I frankly don't need :)


Hope this helps. I'll find you online tonight and we can talk more?

Andrea