Details
-
Bug
-
Status: Reopened
-
Not a Priority
-
Resolution: Unresolved
-
1.5.1, 1.6.0
-
None
-
None
Description
I have a workflow that processes a stream of objects that implement an
interface. The primary implementation was not a POJO and worked fine.
When I added an implementation that was a POJO, the workflow fails with
an error of Input mismatch; namely our POJO does not match the interface.
The exception is thrown in TypeExtractor#validateInfo when the type it
checks is an instanceof PojoTypeInfo (line 1456). When the object is
not a POJO, it is GenericTypeInfo (line 1476) and passes this validation.
The difference between these two handling blocks is the POJO test is
testing that the typeInfo's type class is the same as the class of the
type desired by the next step in the workflow. The Generic block tests
that the class of the type is assignable from the typeInfo's type class.
Attached is a JUnit5 test that illustrates the issue. The testPojo()
test will fail as written and indicates the mismatch of FooPojo and Foo.
I believe that changing the block for the PojoTypeInfo to act like the
GenericTypeInfo block would fix this but I don't know if there is a
specific reason to treat POJOs differently here. (For example, if the
Foo array in the test is changed to FooPojo[], then there is a compile
time argument mismatch: TestMapFunction cannot be converted to
MapFunction<FooPojo,R>.)
Workarounds:
1. Avoid POJOs when using interfaces as part of the steps of the workflow.
2. Modify the map function to be a generic class with T extends Foo:
TestMapFunction<T extends Foo> implements MapFunction<T, String>