You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2017/10/05 12:04:47 UTC

[Bug 61585] New: Regular Expression Extractor does not populate variables if not preceeded by a Sampler

https://bz.apache.org/bugzilla/show_bug.cgi?id=61585

            Bug ID: 61585
           Summary: Regular Expression Extractor does not populate
                    variables if not preceeded by a Sampler
           Product: JMeter
           Version: 3.3
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: cristianosadun@hotmail.com
  Target Milestone: ---

Created attachment 35395
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35395&action=edit
JMeter project snippet

This is not a big deal, but it's a bit misleading so perhaps worth reporting.

Ref. attached image. The example here is with HTTP Sampler but I guess the
behavior is generic.

I have a user-defined variable containing a URL and, within a simple
controller, I extract some parts of its value into other variables ("server",
"port" etc and then use them to configure an HTTP Sampler. The regular
expressions are correct and to their job (see below).

The HTTP sampler fails because the variables defined by the RegExp Extractors
aren't replaced with the extracted values, and that is because they are
actually not placed in JMeterVariables at all in the first place (using a
DebugSampler right after the extractions, I can see that the variables aren't
there).

Since JMeter can't find a value for them, they stay as literals in the
configuration - which obviously causes the sampler to fail.

However, if I duplicate the HTTP sampler, the duplicated sampler works fine. 

It seems that RegExp Extractor needs at least a sampler (any sampler, anywhere
in the sequence) in order to actually place the variable it defines in
JMeterVariables - and they will be visible only after the first sampler is
executed.

Since the RegExp Extractor is post processor, it makes sort of sense, but it
should pehaps fail in a bit more explicit manner? Or shouldn't fail at all? 

After all, by placing even a Debug Sampler before the Extractors, it works as
expect so it doesn't seem an explicit design decision, but more of a side
effect. 

No big deal as I said, but maybe something simple to fix to make life easier
for test script developers. :)

Cheers,

 -cris

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 61585] Regular Expression Extractor does not populate variables if not preceeded by a Sampler

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61585

Cristiano Sadun <cr...@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
                 OS|                            |All

--- Comment #1 from Cristiano Sadun <cr...@hotmail.com> ---
Marked as "minor"

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 61585] Regular Expression Extractor does not populate variables if not preceeded by a Sampler

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61585

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |p.mouawad@ubik-ingenierie.c
                   |                            |om
         Resolution|---                         |WORKSFORME

--- Comment #2 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
(In reply to Cristiano Sadun from comment #0)
> Created attachment 35395 [details]
> JMeter project snippet
> 
> This is not a big deal, but it's a bit misleading so perhaps worth reporting.
> 
> Ref. attached image. The example here is with HTTP Sampler but I guess the
> behavior is generic.
> 
> I have a user-defined variable containing a URL and, within a simple
> controller, I extract some parts of its value into other variables
> ("server", "port" etc and then use them to configure an HTTP Sampler. The
> regular expressions are correct and to their job (see below).
> 
> The HTTP sampler fails because the variables defined by the RegExp
> Extractors aren't replaced with the extracted values, and that is because
> they are actually not placed in JMeterVariables at all in the first place
> (using a DebugSampler right after the extractions, I can see that the
> variables aren't there).
> 
> Since JMeter can't find a value for them, they stay as literals in the
> configuration - which obviously causes the sampler to fail.
> 
> However, if I duplicate the HTTP sampler, the duplicated sampler works fine. 
> 
> It seems that RegExp Extractor needs at least a sampler (any sampler,
> anywhere in the sequence) in order to actually place the variable it defines
> in JMeterVariables - and they will be visible only after the first sampler
> is executed.
Yes
> 
> Since the RegExp Extractor is post processor, it makes sort of sense, but it
> should pehaps fail in a bit more explicit manner? Or shouldn't fail at all? 

If it doesn't extract anything, why should it fail ? I has not even run in fact
as there was no sampler.
> 
> After all, by placing even a Debug Sampler before the Extractors, 

Extractors are scoped elements, as such their position(before/after) does not
influence their action.
See:
http://jmeter.apache.org/usermanual/test_plan.html#scoping_rules
http://jmeter.apache.org/usermanual/component_reference.html#postprocessors

it works
> as expect so it doesn't seem an explicit design decision, but more of a side
> effect. 
A Debug Sampler IS A Sampler as such it is not a side effect.
> 
> No big deal as I said, but maybe something simple to fix to make life easier
> for test script developers. :)
> 
> Cheers,
> 
>  -cris

Thanks for report, but this is clearly a design decision, see my notes above.

If I misunderstood your issue, please reopen with more details on what you
expect with a particular plan and what you get.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.