Any reason to keep ClientConfiguration final?

[dmagda]

@Pavel Tupitsyn <[hidden email]>, @Igor Sapego <[hidden email]>,

Michael has been integrating Ignite with Micronaut and we hit some
limitations related to the configuration. To simplify the configuration of
the thin client instances, we need to inherit from the ClientConfiguration
class
<https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java>
but
the class is made final.

Is any good reason for keeping its final? Otherwise, I'll go ahead and
remove that modifier.


-
Denis

[Pavel Tupitsyn]

Denis,

No objections to the removal of the "final" modifier from my side.
However, the use case sounds a bit weird to me, can you please describe it
in more detail?

Thanks,
Pavel

On Mon, Aug 24, 2020 at 10:47 PM Denis Magda <[hidden email]> wrote:

> @Pavel Tupitsyn <[hidden email]>, @Igor Sapego <[hidden email]>,
>
> Michael has been integrating Ignite with Micronaut and we hit some
> limitations related to the configuration. To simplify the configuration of
> the thin client instances, we need to inherit from the ClientConfiguration
> class
> <https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java> but
> the class is made final.
>
> Is any good reason for keeping its final? Otherwise, I'll go ahead and
> remove that modifier.
>
>
> -
> Denis
>

[Igor Sapego-2]

No objections from my side.

What is the case? Some kind of new thin client?

Best Regards,
Igor


On Mon, Aug 24, 2020 at 11:40 PM Pavel Tupitsyn <[hidden email]>
wrote:

> Denis,
>
> No objections to the removal of the "final" modifier from my side.
> However, the use case sounds a bit weird to me, can you please describe it
> in more detail?
>
> Thanks,
> Pavel
>
> On Mon, Aug 24, 2020 at 10:47 PM Denis Magda <[hidden email]> wrote:
>
>> @Pavel Tupitsyn <[hidden email]>, @Igor Sapego <[hidden email]>
>> ,
>>
>> Michael has been integrating Ignite with Micronaut and we hit some
>> limitations related to the configuration. To simplify the configuration of
>> the thin client instances, we need to inherit from the ClientConfiguration
>> class
>> <https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java> but
>> the class is made final.
>>
>> Is any good reason for keeping its final? Otherwise, I'll go ahead and
>> remove that modifier.
>>
>>
>> -
>> Denis
>>
>

[Michael Pollind]

micronaut setups the configuration at compile time. so a lot of the
configuration is through annotating classes. There are two main methods for
this ConfigurationProperties/ConfigurationBuilder. ConfigurationBuilder
maps properties to a factor and ConfigurationProperties maps properties
onto a class object. It's the difference between wrapping a class and
extending it. You can see the differences by looking at these two items
listed below and the sample code that creates the thin client. It's more
useful just to inject the configuration vs having to unwrap the bean.
Hopefully this helps clarify things. The code is just a bit more clumsy
using a wrapping class this way, but it's not too bad from my perspective.


Thin Client:
https://github.com/micronaut-projects/micronaut-ignite/blob/7c767288f540f5ae6dd0479252db9a1c5072d120/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteThinClientConfiguration.java
Thick Client:
https://github.com/micronaut-projects/micronaut-ignite/blob/7c767288f540f5ae6dd0479252db9a1c5072d120/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java

...

/**
 * Ignite {@link ClientConfiguration}.
 * @param clientConfiguration client configuration
 * @return client configuration
 */
@Bean
@Named("default")
@Primary
@Requires(beans = DefaultIgniteThinClientConfiguration.class)
public ClientConfiguration igniteClientConfiguration(@IgnitePrimary
DefaultIgniteThinClientConfiguration clientConfiguration) {
    return clientConfiguration.getConfiguration();
}

/**
 *
 * @param configuration client configuration
 * @return Ignite Thin client
 */
@EachBean(ClientConfiguration.class)
@Singleton
@Bean(preDestroy = "close")
public IgniteClient igniteThinClient(ClientConfiguration configuration) {
    try {
        return Ignition.startClient(configuration);
    } catch (Exception e) {
        LOG.error("Failed to instantiate Ignite Client: " + e.getMessage(), e);
        throw e;
    }
}
...


--
Michael Pollind

On Mon, Aug 24, 2020 at 1:43 PM Igor Sapego <[hidden email]> wrote:

> No objections from my side.
>
> What is the case? Some kind of new thin client?
>
> Best Regards,
> Igor
>
>
> On Mon, Aug 24, 2020 at 11:40 PM Pavel Tupitsyn <[hidden email]>
> wrote:
>
>> Denis,
>>
>> No objections to the removal of the "final" modifier from my side.
>> However, the use case sounds a bit weird to me, can you please describe
>> it in more detail?
>>
>> Thanks,
>> Pavel
>>
>> On Mon, Aug 24, 2020 at 10:47 PM Denis Magda <[hidden email]> wrote:
>>
>>> @Pavel Tupitsyn <[hidden email]>, @Igor Sapego
>>> <[hidden email]>,
>>>
>>> Michael has been integrating Ignite with Micronaut and we hit some
>>> limitations related to the configuration. To simplify the configuration of
>>> the thin client instances, we need to inherit from the ClientConfiguration
>>> class
>>> <https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/ClientConfiguration.java> but
>>> the class is made final.
>>>
>>> Is any good reason for keeping its final? Otherwise, I'll go ahead and
>>> remove that modifier.
>>>
>>>
>>> -
>>> Denis
>>>
>>