cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [Proposal] Simple "production build" directions
Date Thu, 28 Aug 2003 16:46:37 GMT
Switching back to users, as the feedback we need is really for them. 
Any developers (besides me) interested please follow over there, and 
whoever responds to this, please remove dev from the to: field.

Timothy Larson wrote:
> --- Geoff Howard <> wrote:
>>It will be easy to add a new build target "production-seed" (or 
>>something to that effect) which would set those values and perform other 
>>steps as needed.  This would change the instructions to 1) edit blocks 
>>properties 2) ./ production-seed.  Would that be better in your 
>>mind, or is a sample properties better?  I can see positives with both 
> I lean toward a example properties file, because that introduces the
> customization system that Cocoon uses.  I updated to proposed text to
> refer to the "" as an example file:
>   To make a production build without the documentation, samples, scratchpad,
>   or deprecated code simply copy the example ""
>   file to "" before going on to step 3.
>   See below if you are rebuilding or wish to further customize the build.

Ok, point well taken and I agree this will work the best.  This is not 
really what was asked for orginally though -- will this be perceived as 
any better than the current state?  The benefit is that the less-often 
modified properties will be removed from this file to reduce the shock 
of wading through so much that doesn't need to be understood.  Still, 
I'll experiment with a build target that would load these defaults 
without the file-rename step which may scratch the other itch.

>>The key is not how to accomplish it (because the pieces are already in 
>>place in the build to do either), but _what_ to accomplish.
> The example "production build" does not have to be perfect for everybody,
> just reasonable and relatively secure.  We already have the customization
> instructions for making it perfect.
>>Also, are there other config issues can be agreed on for this 
>>target/recommended setting?  Logging level?  Allow/Deny uploads?
> The default log level is already INFO, which is a reasonable default.
> A default setting of Deny uploads is the most secure.

I agree on the uploads, but INFO will really be too verbose for 
production for most people, don't you think?  It will contain every 
component lookup, every step of every access, etc.  Perhaps as 
developers we've too much treated INFO as FINE, but that's too late to 
change.  I'd strongly suggest WARN or ERROR.

> Perhaps we should add these two settings to the example production
> build properties file, since they are among the most likely to be
> customized:
>   # ---- Configuration ----
>   #config.enable-uploads=true
>   # ---- Webapp Build Properties ----
>   build.webapp.loglevel=INFO

Yes, that's the way to do it.  The values can change as we come to 
consensus of course.


View raw message