On Fri, May 6, 2016 at 3:13 PM, sebb <[email protected]> wrote: > 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. > Currently no. Of course it could be.
> > > 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. > -- Cordialement. Philippe Mouawad.
