You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Kenneth Knowles (JIRA)" <ji...@apache.org> on 2018/10/01 22:51:00 UTC

[jira] [Commented] (BEAM-5526) Make ByteBuddyDoFnInvokerFactory injection strategy configurable + drop the singleton

    [ https://issues.apache.org/jira/browse/BEAM-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634733#comment-16634733 ] 

Kenneth Knowles commented on BEAM-5526:
---------------------------------------

[~romain.manni-bucau] you've marked this as a "blocker" priority. It is an implementation detail. {{DoFnInvoker}} and {{DoFnInvokerFactory}} are not user-facing APIs. The reason there is an interface is due to good practice (see Parnas https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf). You should put an interface in place when a significant decision is made, even if there is only one implementation. Here, the interface is around the decision of what library to use, just like you say.

It is kind of a cool idea to implement some other DoFnInvoker factories for users, but then if the pipeline fails it is a user bug, not a Beam bug. That might get confusing. Have you opened this idea on the dev list?

> Make ByteBuddyDoFnInvokerFactory injection strategy configurable + drop the singleton
> -------------------------------------------------------------------------------------
>
>                 Key: BEAM-5526
>                 URL: https://issues.apache.org/jira/browse/BEAM-5526
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-java-core
>            Reporter: Romain Manni-Bucau
>            Assignee: Kenneth Knowles
>            Priority: Blocker
>
> org.apache.beam.sdk.transforms.reflect.DoFnInvokers + DoFnInvokerFactory design is to be a SPI to let user plug their own bytecode manipulation library, however in practise beam uses ByteBuddyDoFnInvokerFactory as a singleton which makes all this design useless.
> ByteBuddyDoFnInvokerFactory is also not configurable at all - typically the injection strategy so it assumes it runs in an environment and on a JVM where it will work - it does not on java 11 for instance.
> This ticket is about fixing all these small inconsistency and blocker to tun on java 11.



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