More generally, if a node state changes from CONFIGURE to IDLE from reloading, is it due to the exception of InvalidSettingsException, any conccrete reasons?
the node description doesn’t comply with the XML schema namely very likely because of the dt-, dl- and dd-tags.
And regarding the node state changes: yes, that’s very likely due to the InvalidSettingsException you mentioned, probably thrown in the configure-method of the respective node on load. If you are familiar with debugging then I would suggest to set a breakpoint there (or a general ‘InvalidSettingsException’-breakpoint) in order to find out why the node configuration fails.
is that possible for me to add more XML Shema for <knimeNode> to make them compatible? If it is possible, how? I am not so familiar with XML.
Or if with <dd dt/> don’t work, are there corresponding elements in knime xml schema to allow listing?
Thanks
Kefang
If the debug you mean is actually not the debug in Eclipse, right? But the one in KNIME. I have heard once about it, but it demands on some special settings. How’s that? Is there any pages there?
Kefang
Yes, you are right, the debug in eclipse (i.e. what we refer to as KNIME SDK). You have to start KNIME from within the SDK in debug mode. If done so, e.g., the program execution will be halted at so called breakpoints where you then can inspect the current state (variables etc.). A quick intro on debugging with eclipse can, e.g., be found here: https://www.vogella.com/tutorials/EclipseDebugging/article.html
I meant the one which connected to KNIME, not the one just from Eclipse side. For example, the bug above gives no specific information about which nodes in the workflow have the exception…
Nothing is caught there for the reloading. Most useful information is the one, state changed from EXECUTED to IDLE. Do you know which exception class provide this information?
feel confrusted…
Kefang
Hm, maybe the other reason could be that the output spec(s) returned by the configure-method on load differs from the one that it has been stored with.
(I would also suggest to set the console log level to ‘debug’ if you haven’t already - then you might get more insights)
I have another suspicion: the loading of the port object at the output port failed. You can quickly confirm that if there is a ‘DataLoadError’ in the console log for the respective node.
I didn’t mean an exception but just a message in the consol log. Nevermind, now that you are already digging into core-classes, can you please add a breakpoint in the WorkflowManger one line below if (!hasData && nc.getInternalState().equals(EXECUTED)) { - line 8698 on my computer (which might vary depending on the version). If you run into that breakpoint then something went wrong while loading the output port object.
The cause of this problem is the PortObjectSpec is null. By changing the code in the following way,
@Override
public PortObjectSpec getSpec() {
// TODO if it access the null one??
if(m_rSpec != null)
return m_rSpec ;
return new RepResultPortObjectSpec();
}
Here, we object is of type PortObject. It is loaded according to the PortObjectSpec and requires implicitly the spec to be the value of its PortObjectSpec. However, in my code, I didn’t assign the spec to PortObject during the loading process. It results in the null value for Spec and inconsistent state for workflow.
One suggestion, do assign the spec to its PortObject during serialization by method **XXPortObjectSerializer#load