You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Vladimir Sitnikov <si...@gmail.com> on 2021/11/20 09:20:14 UTC
Re: JMeter DSL discussion
>I think it's important to slowly isolate the Jmeter core from GUI,
If anybody wants to contribute that, please do so.
Antonio>I think it's a good idea to add DSL in core is a good idea
The immediate question is do we put classes for DSL right into the
current ApacheJMeter_core, ApacheJMeter_http, ApacheJMeter_jdbc,
or do we create a new set of modules like ApacheJMeter_core_dsl,
ApacheJMeter_http_dsl, and so on?
It might be that in the future ApacheJMeter_http would become
ApacheJMeter_http, ApacheJMeter_http_gui, ApacheJMeter_http_dsl.
That would triple the number of folders in src/protocols.
If there are no objections, I would try adding DSL via extra modules.
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vladimir> I've idea what would work the best to resolve it.
Fix: I've *no* idea what would work.... :)
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
> How do you see the DSL for plugins ?
The baseline is they would be able to integrate if they want. They would
have to code their DSL in Kotlin though.
>How will JSR223 custom code be used inside DSL ?
Suggestions are welcome. Kotlin has raw literals (~multiline strings), so
coding JSR223 as a string would be not that bad, especially taking into
account IDEA has language injection (it can autocomplete Groovy,
JavaScript, etc within the string)
Yet another alternative would be converting Kotlin lambdas to JSR223 or
something like that.
>is your suggestion about changing JMeter ${var} syntax or do I
misunderstand ?
I do not suggest changing JMeter syntax.
Vladimir
Re: JMeter DSL discussion
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello,
Few questions regarding the feature :
- How do you see the DSL for plugins ?
- How will JSR223 custom code be used inside DSL ?
Also few notes inline below
Regards
On Saturday, November 20, 2021, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >The annotations could be used for scanning for TestPlan elements on
> startup, too.
>
> I remember we have discussed it, however, it sounds like a different
> feature.
> Of course, some level of code generation might help, however, I have no use
> cases for it now.
>
> >Maybe start with a global org.apache.jmeter.experimental.dsl
> package/module name
>
> I think experimental works better with annotations like
> @OptIn(Experimental)
> If you put experimental into a package name, you can't remove it without
> breaking the usages.
Looks good to me
>
> A single .dsl. package would help indeed, so users could import
> jmeter.dsl.* and use the functions rather than import every package or
> class individually.
> On the other hand, the users won't be able to unimport features they do not
> need
That looks acceptable to me
>
> > Kotlin has a very similar string template format to JMeter, is there a
> good way to distinguish those, or guard the JMeter ones?
>
> That is indeed a problem.
> I've idea what would work the best to resolve it.
> Changing syntax to %{..} might work.
> Changing syntax to explicit expr("__javaScript(...)") might work as well.
> Making variables explicit might work as well. For instance, we can declare
> "variable holder", and pass it to regex extractor, and later use it for
> retrieving the result.
> That would reduce the number of cases where $ is needed in the test plan as
> every use of $ is basically a place for hidden error like "use of undefined
> variable", and so on
is your suggestion about changing JMeter ${var} syntax or do I
misunderstand ?
>
> > It seems, that `aggregateReport` has its parameters given by a closure
> (is that the right name?) , while `http` per positional parameter. Is
> this a Kotlin feature, that we can mix those, or is it only a first
> example and showing different ways of settings parameters on the elements?
>
> Kotlin has positioned parameters, it has named parameters, parameters can
> have default values (even computed values based on other parameters), and
> the final lambda can be outside of the parenthesis.
>
> >And a completely other construction site: Currently JMeter uses a global
> context, which could trip off users of the dsl, when they want to
> execute plans in parallel. Would this be worse, than now?
>
> Do you mean static context when running the plan?
>
> Vladimir
>
--
Cordialement
Philippe M.
Ubik-Ingenierie
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
>I would understand the
>declaration of a general variable, but (at the moment) not a special
>regex one
See
https://jmeter.apache.org/usermanual/component_reference.html#Regular_Expression_Extractor
Regular expression extractor sets and resets **several** variables.
I think variable names like refName_gn, refName_n_gm, refName_matchNr are
not really accessible,
and regular-expression-related holders would help to hide _n_gm names.
There might be a case for
val upperName by variables.javaScript("$name.toUpperCase()")
that translates to
UserDefinedVariables(name: upperName, value:
${__javaScript(getVar("nameVar").upperCase())})
>I think same feature (#toString) can be used to
>introduce JMeter functions
Exactly. Something like `if`(javaScript("2+2")) {...} could render to
IfController with the condition of ${__javaScript(2+2)}
>With respect to naming `extractRegex`:
I suggest we try something first and then figure out if there's a common
ground.
The key difference between extractByRegex {...} and extractor(regex) { ...
} is
that in the first case, the lambda is always typed as "regex extractor".
In the second case, the type of lambda depends on the type of argument.
It might be possible with a few generics, however, in theory, it is a more
complicated design.
Vladimir
Re: JMeter DSL discussion
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 21.11.21 um 10:47 schrieb Vladimir Sitnikov:
>> Can the kotlin templating mechanism be switched off in that case?
> Unfortunately, there's no way to switch it off yet.
> The issue is known as https://youtrack.jetbrains.com/issue/KT-2425
>
>> I don't understand it, can you give an example?
> testPlan {
> var orderId by variables.regex()
> http {
> url = "example.com"
> extractRegex {
> storeTo(orderId)
> // or variable = orderId
> }
> }
> http("example.com/orders/$orderId")
> http(".../${orderId.random}")
>
> In other words, orderId "allocates" a variable name (e.g. orderIdVar), then
> regex extractor is configured to store the value to "orderIdVar"
> Later, $orderId is Kotlin expression that calls orderId.toString() which
> would return the variable name "orderIdVar"
Given this example I can understand, how $orderId will be rendered to
${orderIdVar} and I think same feature (#toString) can be used to
introduce JMeter functions.
What I don't get yet, is why or how the variables.regex() would be
needed. What would it do at that place? I would understand the
declaration of a general variable, but (at the moment) not a special
regex one. At the same time I fail to understand the usage of
${orderId.random} (probably for the same reason).
With respect to naming `extractRegex`:
* we are not extracting a regex, but something using a regex. Should we
make that more clear by using something like `extractByRegex`?
* we have a lot of different extractors, can/should these be made more
unified by using something like `extractor(regex) { storeTo(orderId) ... }`?
>
>> I wanted to ask about the intended usage. How should those possibilities
> map to the elements?
>
> That is the key question :)
> They all will be useful.
>
>> Currently we get the JMeterContext by a static function and everyone
> would get the same context. That is no problem when used inside the GUI,
> but might be a problem, when used by developers in other circumstances
> (and not aware of this)
>
> That is sad indeed, yet it it does not block DSL implementation. It would
> be great to lift that restriction and make JMeter less static in the future.
Yes, it has nothing directly to do with this discussion of a DSL, but I
think it might be more dangerous, when people start using it.
Felix
> Vladimir
>
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
>I think, we already use %{..} inside JMeter,
Just in case, Gatling team has recently moved to #{...} syntax as ${...}
caused issues with both Scala and Kotlin.
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
I've added a "copy code" context action (implementation, tests,
documentation), so it copies the code that users can paste into their
projects.
In other words, it enables configuring an element (or a subtree) in UI
and automatically generating code.
The generator uses element schemas to create a better-looking code,
and it resorts to setProperty(..., ...)
when the element lacks schema.
I do not think we need to add schemas for all the elements, and we
should be good to go.
It would be great if somebody could help review and test the change.
In theory, the change should be backward compatible.
Vladimir
Re: JMeter DSL discussion
Posted by Milamber <mi...@apache.org>.
Hi,
Seems a good approach for DSL features, Java/Kotlin as language seems
good too.
Probably need:
* add a new page on manual to describe and explain how to create DSL
plan (with your samples below)
* and (perhaps) indicate that is a 'beta' features, and will be improve
in next version of JMeter.
Milamber
On 06/06/2023 21:20, Vladimir Sitnikov wrote:
> I've been improving tests, and I realized there's a small change that
> brings a decent way to build test plans.
>
> I've updated PR https://github.com/apache/jmeter/pull/678
> The PR includes samples for both Kotlin and Java
> (see OpenModelThreadGroupConfigElementTest
> and OpenModelThreadGroupConfigElementJavaTest).
>
> I think we can merge it and make incremental improvements later.
> The good part is that DSL is usable for all the components with no
> modifications.
>
> I might miss certain cases, however, it looks nice, at least for testing
> JMeter itself.
>
> WDYT?
>
> Here's Java code:
>
> HashTree tree = testTree(b -> {
> b.add(TestPlan.class, tp -> {
> b.add(OpenModelThreadGroup.class, tg -> {
> tg.setName("Thread Group");
> // 5 samples within 100ms
> // Then 2 sec pause to let all the threads to finish,
> especially the ones that start at 99ms
> tg.setScheduleString("rate(50 / sec) random_arrivals(100 ms)
> pause(2 s)");
> b.add(listener);
> b.add(CounterConfig.class, c -> {
> c.setVarName("counter");
> c.setIncrement(1);
> });
> b.add(DebugSampler.class, dbg -> {
> dbg.setName("${counter}");
> dbg.setDisplayJMeterProperties(false);
> dbg.setDisplayJMeterVariables(false);
> dbg.setDisplaySystemProperties(false);
> });
> });
> });
> });
>
> Here's Kotlin code:
>
> val tree = testTree {
> TestPlan::class {
> OpenModelThreadGroup::class {
> name = "Thread Group"
> // 5 samples within 100ms
> // Then 2 sec pause to let all the threads to finish,
> especially the ones that start at 99ms
> scheduleString = "rate(50 / sec) random_arrivals(100 ms)
> pause(2 s)"
> listener()
> CounterConfig::class {
> varName = "counter"
> increment = 1
> }
> DebugSampler::class {
> name = "\${counter}"
> isDisplayJMeterProperties = false
> isDisplayJMeterVariables = false
> isDisplaySystemProperties = false
> }
> }
> }
> }
>
> Vladimir
>
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
I've been improving tests, and I realized there's a small change that
brings a decent way to build test plans.
I've updated PR https://github.com/apache/jmeter/pull/678
The PR includes samples for both Kotlin and Java
(see OpenModelThreadGroupConfigElementTest
and OpenModelThreadGroupConfigElementJavaTest).
I think we can merge it and make incremental improvements later.
The good part is that DSL is usable for all the components with no
modifications.
I might miss certain cases, however, it looks nice, at least for testing
JMeter itself.
WDYT?
Here's Java code:
HashTree tree = testTree(b -> {
b.add(TestPlan.class, tp -> {
b.add(OpenModelThreadGroup.class, tg -> {
tg.setName("Thread Group");
// 5 samples within 100ms
// Then 2 sec pause to let all the threads to finish,
especially the ones that start at 99ms
tg.setScheduleString("rate(50 / sec) random_arrivals(100 ms)
pause(2 s)");
b.add(listener);
b.add(CounterConfig.class, c -> {
c.setVarName("counter");
c.setIncrement(1);
});
b.add(DebugSampler.class, dbg -> {
dbg.setName("${counter}");
dbg.setDisplayJMeterProperties(false);
dbg.setDisplayJMeterVariables(false);
dbg.setDisplaySystemProperties(false);
});
});
});
});
Here's Kotlin code:
val tree = testTree {
TestPlan::class {
OpenModelThreadGroup::class {
name = "Thread Group"
// 5 samples within 100ms
// Then 2 sec pause to let all the threads to finish,
especially the ones that start at 99ms
scheduleString = "rate(50 / sec) random_arrivals(100 ms)
pause(2 s)"
listener()
CounterConfig::class {
varName = "counter"
increment = 1
}
DebugSampler::class {
name = "\${counter}"
isDisplayJMeterProperties = false
isDisplayJMeterVariables = false
isDisplaySystemProperties = false
}
}
}
}
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
>There will be a meetup related to JMeter DSL tomorrow
Here's the recording: https://youtu.be/FZOcmtp5sJY
Thanks everybody for joining in less than 24h scheduling timeframe :)
It was nice to see you all, and it is great we have common issues, common
ideas.
Many thanks to Felix for emphasizing that participation in dev@jmeter
discussions
would make you closer to the core team, and it is important to hear
opinions, ideas.
I might be missing something, so please feel free to add/correct me.
* I think nobody objected to programmatic DSL
* There was an idea to activate GitHub Discussions for
github.com/apache/jmeter project.
I see it is possible by voting on a dev mailing list and then filing a
ticket to INFRA (many ASF projects have already enabled Discussions)
I'll start voting soon.
* We diverted multiple times into "it would be great if TestElement API was
refined" discussion,
however, every time it ends up with "it is probably a lot of work".
As I said earlier, I agree it would be great to refine TestElement API,
however,
I do not think that refinement is a pre-requisite for creating and
delivering DSL.
If there are ideas on that refinement, please feel free to start a
discussion thread.
* Someone mentioned certain TestElement features are in-UI only. For
instance,
sometimes "value validation" is implemented in GUI classes only, so all DSL
implementations
have to deal with it somehow.
That is a nice finding, and I think we could make incremental improvements
there.
* There was a discussion regarding "incubating DSL in-JMeter" vs
"incubating DSL out of JMeter and merging sometime later"
I incline that we should incubate DSL in-JMeter for the following reasons:
1) Having something in-JMeter increases the visibility of the feature for
the end-users
2) Having in-JMeter DSL allows immediate support DSLs for the newly
added/modified in-JMeter components.
We can't promote/reference third-party projects on the key JMeter pages due
to ASF restrictions,
so third-party projects need to do their own promotion.
As for me, having something in-JMeter is really motivating.
The alternative option is to "incubate out of JMeter, then weigh options,
compare pros and cons",
however, those activities do demotivate me. I could throw pros and cons,
however, I would rather
invest time on the feature itself rather than spend N months on pros and
cons discussions :-/
By the way, recently Gatling team released what they call Java and Kotlin
DSLs, so if we spend
years on discussions, we would lag behind a lot.
* We have discussed that Java, Kotlin, and Groovy might be viable languages
for DSL,
different people expressed their own opinions. I am not sure what is the
summary though.
First of all, I think Groovy is not that good fit for the JMeter DSL as
* Groovy has a significant amount of magic (you don't see the errors in DSL
immediately, and you basically need to execute it to find typos)
* IDE support for Groovy is bad. I know there are gdsl files, however,
overall IDE experience with Groovy is so-so, and writing gdsl files is a
special skill
* Groovy is a very rich language (especially when it comes to DSL), so
automatic code formatting solutions are hard or they just do not exist
* Groovy-Java integration is far from seamless
* Groovy is rich, so refactoring is really hard: rename, "extract method",
and other refactorings are hard or even impossible.
For instance, once I tried to extract a helper method out of Jenkins Groovy
DSL,
and I had to add "resolveStrategy = Closure.OWNER_FIRST" to make it work.
No way I could explain that to JMeter users.
I am sure all the features of Java-based DSL can be easily implemented in
Kotlin-based DSL.
On the other hand, there are features that are trivial in Kotlin, yet they
are hard or impossible in Java-based DSL.
That is why I suggest we proceed with Kotlin-based DSL.
Something that comes to my mind right away:
* default values for parameters
* named arguments
* limited operator overloading. For instance, "5.seconds" or
(a/b).roundToInt() are not possible in Java
* DSL compatibility with the standard for/if constructs
* simplified refactoring (e.g. select multiple lines of DSL and extract it
into a method via default IDE features)
* enhanced deprecation: warning, error, hidden, suggested replacements
* multiline string literals (they exist in Java 15+, however, there are
users who can't migrate to Java 15+ yet)
* much stronger type inference. Kotlin is able to deduce types in many
cases where Java stops.
Java design focuses on "speed of compilation", so they have strict limits
where inference stops and it requires
user to specify the type.
Kotlin focuses on pragmatic design, so it has much stronger type inference
algorithms,
so it is easier for developers to write code (e.g. less explicit types
needed in generic-heavy code)
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
There will be a meetup related to JMeter DSL tomorrow: 24 November 11:30
UTC (see
https://github.com/anasoid/jmeter-as-code/issues/133#issuecomment-976332680
)
Feel free to join:
https://zoom.us/j/95780554945?pwd=MWtvYjlmc1dRREMzbWdsbmxSMk5MQT09
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Well, maybe we see use cases, when we see the first implementation of
>the generating function (`http`, `aggregateReport` in your example).
I've filed https://github.com/apache/jmeter/pull/678 to get
something started.
The relevant code is located in jmeterdsl.kt.
The immediate question is "how do we represent in-flight nodes?".
One of the ways is to stick with the current JMeter's
jmeter.testelement.TestElement instances,
however, the drawback is that those classes have weird APIs.
For instance, ThreadGroup has setDelay(long), and it has no way to set
delay based on a property.
Samplers have .sample() method that does not seem to make sense in the
context of test plan generation.
HttpSampler exposes readResponse(...), .interrupt(), and so on.
Then, the relationship between TestElements and their children is not that
regular. For instance, ThreadGroup
owns LoopController, however, that association is configured **only** in
ThreadGroupGui#modifyTestElement method,
so if you instantiate ThreadGroup directly, it won't work.
On the other hand, if we go with creating dsl-only wrappers, it might
increase the amount of boilerplate code
required to add a new sampler: "sampler definition class", "GUI class",
"properties file", "dsl wrapper", "dsl function".
It does not sound that bad, however, I am not sure it is something we
should be afraid of.
Having a separate set of "test element classes" might be good as we could
design it for test plan generation purposes,
and we would not expose runtime-like methods unless they are needed.
Vladimir
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
> Can the kotlin templating mechanism be switched off in that case?
Unfortunately, there's no way to switch it off yet.
The issue is known as https://youtrack.jetbrains.com/issue/KT-2425
>I don't understand it, can you give an example?
testPlan {
var orderId by variables.regex()
http {
url = "example.com"
extractRegex {
storeTo(orderId)
// or variable = orderId
}
}
http("example.com/orders/$orderId")
http(".../${orderId.random}")
In other words, orderId "allocates" a variable name (e.g. orderIdVar), then
regex extractor is configured to store the value to "orderIdVar"
Later, $orderId is Kotlin expression that calls orderId.toString() which
would return the variable name "orderIdVar"
>I wanted to ask about the intended usage. How should those possibilities
map to the elements?
That is the key question :)
They all will be useful.
>Currently we get the JMeterContext by a static function and everyone
would get the same context. That is no problem when used inside the GUI,
but might be a problem, when used by developers in other circumstances
(and not aware of this)
That is sad indeed, yet it it does not block DSL implementation. It would
be great to lift that restriction and make JMeter less static in the future.
Vladimir
Re: JMeter DSL discussion
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 20.11.21 um 14:28 schrieb Vladimir Sitnikov:
>> The annotations could be used for scanning for TestPlan elements on
> startup, too.
>
> I remember we have discussed it, however, it sounds like a different
> feature.
> Of course, some level of code generation might help, however, I have no use
> cases for it now.
Well, maybe we see use cases, when we see the first implementation of
the generating function (`http`, `aggregateReport` in your example).
I thought it might help developers of plugins to get started on
integration into the dsl.
>
>> Maybe start with a global org.apache.jmeter.experimental.dsl
> package/module name
>
> I think experimental works better with annotations like @OptIn(Experimental)
> If you put experimental into a package name, you can't remove it without
> breaking the usages.
My idea was to use it to explicitly hinder us from re-using the code :)
but we could try with an annotation and see how it works out.
>
> A single .dsl. package would help indeed, so users could import
> jmeter.dsl.* and use the functions rather than import every package or
> class individually.
> On the other hand, the users won't be able to unimport features they do not
> need
If you have a clear idea, of a structure, we could use that, but if not,
it is (in my opinion) valid to start with such a mess.
>
>> Kotlin has a very similar string template format to JMeter, is there a
> good way to distinguish those, or guard the JMeter ones?
>
> That is indeed a problem.
> I've (no) idea what would work the best to resolve it.
> Changing syntax to %{..} might work.
I think, we already use %{..} inside JMeter, too. (Template language for
the https script recorder naming logic)
> Changing syntax to explicit expr("__javaScript(...)") might work as well.
Can the kotlin templating mechanism be switched off in that case?
> Making variables explicit might work as well. For instance, we can declare
> "variable holder", and pass it to regex extractor, and later use it for
> retrieving the result.
> That would reduce the number of cases where $ is needed in the test plan as
> every use of $ is basically a place for hidden error like "use of undefined
> variable", and so on
I don't understand it, can you give an example? Something like a
dsl-function (`http(jmVar("host))` and `http("""${jmFunc("upper",
jmVar("hostname"))}""")` (not sure, if it is valid kotlin))
>
>> It seems, that `aggregateReport` has its parameters given by a closure
> (is that the right name?) , while `http` per positional parameter. Is
> this a Kotlin feature, that we can mix those, or is it only a first
> example and showing different ways of settings parameters on the elements?
>
> Kotlin has positioned parameters, it has named parameters, parameters can
> have default values (even computed values based on other parameters), and
> the final lambda can be outside of the parenthesis.
I wanted to ask about the intended usage. How should those possibilities
map to the elements?
>
>> And a completely other construction site: Currently JMeter uses a global
> context, which could trip off users of the dsl, when they want to
> execute plans in parallel. Would this be worse, than now?
>
> Do you mean static context when running the plan?
Currently we get the JMeterContext by a static function and everyone
would get the same context. That is no problem when used inside the GUI,
but might be a problem, when used by developers in other circumstances
(and not aware of this)
Felix
>
> Vladimir
>
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
>The annotations could be used for scanning for TestPlan elements on
startup, too.
I remember we have discussed it, however, it sounds like a different
feature.
Of course, some level of code generation might help, however, I have no use
cases for it now.
>Maybe start with a global org.apache.jmeter.experimental.dsl
package/module name
I think experimental works better with annotations like @OptIn(Experimental)
If you put experimental into a package name, you can't remove it without
breaking the usages.
A single .dsl. package would help indeed, so users could import
jmeter.dsl.* and use the functions rather than import every package or
class individually.
On the other hand, the users won't be able to unimport features they do not
need
> Kotlin has a very similar string template format to JMeter, is there a
good way to distinguish those, or guard the JMeter ones?
That is indeed a problem.
I've idea what would work the best to resolve it.
Changing syntax to %{..} might work.
Changing syntax to explicit expr("__javaScript(...)") might work as well.
Making variables explicit might work as well. For instance, we can declare
"variable holder", and pass it to regex extractor, and later use it for
retrieving the result.
That would reduce the number of cases where $ is needed in the test plan as
every use of $ is basically a place for hidden error like "use of undefined
variable", and so on
> It seems, that `aggregateReport` has its parameters given by a closure
(is that the right name?) , while `http` per positional parameter. Is
this a Kotlin feature, that we can mix those, or is it only a first
example and showing different ways of settings parameters on the elements?
Kotlin has positioned parameters, it has named parameters, parameters can
have default values (even computed values based on other parameters), and
the final lambda can be outside of the parenthesis.
>And a completely other construction site: Currently JMeter uses a global
context, which could trip off users of the dsl, when they want to
execute plans in parallel. Would this be worse, than now?
Do you mean static context when running the plan?
Vladimir
Re: JMeter DSL discussion
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 20.11.21 um 12:46 schrieb Vladimir Sitnikov:
>> Do you have a rough idea, what the dsl would look like, or how the
>> elements get mapped/detected to be a part of the dsl?
> Commonly used elements have to be mapped manually for consistency reasons.
> There might be a generic (string-like) approach to allow fine-tuning.
I wondered, whether we could add annotations and a annotations processor
to generate code/classes, that could be used to setup dsl components.
The annotations could be used for scanning for TestPlan elements on
startup, too.
>
>> Could you elaborate a bit more on your plan, or would the extra module
>> be really an add-on?
> I am not sure yet.
> It might be that it would be good enough to keep the dsl classes side by
> side with the corresponding elements.
> In other words, creating a module for a couple of classes might not be that
> justified.
When we try to get our code into modules, it might be a good idea to
have this sorted out, before (but that should not let us keep from
experimenting).
Maybe start with a global org.apache.jmeter.experimental.dsl
package/module name, and mash everything in there for a start?
>
>> Do you have a rough idea, what the dsl would look like
> Something behind the lines of
>
> val plan = testPlan {
> aggregateReport {
> outputFile = File("...")
> }
> openModelThreadGroup {
> schedule {
> rate(50.0 / second)
> random_arrivals(10.minutes)
> }
> transaction("hello") {
> http("http://hello.example")
> http("http://world.example")
> }
> }
> }
>
> println(plan.toJxm())
> plan.execute()
Kotlin has a very similar string template format to JMeter, is there a
good way to distinguish those, or guard the JMeter ones?
It seems, that `aggregateReport` has its parameters given by a closure
(is that the right name?) , while `http` per positional parameter. Is
this a Kotlin feature, that we can mix those, or is it only a first
example and showing different ways of settings parameters on the elements?
And a completely other construction site: Currently JMeter uses a global
context, which could trip off users of the dsl, when they want to
execute plans in parallel. Would this be worse, than now?
Felix
>
> Vladimir
>
Re: JMeter DSL discussion
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Do you have a rough idea, what the dsl would look like, or how the
>elements get mapped/detected to be a part of the dsl?
Commonly used elements have to be mapped manually for consistency reasons.
There might be a generic (string-like) approach to allow fine-tuning.
>Could you elaborate a bit more on your plan, or would the extra module
>be really an add-on?
I am not sure yet.
It might be that it would be good enough to keep the dsl classes side by
side with the corresponding elements.
In other words, creating a module for a couple of classes might not be that
justified.
>Do you have a rough idea, what the dsl would look like
Something behind the lines of
val plan = testPlan {
aggregateReport {
outputFile = File("...")
}
openModelThreadGroup {
schedule {
rate(50.0 / second)
random_arrivals(10.minutes)
}
transaction("hello") {
http("http://hello.example")
http("http://world.example")
}
}
}
println(plan.toJxm())
plan.execute()
Vladimir
Re: JMeter DSL discussion
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 20.11.21 um 10:20 schrieb Vladimir Sitnikov:
>> I think it's important to slowly isolate the Jmeter core from GUI,
> If anybody wants to contribute that, please do so.
>
> Antonio>I think it's a good idea to add DSL in core is a good idea
>
> The immediate question is do we put classes for DSL right into the
> current ApacheJMeter_core, ApacheJMeter_http, ApacheJMeter_jdbc,
> or do we create a new set of modules like ApacheJMeter_core_dsl,
> ApacheJMeter_http_dsl, and so on?
>
> It might be that in the future ApacheJMeter_http would become
> ApacheJMeter_http, ApacheJMeter_http_gui, ApacheJMeter_http_dsl.
> That would triple the number of folders in src/protocols.
>
> If there are no objections, I would try adding DSL via extra modules.
Could you elaborate a bit more on your plan, or would the extra module
be really an add-on?
Do you have a rough idea, what the dsl would look like, or how the
elements get mapped/detected to be a part of the dsl?
Felix
>
> Vladimir
>