I agree with this. We are going to formalize this in what is
called as "Profile Support". Obviously, this will be subjective
because now you let the software (aka GlassFish software) decide
what defaults should be. It could be more or less coarse/fine
grained per the requirements from the user. To reduce the
complexity for example, we could just say that there is a profile
called "developer" that lets software decide what goes in a config file
like "domain.xml".
For instance, when user wants to use GlassFish as a "developer",
s/he would *at the time of installation* choose the developer
profile, upon doing which, the defaults (again, those that
software feels are appropriate) will be chosen.
For instance, in the "developer" profile, we will by default disable
the http access logging for all the good reasons that various people
have articulated.
Is this a good thing? Will that satisfy some/most of users' needs?
We are in the process of making this proposal for GlassFish V2.
(Sorry, still in the works). I think there will be some announcement
to solicit feedback for all the new features we do for V2.
Kedar
Ryan Galgon wrote:
> What about providing two default config files, one for performance and
> one for development that has what people 'think' should be the best
> setting for both. Sort of like how on a fresh install of Apache on most
> systems there's quite a few started conf files named appropriately or
> mysql with the small, medium, huge.cnf files. I'm thinking that may
> provide a decent middle ground at the cost of complicating things
> somewhat. I know as a novice with all of this stuff I'd have/would find
> that useful as a way to check settings in terms of best for production
> and best for development.
>
> On 8/9/06, *Jan Luehe* <Jan.Luehe_at_sun.com <mailto:Jan.Luehe_at_sun.com>> wrote:
>
>
>
> vince kraemer wrote On 08/09/06 19:28,:
>
> > Craig McClanahan wrote:
> >
> >> Jan Luehe wrote:
> >>
> >>> [snip]
> >>> I think regardless of whether access logging is on or off by
> >>> default, once it is
> >>> on (either by default or by configuration), developers expect
> >>> immediate updates.
> >>>
> >>> I think we need to do a survey of how useful access logging is
> >>> during development,
> >>> and how much of a performance penalty people are willing to pay
> for it.
> >>>
> >>> Tomcat disables it by default, and nobody has ever complained
> about it.
> >>>
> >> There's a reason for that. The important log file during
> development
> >> is the system log, not the access log ... so you can see exception
> >> messages and the like. That's also why tools like NetBeans and
> >> Creator give you direct access to the system log, but not to the
> >> access log.
> >>
> >> I'd vote for access log disabled by default. But also, given the
> >> theory that the only time you'd want the access log enabled is a
> >> production environment where performance is important, I'd also vote
> >> for configuring the default enabled behavior to maximize
> performance.
> >
> >
> > That is a consistent opinion. I like that.
>
>
> I'm fine with turning access logging off by default in PE.
>
> What about EE? Do we want it on by default? If yes, I agree that the
> out-of-the-box settings should be such that perf is maximzed. If the
> answer is no, then we could ask admins to pick appropriate settings
> (to maximize perf) as they enable access logging.
>
> Jan
>
> >
> >
> > vbk
> >
> >>
> >> Craig McClanahan
> >>
> >>>
> >>> Jan
> >>>
> >>>>>
> >>>>> Jan
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> vbk
> >>>>>
> >>>>>
> >>>>
> >>>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> >>>> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
> <mailto:users-help_at_glassfish.dev.java.net>
> >>>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> >>> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
> <mailto:users-help_at_glassfish.dev.java.net>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> >> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
> <mailto:users-help_at_glassfish.dev.java.net>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> > For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
> <mailto:users-help_at_glassfish.dev.java.net>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> <mailto:users-unsubscribe_at_glassfish.dev.java.net>
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> <mailto:users-help_at_glassfish.dev.java.net>
>
>
>
>
> --
> --rgalgon_at_gmail.com--