[jira] [Commented] (REEF-50) Creating driver config for .Net clients

["Markus Weimer (JIRA)" <ji...@apache.org>]

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

Markus Weimer commented on REEF-50:
-----------------------------------

I took the liberty of formatting the issue text. Most of the above affects the C# code, which we won't be able to really discuss here until [REEF-51] is resolved. Hence, I suggest to create two sub-issues for this.

  # The needed changes to the java side, including the build. We will have to augment our builds such that they create the skeleton driver configuration for the Java side of a .NET/Java hybrid Driver (see [REEF-51] for a description of that).
  # The proposed API for the C# side of the house.

That way, we can continue work on the first issue, while clearly marking the second one as blocked by [REEF-51].

> Creating driver config for .Net clients 
> ----------------------------------------
>
>                 Key: REEF-50
>                 URL: https://issues.apache.org/jira/browse/REEF-50
>             Project: REEF
>          Issue Type: Improvement
>            Reporter: Julia
>            Assignee: Julia
>
> h3. Issue description
> Currently, for .Net clients to submit a job through REST API, they have to write C# client, and launch Java bridge client to generate driver.config with clr arguments. It requires .NET clients to have java installed at their machine and run java program. We are looking for a solution that can generate driver.config using C# without involve java code from client side. 
> h3. Proposed solution
>   # Create javadriver.config with java bridge Launch and JobClient without C# arguments in the configuration
>   # Serialize java class hierarchy and save it into a file
>   # Write a C# tool for C# client to generate driver.config 
>   ## Deserialize javadriver.config with java class hierarchy
>   ## Bind clr arguments such as memory, submission directory, globalfiles, etc to the deserialized Configuration
>   ## Serialize the new configuration into driver.config
>   # That’s it! Client just needs to run the tool with his clr arguments, he will get driver.config for him to submit the job with rest API. 
> h3. Notes
>   # Most java JobClient classes, handlers, configuration settings are relatively stable. We can modify the bridge JobClient little bit (use a flag for example) to generate  javadriver.config without CLR config data. This javadriver.config can be shipped as part of the NuGet. If we change any classes in java bridge JobClient at development time, we need to regenerate this javadriver.config  file and the java class hierarchy, and package them into the NuGet.
>   # Most of the CLR parameters are optional in driver config. We can leave them unbind at Java side. Then bind them at .Net side. The only one is DRIVER_IDENTIFIER that is a required parameter. One possible way is to change it to optional. In the C# tool, if client doesn’t supply it, we can assign a default value to it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)