I was doing something similar to that for some other projects and found
that cfg4j [1] to be a very clean and good framework to keep the format of
the configuration generic and dynamic. Built-in support for Yaml and
property files and can also ready from multiple sources like Git, Consul,
classpat
One thing also to consider if you modifying the config structure, is an evented
config structure, so that registrants get callbacks if changes are made that
are real-time.
Thanks,
Mark
> On Oct 5, 2017, at 12:49 PM, Galen O'Sullivan wrote:
>
> I don't care too much about exactly what the confi
I don't care too much about exactly what the configuration looks like, but
I want it to be unified, and I want it to be set when the cache starts.
Checking system properties throughout the codebase whenever we feel like is
a bit too magic for me.
In addition, it seems that in order to add a new va
*Properties* are simple (think *Spring Boot; *there is no better example);
YAML provides structure (with IDE support);
*Type-Safety* is the responsibility of the framework/API (think the
configuration format really should not matter, but data-binding/conversion
is always a concern regardless of t
As a geode admin setting up the cluster with security, I don't want to
worry about what version of protocol the client is going to use.
+1 for the new protocol to just use existing properties.
On Mon, Oct 2, 2017 at 1:24 PM Dan Smith wrote:
> I realized I've been assuming you were asking about t
I realized I've been assuming you were asking about turning on ssl
authentication. Maybe you are talking about authenticating with the
security manager. Either way, what Anthony said still applies - the
new protocol should just use the existing properties (security-manager
in that case).
-Dan
On
Yes to API first, config file second! Config file should reflect the API
and domain objects.
But... How can you even begin go argue properties over XML? Configuration
should be well structured and expressive. Properties is neither.
Properties can't handle collections of things without some serio
I don't mean to derail the topic at hand, but...
On the same vain as Properties, can we also stop talking about XML? I much
prefer Properties over XML any day, especially given YAML. However, that
does not imply Properties should be added at will. Properties also
increase the "surface area" of
Seriously? Stop with properties already. There are so many better ways to
do configuration. We already have strong APIs for setting up the server as
well as XML which nearly correlates with the API. In fact the XML and API
should be merged together better. Think spring!
For configuration of the ne
One thing to think about - if the new protocol doesn't support two-way
authentication maybe we should throw an exception if the user sets
ssl-require-authentication=true? We definitely don't want to lie to
the user and pretend that we are providing some level of security
which we are not.
I'm assu
Is there a need for property yet?
The authentication-enabled question could be answered from the existing
security properties. That ensures consistency and means a user would only need
to set a single switch.
If we only support a single authentication mode, we can defer adding
configration un
Security configuration for this new protocol should should be done in
a way that is consistent with existing SSL related properties. See
https://geode.apache.org/docs/guide/12/managing/security/implementing_ssl.html.
In this case, maybe this new protocol should be use the same
configuration as the
12 matches
Mail list logo
