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

[Bryan Berry < >]

Hey Andrea

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

It may best belong in the java cookbook at java/libraries/java_webapp.rb . It definitely applies in some aspect to jboss, jetty, jruby, scala, etc.

I am very happy to join forces at the same time I do have to write something that 100% solves my problems at work otherwise I will go insane over the next couple months ;).

> 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

would this work for you?

xx_opts  'UseParallelGC' => true, 'UseConcMarkSweepGC' => true, 'CompileThreshold' => 10000

Which would convert to  -XX:+UseParallelGC -XX:+UseConcMarkSweepGC -XX:CompileThreshold=10000

so the boolean values convert to '+' prefixes otherwise the value will be '=' something

while the jvm and ports helpers map easily to tomcat, jetty, jboss, etc, the datasources may not

also, I suggest we call the attribute 'datasource' and not 'database' as that is more common in the java docs. However you may use the database name elsewhere in the application cookbook

cheers

On Mon, Apr 16, 2012 at 8:35 AM, Andrea Campi < "> > wrote:

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