Jenkins build is back to normal : JMeter » JMeter-trunk #353

See

Build failed in Jenkins: JMeter » JMeter-trunk #352

See Changes: -- [...truncated 1.60 KB...] > git checkout -f 403842148e82c24e560c365efd8b7290076b0ba5 # timeout=10 Commit message: "Update log4j2 to 2.15.0 to fix CVE-2021-442

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully edited a comment on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other

briantully edited a comment on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) yo

[GitHub] [jmeter] briantully commented on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI r

briantully commented on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993204248 > Any ideas or ETA when would the public release be there with the security fix included? @mazen160 rather than wait for a new release (and potentially new bugs) you can

[Jmeter] Nightly build artifacts

Hello, There is any maven repo where we can find Jmeter nightly artifacts? -- Cordialement, - Anas OUFDOU

[GitHub] [jmeter] mazen160 commented on pull request #680: Update log4j2 to 2.15.0 to fix CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI rel

mazen160 commented on pull request #680: URL: https://github.com/apache/jmeter/pull/680#issuecomment-993021185 Any ideas or ETA when would the public release be there with the security fix included? -- This is an automated message from the Apache Git Service. To respond to the message, p

Re: Include + Module controller hybrid

> Do you think relative path is a viable solution? > > An alternative option is to have "library paths" JMeter propery, so it > would lookup libraries in the given set of paths. Yup, I think either of options would work. > When it comes to the UI, I would love to see the included elements, and it

Re: Include + Module controller hybrid

>test plan can >be run in different envs with different jmeter installation paths Do you think relative path is a viable solution? An alternative option is to have "library paths" JMeter propery, so it would lookup libraries in the given set of paths. When it comes to the UI, I would love to s

Re: Include + Module controller hybrid

> By the way, I wonder if we can explicitly forbid the use of ${...} > expressions in file names. Mm. I see it as a quite limiting change, considering the test plan can be run in different envs with different jmeter installation paths, or for ex. I run it locally on the pre-installed jmeter instanc

Re: Include + Module controller hybrid

>Gotcha, thanks for clarifying - then it might absolutely be an >alternative solution. In practice, there's not much difference overall :) However, many programming languages have the concept of "exporting and importing symbols" (e.g. import ... in Java), so JMeter might be good to borrow the con

Re: Include + Module controller hybrid

> I suggest that "import element" would create a virtual node that references > the external file symbolically. > Then, the import could be "scoped to the subtree", so you might import > "commons" library at the very top, and you could import more specific > "libraries" somewhere inside the tree.

Re: Include + Module controller hybrid

> However, it doesn't seem to not be an optimal solution for the case when I have 20+ "libraries" with a certain level of depth each having multiple nested modules/elements that also can reference I think there's misunderstanding. I don't suggest copying the trees at import time. I suggest that "i

Re: Include + Module controller hybrid

Thanks for your input! > Have you explored the possibility of "Import Element"? > In other words, an element that would "import a jmx file" into the > namespace of the current test plan. > Then Module Controllers should be able to reference the nodes of the > imported JMX. > For example, "Import a