nodeProperty subclass with null node member

[Marc MacIntyre]

I've got a subclass of NodeProperty that, in the canTake function, frequently has a null value for this.node.  Is there any way to prevent this, or any common reason why it would be null?  I expected that setNode() would be called when the node instantiated the NodeProperty.

--

Marc MacIntyre

[Oleg Nenashev]

Hello Marc,

I've experienced same issue at 1.480.3 LTS and implemented patch for the Jenkins core.
I'm going to create pull request after getting approvals.

As workaround, you can parse StaplerRequest header and then get Slave according to the name from the request.
You can find sample code here: https://gist.github.com/oleg-nenashev/5590176 

Best regards,
Oleg Nenashev
R&D Engineer, Synopsys Inc.

www.synopsys.com

среда, 15 мая 2013 г., 0:43:23 UTC+4 пользователь Marc MacIntyre написал:

[Marc MacIntyre]

Thanks, Oleg; I look forward to seeing that pull request.  I'm not clear on where your workaround code would be implemented, though; I understand that I could derive the ancestor from the time the nodeProperty is initially configured via stapler request, but I don't get a stapler request when the nodeProperty is created on startup, do I?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Marc MacIntyre

[Олег Ненашев]

Hello and sorry for delay,

I suppose you can implement following workaround in case of your custom NodeProperty:
•    Get node at NodePropertyDescriptor ::newInstance() using proposed workaround
•    Pass Node/NodeDescriptor to your NodeProperty via its constructor
•    Assign node information to serializable field (ex, nodeName)
•    Therefore, this field will be propagated to configuration file and will be available after Jenkins restart.
•    You can implement getNode(String nodeName), which gets node on-demand and then calls setNode() to cache node for future use.

General-purpose workaround:
•    Implement task with “onStartup” and “onSlaveConfigSubmit” triggers, which will iterate through existing slaves and call setNode() for all of theirs properties

// Offtopic: Core patch
I’ve implemented first approach at my local fork of Jenkins Core. NodeProperty provides getNode() method, which returns owner according to cache or stored slave’s name. This approach is quite easy and probably should be ported to main branch.

BTW, I have following concerns:
•    NodeProperty.owner is a protected field. So, child classes can access and change it directly
•    NodeProperty::setOwner() method is overridable
•    It would be great to encapsulate “owner” via (final?) getter and setter
•    This approach will corrupt backward compatibility (in particular, proposed workaround won’t work), so such refactoring could be very painful.

Probably, somebody from core team could comment this proposal. 
I’ll try to create issue at BugTracker today.

Best regards,
Oleg Nenashev
R&D Engineer, Synopsys Inc.
www.synopsys.com

2013/5/16 Marc MacIntyre <mar...@purestorage.com>

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/KX7NZz39ssU/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.