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:10:33 GMT
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.

>
> > 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.
The problem is similar to HTTPResponse.parsers and the way htmlParser are
configured.



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

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



-- 
Cordialement.
Philippe Mouawad.

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