You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "James Morgan (JIRA)" <ji...@apache.org> on 2018/09/06 19:16:00 UTC

[jira] [Created] (FLINK-10296) TypeExtractor only validates/matches exact POJO classes

James Morgan created FLINK-10296:
------------------------------------

             Summary: TypeExtractor only validates/matches exact POJO classes
                 Key: FLINK-10296
                 URL: https://issues.apache.org/jira/browse/FLINK-10296
             Project: Flink
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.6.0, 1.5.1
            Reporter: James Morgan
         Attachments: PojoTest.java

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>



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)