On Fri, May 6, 2016 at 11:21 AM, sebb <[email protected]> wrote: > On 6 May 2016 at 09:44, Philippe Mouawad <[email protected]> > wrote: > > On Friday, May 6, 2016, sebb <[email protected]> wrote: > > > >> On 5 May 2016 at 19:52, Philippe Mouawad <[email protected] > >> <javascript:;>> wrote: > >> > On Thu, May 5, 2016 at 8:29 PM, Felix Schumacher < > >> > [email protected] <javascript:;>> wrote: > >> > > >> >> > >> >> > >> >> Am 5. Mai 2016 20:17:37 MESZ, schrieb Philippe Mouawad < > >> >> [email protected] <javascript:;>>: > >> >> >Hi Felix, > >> >> > > >> >> >1. true > >> >> >2. I don't understand the problem , can you clarify for me ? > >> >> > >> >> ^ indicates start of line (String in our case). But the code does a > >> match, > >> >> so that is implicit. But if I see a ^ I think the regex will do a > "find" > >> >> instead of a "match". > >> >> > >> >> So as a result I think we should remove the ^. > >> >> > >> >> > > >> >> >3. Yes we want to trap: > >> >> >- Sample1 > >> >> >- Sample1-success > >> >> >- Sample1-failure > >> >> >- Sample2 > >> >> >- Sample2-success > >> >> >- Sample2-failure > >> >> > > >> >> >Ideally not Sample2XXX-success. > >> >> > >> >> And not Sample123? > >> >> > >> > No > >> > > >> >> > >> >> >Do you see a better regex ? > >> >> > >> >> If we want to match all those, than the regex is correct. > >> >> > >> >> All in all, I think it would be safe to change the regex to > >> >> > >> >> Sample[12](?:-failure|-success)? > >> >> > >> > > >> > Yes but in real life they will not be named Sample1, Sample2 , but > >> > Purchase, Search for example > >> > >> In which case we seem to be asking the customer to provide their own > regex. > > > > yes > > > >> > >> This is prone to error, and won't they have to change it for each test? > > > > > > I don't understand. > > I mean that creating regexes can be hard. > > > Samples naming is up to users, it's already like this in BackendListener, > > same for regexp extractor. > > > > Here we just provide an example of a regexp with 2 samples. > > In which case use names which are more representative, rather than > ones which happen to be easy to write regexes for. > > > > >> > >> I think this may cause a lot of questions on the user list. > >> > >> If it is just a question of matching some words optionally followed by > >> '-success' or '-failure', then I think the user should just have to > >> supply the words. > >> Possibly even as lines in a separate file. > >> The code then creates its own regex or does its own matching. > > > > > > Regexp is more flexible and there are a lot of helper on the net. > > But we still get quite a few questions on them. > > > To be coherent with BackendListener we should stick with regexp. > > If you are referring to the "samplersList" variable in BackendListener > then using it as a regex is *optional* > > Also the field is one the GUI, so each test can have its own config > (or even multiple ones in a single test) > > > A list of samples in another file is again another configuration to > manage > > instead of having everything in user.properties. > > But if the regex need to be changed for each test then having it in > ^[jmeter|user]\.properties$ is not very convenient. >
We can in next version create a Test Element called ReportConfiguration that will hold the values that are in ^[jmeter|user]\.properties$ for now. > > I've also just noticed that the property appears in both > jmeter.properties and user.properties. > Having them in jmeter.properties is required for IOC. In user.properties, we just put them to make it clear for users which ones are to be configured. It's the same strategy as for search_paths, user.classpath... As we advise to do all changes in user.properties. Also the regexp example is here to show an example for users. Maybe this can be even more documented if you think it's not clear enough. > That's more potential confusion. > > I think the whole way that ReportGenerator uses properties needs to be > looked at; I'll raise a separate thread. > I answered in the other thread. > > > Let's see what happens with 3.0 and we can enhance in the future. > > If you look at it we already had feedback on reports, and it was not one > of > > them. > > > > > >> > >> >> > >> >> Or, if it should be a bit more descriptive > >> >> > >> >> (?:Sample1|Sample2)(?:-failure|-success)? > >> >> > >> >> Which is mostly the same as the one in the properties file. > Differences > >> >> are non capture and remove indicator of start of line. > >> >> > >> > ok, can you just double check it ? > >> > > >> >> > >> >> Felix > >> >> > >> >> >Thanks > >> >> > > >> >> > > >> >> > > >> >> >On Thu, May 5, 2016 at 7:23 PM, Felix Schumacher < > >> >> >[email protected] <javascript:;>> wrote: > >> >> > > >> >> >> Hi all, > >> >> >> > >> >> >> the regex for series_filter is currently set to > >> >> >> > >> >> >> ((^Sample1)|(^Sample2))(-success|-failure)? > >> >> >> > >> >> >> in the user.properties file. > >> >> >> > >> >> >> The regex could be written a bit shorter as > >> >> >> > >> >> >> ^Sample[12](-success|-failure)? > >> >> >> > >> >> >> But there are still a few things to consider. > >> >> >> > >> >> >> 1. I don't think that we are interested in the captured groups and > >> >> >> could tell the regex engine that by using (?:...) instead of > (...). > >> >> >> > >> >> >> 2. The ^ in front of Sample1 makes it look like the regex would be > >> >> >used > >> >> >> as "find", as there is no $ to indicate the end of a line. > >> >> >> > >> >> >> 3. The ? after the last group indicates that the results could be > one > >> >> >> of > >> >> >> + Sample1 > >> >> >> + Sample1-success > >> >> >> + Sample1-failure > >> >> >> + Sample2... > >> >> >> Is this true? Or is just ...-success and ...-failure? In that > case > >> >> >> the ? at the end of the regex should be removed. > >> >> >> > >> >> >> Regards, > >> >> >> Felix > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > > >> > > >> > -- > >> > Cordialement. > >> > Philippe Mouawad. > >> > > > > > > -- > > Cordialement. > > Philippe Mouawad. > -- Cordialement. Philippe Mouawad.
