On 6 May 2016 at 13:42, Philippe Mouawad <[email protected]> wrote: > 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.
That's not true. They could be in any file. > 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.
