Nikolay,
As I understand, you insist on changing the default behavior, is this
correct?
On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov <nizhi...@apache.org> wrote:
> Hello, Igor, Pavel.
>
> Thanks for the feedback
>
> > Agree with Pavel, this should be disabled by default.
>
> Right now, Ignite, by default, forcing users to enlist every single value
> object they have in project in the config.
> Do you think it’s a right way to go?
>
> > To me it looks pretty dangerous as users do not explicitly control
> what’s going to be registered and it could lead to hard-to-debug mistakes
> when wrong classes get registered or with wrong names.
>
> Approach with transparent type registration implemented in every RPC
> framework I know.
> I think user expect it from the modern software.
> Can you, please, highlight dangerous part of the approach?
>
> > Wouldn't
> > it be more reasonable to only register those which are used with Java
> > services?
>
> Correct. Will do it.
>
> > Registering every .NET type as a Java type can lead to typeId collisions
> and break existing user code,
>
> For Service and Compute API binary type registration both in Java and .Net
> will happen anyway.
> It’s required just to get things work.
>
> > 12 янв. 2021 г., в 20:31, Igor Sapego <isap...@apache.org> написал(а):
> >
> > Agree with Pavel, this should be disabled by default.
> >
> > To me it looks pretty dangerous as users do not explicitly control what's
> > going to be
> > registered and it could lead to hard-to-debug mistakes when wrong classes
> > get
> > registered or with wrong names. Also it can be hard to use with classes
> > that should
> > not be registered at all, which is often the case because not everyone
> use
> > .NET client
> > with Java services.
> >
> > To me it looks familiar to another of our features - peer class loading,
> > which is disabled
> > by default for similar reasons.
> >
> > Also, why register types which are used as method arguments for any
> > service? Wouldn't
> > it be more reasonable to only register those which are used with Java
> > services?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Jan 12, 2021 at 7:35 PM Pavel Tupitsyn <ptupit...@apache.org>
> wrote:
> >
> >> Nikolay,
> >>
> >> I think this behavior should be opt-in - let's add a flag to
> >> BinaryConfiguration.
> >> Registering every .NET type as a Java type can lead to typeId collisions
> >> and break existing user code,
> >> so we can't enable this by default.
> >>
> >>
> >> Ignite stores typeId -> className mappings separately for Java and .NET
> >> [1].
> >> Separate maps were introduced because C# and Java have different naming
> >> conventions,
> >> typically you have org.foo.bar.Person in Java and Foo.Bar.Person in
> .NET,
> >> so we allow the users to map two different type names to the same typeId
> >> with a custom name or id mapper.
> >>
> >> This proposal says we should always put Foo.Bar.Person from .NET to the
> >> Java mapping,
> >> in the hope that there is a class with that name in Java, which is a
> very
> >> rare use case.
> >>
> >> [1]
> >> org.apache.ignite.internal.MarshallerContextImpl#registerClassName(byte,
> >> int, java.lang.String, boolean)
> >>
> >> On Tue, Jan 12, 2021 at 4:56 PM Nikolay Izhikov <nizhi...@apache.org>
> >> wrote:
> >>
> >>> Hello, Igniters.
> >>>
> >>> Currently, in case of usage .Net platform client it’s required for the
> >>> user to explicitly register each custom type.
> >>>
> >>> ```
> >>> _marsh = new Marshaller(new BinaryConfiguration
> >>> {
> >>> TypeConfigurations = new List<BinaryTypeConfiguration>
> >>> {
> >>> new BinaryTypeConfiguration(typeof (Address)),
> >>> new BinaryTypeConfiguration(typeof (TestModel))
> >>> }
> >>> });
> >>> ```
> >>>
> >>> Note, we have a special public interface to map java type to .net
> types -
> >>> `IBinaryNameMapper`
> >>>
> >>> ```
> >>> public interface IBinaryNameMapper
> >>> {
> >>> string GetTypeName(string name);
> >>> string GetFieldName(string name);
> >>> }
> >>> }
> >>> ```
> >>>
> >>> Users found this approach annoying and not convenient.
> >>> So, recently we made a several improvements for the Service API to
> >>> implicitly register each custom type from service method arguments.
> [1],
> >>> [2], [3]
> >>> For now, user can just call Java service from .Net without any
> additional
> >>> configuration in case FQN NameMapper used.
> >>>
> >>> I propose to extends approach with the implicit binary type
> registration
> >>> to all APIs and prepare PR for it [4].
> >>>
> >>> What do you think?
> >>>
> >>> [1]
> >>>
> >>
> https://github.com/apache/ignite/commit/35f551c023a12b3570d65c803d10c89480f7d5e4
> >>> [2]
> >>>
> >>
> https://github.com/apache/ignite/commit/6d02e32e7f049e4f78f7abd37f4ff91d77f738c2
> >>> [3]
> >>>
> >>
> https://github.com/apache/ignite/commit/c2204cda29e70294cc93756eabc844b64e07a42e
> >>> [4] https://github.com/apache/ignite/pull/8635
> >>
>
>
