IGNITE-10075 .NET: Avoid binary configurations of Ignite Java service params

[nizhikov]

This PR contains changes to avoid explicit type registration while call java service from .Net.
The type will be automatically registered if FQN equals for .Net type and for Java companion.

The Contribution Checklist

• There is a single JIRA ticket related to the pull request.
• The web-link to the pull request is attached to the JIRA ticket.
• The JIRA ticket has the Patch Available state.
• The pull request body describes changes that have been made.
  The description explains WHAT and WHY was made instead of HOW.
• The pull request title is treated as the final commit message.
  The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
• A reviewer has been mentioned through the JIRA comments
  (see the Maintainers list)
• The pull request has been checked by the Teamcity Bot and
  the green visa attached to the JIRA ticket (see TC.Bot: Check PR)

Notes

• How to Contribute
• Coding abbreviation rules
• Coding Guidelines
• Apache Ignite Teamcity Bot

If you need any help, please email [email protected] or ask anу advice on http://asf.slack.com #ignite channel.

[ptupitsyn]

Changes look good to me in general - please see a couple comments.

However, this seems to cover a very rare use case when Java and .NET full type names match. Naming conventions are different, so a user has to go out of their way to break them. Are we sure that this is useful?

[nizhikov]

Are we sure that this is useful?

I and @kukushal have a request for a feature from one of the Ignite users that building an application that uses Java services from the DotNet platform.

[nizhikov]

Hello, @ptupitsyn

I've reworked this patch.
After some discussion with @kukushal I came to the decision that the initial patch (searching java type with .net name during deserialization) is bad.
Because we enhance global logic but not the logic that relates to the .net -> java service execution.

So I changed the algorithm to the following: during .net -> java service execution we register a new binary type both for java and .net platforms. We expect that there is java analog for each .Net type.

What do you think?
Can you, please, review the patch one more time.

[ptupitsyn]

The idea of registerSameJavaType is fine with me. I agree that it is a better solution.

I think we should simplify the implementation - instead of passing the flag around in all those places, use a thread local flag in Marshaller, then in ServiceProxySerializer.WriteProxyMethod do something like

try
{
    writer.Marshaller.RegisterSameJavaTypes = true;
    // Write args
}
finally
{
    writer.Marshaller.RegisterSameJavaTypes = false;
}

[nizhikov]

@ptupitsyn

use a thread local flag in Marshaller

Implemented as suggested.
Please, take a look one more time.

[ptupitsyn]

@nizhikov thanks, one more adjustment please:

I think it is a bit cleaner to pass the thread local flag as a parameter to the IBinaryProcessor.RegisterType, which is called from a single place in Marshaller. That way we reduce the global state usage.

[nizhikov]

I think it is a bit cleaner to pass the thread local flag as a parameter to the IBinaryProcessor.RegisterType

done.

[ptupitsyn]

Looks good to me, thanks!