On Fri, May 6, 2016 at 3:25 PM, sebb <[email protected]> wrote: > 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? >
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.
