ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: ClientConnectionConfiguration properties refactoring.
Date Wed, 04 Feb 2015 12:52:48 GMT
One more point here.

Currently we have flag *IgniteConfiguration.restEnabled* which is
deprecated and it is advised to use
*IgniteConfiguration.clientConnectionConfiguration* instead.
I want to remove this flag. But the problem is that this flag is set to
"true" by default. Therefore, if I remove it, I will have to set default
value for "clientConnectionConfiguration" to "new
ClientConnectionConfiguration()" to keep REST enabled by default as
earlier. And if you want to disable REST, he will have to
"IgniteConfiguration.setClientConnectionConfigration(null)", what looks
counterintuitive.

So I think it is better to keep this flag in configuration and remove
deprecatino from it.

Any thoughts?

On Wed, Feb 4, 2015 at 12:40 PM, Yakov Zhdanov <yzhdanov@gridgain.com>
wrote:

> Agree. Just pay attention to abbreviations - message -> msg, count -> cnt,
> etc.
>
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2015-02-04 12:27 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
>
> > Folks,
> >
> > Currently "o.a.i.c.ClientConnectionConfiguration" class has lots of
> > properties and we have a plan to review/refactor them.
> >
> > Here is my proposal on that:
> > 1) Almost all properties have "rest" and "tcp" in their names. Let's
> remove
> > these prefixes altogether. E.g.: "restTcpSelectorCount" ->
> "selectorCount".
> > 2) Rename "clientMessageInterceptor" to "messageInterceptor"
> > 3) Remove "restAccessibleFolders" and corresponding client "LOG" command.
> > 4) Remove all mirrored (and already deprecated) properties from
> > IgniteConfiguration as backward compatibility is not a concern for
> initial
> > release.
> >
> > It appears that none other properties can be removed from this class
> > because Memcached client use binary protocol and may potentially need any
> > of them.
> >
> > Any comments?
> >
> > Vladimir.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message