jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: ReportGenerator properties
Date Fri, 06 May 2016 13:30:34 GMT
On Fri, May 6, 2016 at 3:25 PM, sebb <sebbaz@gmail.com> wrote:

> On 6 May 2016 at 14:10, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > On Fri, May 6, 2016 at 2:44 PM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 6 May 2016 at 13:31, Philippe Mouawad <philippe.mouawad@gmail.com>
> >> wrote:
> >> > On Friday, May 6, 2016, sebb <sebbaz@gmail.com> wrote:
> >> >
> >> >> I should have noticed this before, but I did not, so sorry for
> >> >> bringing it up now.
> >> >>
> >> >> ==
> >> >>
> >> >> jmeter.properties contains 40 enabled properties for ReportGenerator
> >> >> plus some additional ones that are commented out.
> >> >>
> >> >> This means that over half the total number of entries in the file are
> >> >> for ReportGenerator.
> >> >>
> >> > There are much more entries in file than 80.
> >>
> >> $ grep -v "^#" jmeter.properties | grep -v "^\s*$" | wc -l
> >>
> >> 73
> >>
> >> >
> >> >> That does not seem right.
> >> >>
> >> >
> >> >
> >> >
> >> >>
> >> >> user.properties contains 8 commented references to ReportGenerator.
> >> >>
> >> >> As far as I can tell, about half of the properties are report titles,
> >> >>
> >> >
> >> > If you're talking about user.properties, only 1 relates to a Title
> and is
> >> > specific to each Load Test (not even script).
> >>
> >> No, I'm primarily referring to jmeter.properties.
> >>
> > ok
> >
> >>
> >> > If you're talking about the .title ones, then yes they could be in
> >> > messages.properties, but read below for the reason they are not.
> >> >
> >> >
> >> >> so belong in messages.properties anyway.
> >> >
> >> >
> >> >
> >> >
> >> >>
> >> >> Most of the remaining ones look like values that belong elsewhere.
> >> >>
> >> >> jmeter.properties is supposed to be for rarely changed configuration
> >> >> items, debug etc.
> >> >
> >> > The majority of properties are here for IOC of components.
> >> > When report was created, we aimed at making it extensible.
> >> > Dependencies are injected and reports are declared through properties
> and
> >> > properties are injected.
> >> > That's why title is not in messages.properties.
> >>
> >> What are non-English speaker supposed to do?
> >
> >
> > Ok , let's create an enhancement to I18N
> >
> >>
> >> If they change jmeter.properties they will have to do so for every
> release.
> >>
> >
> > They can change this in user.properties.
> > No need to touch jmeter.properties
>
> >>
> >> jmeter.properties is supposed to be largely immutable.
> >>
> > No need to touch it.
>
> In which case why are the entries not defaulted in the code?
>

Read the code, test and you'll see.

>
> >>
> >> > We didn't want to introduce an additional configuration file for IOC,
> >> > ideally we would have liked to use something like Spring IOC but
> didn't
> >> > want to introduce it to avoid too many additional dependencies.
> >> >
> >> > For the properties you mention, they are in fact not aimed to be
> changed
> >> by
> >> > regular users.
> >>
> >> So why are they defined in jmeter.properties?
> >> They should be defaulted.
> >>
> >
> > No ,because we didn't want to hardcode the reports.
>
> A default is not the same as hardcoding.
> I meant that the code should use a sensible default if the property is
> not defined.
>

Read the code, test and you'll see.

>
> > The problem is similar to HTTPResponse.parsers and the way htmlParser are
> > configured.
>
> Except that those properties very rarely need to be changed.
>
> >
> >
> >>
> >> > Except for the 8 that are in user.properties, you will generally
> change:
> >> > - Apdex values
> >> > - report_title
> >> > - granularity
> >> > - series_filter
> >>
> >> Will these need to be changed for each test?
> >>
> >
> > For each campaign of test at least on same application , or if target
> > values for 1 campaign changes.
>
> So user.properties needs to be changed for each of these cases?
> That quickly gets rather tedious, especially if there are other
> overrides that need to be configured.
>

Frankly it's not , I have been using it on 3 campaigns recently and it's
not tedious.
I have a user.properties per campaign.

>
> But I suppose they can use the -q option to isolate the properties in
> a separate file.
>

I don't know , try and see.

>
>
> >>
> >> >
> >> >>
> >> >> And I thought we were trying to reduce the number of properties, not
> >> >> add to them.
> >> >>
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message