On 6 May 2016 at 14:10, Philippe Mouawad <[email protected]> wrote: > On Fri, May 6, 2016 at 2:44 PM, sebb <[email protected]> wrote: > >> On 6 May 2016 at 13:31, Philippe Mouawad <[email protected]> >> wrote: >> > On Friday, May 6, 2016, sebb <[email protected]> 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? >> >> > 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. > 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. But I suppose they can use the -q option to isolate the properties in a separate file. >> >> > >> >> >> >> And I thought we were trying to reduce the number of properties, not >> >> add to them. >> >> >> > > > > -- > Cordialement. > Philippe Mouawad.
