Interface/Abstract PortObject/PortObjectSpec

I have an existing PortObject implementation which is in use by my current nodes and workflows already, let's call it AncientPortObject. Due to necessary changes and improvements I need a new implementation of this PortObject, let's call it ImprovedPortObject. The improvements are completely internal, and both PortObjects expose the same API, so they are basically interchangable from a receiving node's perspective.

Now, I would like existing nodes to accept input from AncientPortObject and ImprovedPortObject as well.

My idea was the following:

  • Add an abstract class or interface PhilippsAbstractPortObject which is implemented by the old and new port objects and pull up the common API
  • Change existing nodes so that they require the PhilippsAbstractPortObject as input now instead of AncientPortObject, so they are able to handle the old and the new format
  • Newly implemented nodes produce ImprovedPortObject instances

Until here, things seemed logical. After implementing my changes however, I get the following error when starting KNIME:

ERROR     ModalContext PortTypeRegistry     CODING PROBLEM    Port object class 'blabla.PhilippsAbstractPortObject' is not registered at the extension point org.knime.core.PortType.

So, I obviously I need to register the PhilippsAbstractPortObject in the extension point. No big deal. But, I notice, the extension point wants me to register *Serializer classes as well. That doesn't make sense to me, as I would never serialize/deserialize the PhilippsAbstractPortObject itself.

So, taking one step back and a deep breath I have some general doubts: Is this idea on addressing things reasonable at all? Is this a stupid idea to handle my issue? Any suggestions or best practices?

-- Philipp


I've now simply registered some no op. PortObjectSerializer and PortObjectSpecSerializer for the abstract port object and the error is obviously gone. My first experiments show that everything seems to be working as expected.

Yet I would be really greatful for soem feedback from the KNIME developers whether this is an "OK" way to handle things.

1 Like

Hi Philipp,

I think there is not much to add to your summary. You are right: We do not have the notion of deprecating (or let's say interfacing + versioning) PortObjects. So what you are doing seems to be very sensible to me.

Note that for custom data types there is a schema for different versions / implementations. The extension point allows you to register multiple cell implementations for the same data type, and each of which has its own serializer. Maybe we should do the same with PortObject definitions.


Hi Bernd,

perfect, thanks for the feedback!

-- Philipp