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 <[email protected]> > 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? > > > On Thu, May 16, 2013 at 1:11 AM, Oleg Nenashev <[email protected]>wrote: > >> 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 написал: >> >>> 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 >>> >> -- >> 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 [email protected]. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Marc MacIntyre > > -- > 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 > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
