jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: regex for jmeter.reportgenerator.exporter.html.series_filter
Date Fri, 06 May 2016 13:13:56 GMT
On 6 May 2016 at 13:42, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> On Fri, May 6, 2016 at 11:21 AM, sebb <sebbaz@gmail.com> wrote:
>
>> On 6 May 2016 at 09:44, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>> > On Friday, May 6, 2016, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 5 May 2016 at 19:52, Philippe Mouawad <philippe.mouawad@gmail.com
>> >> <javascript:;>> wrote:
>> >> > On Thu, May 5, 2016 at 8:29 PM, Felix Schumacher <
>> >> > felix.schumacher@internetallee.de <javascript:;>> wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> Am 5. Mai 2016 20:17:37 MESZ, schrieb Philippe Mouawad <
>> >> >> philippe.mouawad@gmail.com <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 <
>> >> >> >felix.schumacher@internetallee.de <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.

Mime
View raw message