FWIW I recently replaced several C-style loops with *for ( x in y )* for
iterating over both lists and maps in CPS code and for the most part
conversion went fine. There were a couple of CPS sections where I could not
use that construct and had to fall back on the C-loops and further do a
torturous cast to avoid a serialization error getting keys and values from
the map. I want to say *Set<Map.Entry<K,V>>* caused the exception because
*AbstractMap.SimpleEntry* and *.SimpleImmutableEntry* are serializable,
while *Set *is not, per the JDK.
for ( int i = 0; i < myMap.size(); i++ ) {
// hacktacular String() cloning to avoid NotSerializableException; also
// hacktacular Map > Set > Array morph to enable C-style looping
final foo = new String( myMap.entrySet().toArray()[i].value )
// do stuff with foo...
}
Nonetheless as mentioned in another part of the script I had no problem
using the shorter alternative, nor accessing keys and values using
*myMap.key* and *myMap.value*. Not sure what the difference is with my more
stubborn loop.
On Wednesday, April 27, 2016 at 8:21:45 AM UTC-7, Norbert Lange wrote:
>
>
>
> Am Mittwoch, 27. April 2016 16:41:40 UTC+2 schrieb Jesse Glick:
>>
>> On Tuesday, April 26, 2016 at 7:18:55 PM UTC-4, Norbert Lange wrote:
>>>
>>> There seem to be some arcane rules on how to iterate over some
>>> builtin Groovy/Java Types within a sandbox. I haven`t found a way that
>>> works without manually allowing the function.
>>
>>
>> Which methods did you need to approve? We can easily add them to the
>> default whitelist in the Script Security plugin. But anyway
>>
>> The map`s each (at least)
>
>
>>
>>> 2) Serialization issues for iterators.
>>>
>>
>> `for (x : list) {…}` works as of `workflow-cps` 2.x. Other iterators do
>> not yet work (outside a `@NonCPS` method). Probably fixing them is not
>> hard, just have not gotten to it yet
>>
>
> Yes, these issues I can very likely work around. For someone who is new to
> Groovy and Jenkins sandboxing, a list of preferred methods would be very
> welcome (the examples from the workflow libs are rather simple). There are
> atleast 3 different ways to iterate over containers, and several variations
> of those for maps.
>
>
>>
>>
>>>
>>> take the createDList
>>> which seems to execute the code differently (throws errrors, need to
>>> define a explicit variable)
>>>
>>
>> Not sure what this is about. If you find something you think should work
>> which does not work in a minimal reproducible script, please file a bug
>> report for it.
>>
> Where? Is that a feature-not-bug of Groovy, an issue in Jenkins or some
> Plugin? I was hoping for some feedback as I am not proficient in either of
> those to pinpoint issues.
> The code above should be able to explain the issue, the exact same method
> body in the node scope works fine, the call will result in some message
> about "it not defined". Similary there seems some issues with name clashes
> (if variables in functions are named like those in the node scope), but it
> mightve been some flukes during trial-and-error
>
>
>>
>>
>>>
>>> Are variables from Closures global?
>>>
>>
>> Local `def` variables in a closure? Not sure what you are referring to
>> here.
>>
> See last point, and the code were I can access the it variable after the
> closure were its used (Noted with "// Weird !" )
>
>>
>> The main problem you are presumably hitting is the well-known
>> JENKINS-26481 <https://issues.jenkins-ci.org/browse/JENKINS-26481>. We
>> are working on a fix, but in the meantime, do not use any method built into
>> Groovy which takes a closure argument, such as `list.each {x -> …}` or
>> `someText.eachLine {line -> …}`. Rather use a Java-style loop. (To be on
>> the safe side, also avoid iterators, meaning use a C- or JDK 1.4-style loop
>> with an index.)
>>
> Could you please post me the preferable code for iterating a map in this
> way? (Not sure I fully understand the bug )
>
>
>> Incidentally `it` does not currently work in closures as noted in
>> JENKINS-33468
>> <https://www.google.com/url?q=https%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-33468&sa=D&sntz=1&usg=AFQjCNHCpckU-LtRXqq1a2tEPCzNrYhPTw>;
>>
>> use an explicit parameter name instead.
>>
> That seems to be one of the issues I am fighting with, and might be that
> the supposed name-clashes came from unfocused variations of the code.
> Strangely it does seem to somewhat work in the node body?
>
> Kind Regards,
> Norbert
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/53ef9445-93a4-42aa-885a-e5a5238758ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
