[
https://issues.apache.org/jira/browse/SAMZA-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933745#comment-15933745
]
Navina Ramesh commented on SAMZA-1137:
--------------------------------------
{quote}at least, the same LocalApplicationRunner should be used to instantiate
the StreamProcessor() and replace the whole SamzaContainer.main() method{quote}
Doesn't this happen today? StreamProcessor should hide everything in
SamzaContainer. It seems to me that we want to inject an instance into the
container and it is not possible to do that with the current StreamProcessor
api. Is that right?
Even if our current implementation is hacky, I think it is crucial that
abstraction layer and their contracts are not overstepped or by-passed. If
ApplicationRunner is responsible for launching the jobs, then it should not be
in the business of generating StreamSpec. To me, that seems like a breach in
contract between the ApplicationRunner and the StreamProcessor. Or perhaps,
ApplicationRunner is too broadly defined in terms of its functionality. Let's
discuss this further.
I think it will be a good idea to document the new architecture (the diagram
illustrating the different components specifically) to well-define the
different contracts. I feel like we are going back-and-forth on certain topics,
simply because everyone has a different interpretation of what our new
architecture is.
> Instantiate ApplicationRunner in SamzaContainer
> -----------------------------------------------
>
> Key: SAMZA-1137
> URL: https://issues.apache.org/jira/browse/SAMZA-1137
> Project: Samza
> Issue Type: Task
> Reporter: Yi Pan (Data Infrastructure)
> Assignee: Xinyu Liu
>
> From the discussion on SAMZA-1122, we will need to create an
> ApplicationRunner in SamzaContainer as well, at least to provide StreamSpecs
> for fluent API.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
