Github user emilianbold commented on the issue:
https://github.com/apache/jmeter/pull/293
Done.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user pmouawad commented on the issue:
https://github.com/apache/jmeter/pull/293
+1 for fixing both methods
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
Github user emilianbold commented on the issue:
https://github.com/apache/jmeter/pull/293
Like I've said, I wanted my patch to be low-impact. Ideally normalizeList
should be something like this:
```java
protected Collection normalizeList(Collection coll) {
Github user emilianbold commented on the issue:
https://github.com/apache/jmeter/pull/293
> could be the same issue available with the next method "normalizeMap"?
Actually, yes! Should I update this patch or leave normalizeMap for another
fix?
---
If your project is set up
Github user vherilier commented on the issue:
https://github.com/apache/jmeter/pull/293
Hi guys,
could be the same issue available with the next method "normalizeMap"?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user emilianbold commented on the issue:
https://github.com/apache/jmeter/pull/293
It's unclear to me why it's so important to use the same kind of collection
class. So I tried to keep the patch low-impact.
Instead of null or an empty list it could return a new
Github user FSchumacher commented on the issue:
https://github.com/apache/jmeter/pull/293
Great, I wonder if we should change the return value from `null` to
`Collections.emptyList()` in case of an Exception, too.
I will add a test case to the bugzilla entry for
Github user emilianbold commented on the issue:
https://github.com/apache/jmeter/pull/293
Done. The new patch is much cleaner.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user emilianbold commented on the issue:
https://github.com/apache/jmeter/pull/293
Ammeding the commit as we speak.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user pmouawad commented on the issue:
https://github.com/apache/jmeter/pull/293
@FSchumacher , I agree. Let's commit the patch without the new method.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user FSchumacher commented on the issue:
https://github.com/apache/jmeter/pull/293
As Emilan suggested, we could change normalizeList to always create a new
collection, instead of introducing a new method, that has configurable
behaviour.
I consider the current
Github user pmouawad commented on the issue:
https://github.com/apache/jmeter/pull/293
Thanks for analysis and patch. It was a hard one !.
@FSchumacher , I don't understand your comment , what exactly do you want
to change ?
Thanks
---
If your project is set up for it,
Github user FSchumacher commented on the issue:
https://github.com/apache/jmeter/pull/293
Great. Thanks for your analysis and your fix.
I tend to change the behaviour of normalizeList, even if it is a change in
the unwritten contract. The current behaviour seems wrong to me.
13 matches
Mail list logo
