Comments (8)
somewhat busy today
from avaje-config.
How do I do the above without reacting to every single property change?
my first thought is something similar to the one below.
// register
config.onChange(
"reload",
s -> {
// reload configs here
});
// set props
config.setProperty("key", "val");
config.setProperty("key2", "val");
// fire reload event
config.setProperty("reload", "amogus");
Would this work out for your example?
from avaje-config.
That is an interesting imaginative hack. It seems a little dirty but other than threading issues it probably would work. It is sort of the other option I was going to propose of a "flush" method.
If that is a solution we should fix property loading so that order in the file is maintained.
I think like here:
Here is some code again from our code base that maintains property order. I highly recommend you guys consider doing something similar:
static Properties prepareProperties(
BiConsumer<String, String> consumer)
throws IOException {
// Hack to use properties class to load but our map for preserved order
@SuppressWarnings("serial")
@NonNullByDefault({})
Properties bp = new Properties() {
@Override
public Object put(
@Nullable Object key,
@Nullable Object value) {
if (key != null && value != null) {
consumer.accept((String) key, (String) value);
}
return null;
}
};
return bp;
}
public static void readProperties(
Reader reader,
BiConsumer<String, String> consumer)
throws IOException {
@NonNullByDefault({})
Properties bp = prepareProperties(consumer);
bp.load(reader);
}
It still feels wrong though to depend on the order of properties for a proper event batching but I suppose it would work.
from avaje-config.
but hopefully you get the idea.
Yes, I like it.
With the update(boolean) ... what is a use case where that is not set to true? Where the is put() but update is false?
from avaje-config.
as well as combined the "change request" with the downstream event
Yeah, we'd want them to be separate, perhaps more like:
// event builder / publisher always works on a snapshot
Configuration configuration = ...;
eb = configuration.eventBuilder();
// optional description of the event
eb.description("TheReasonImDoingThis");
// or ... if we must provide a description of the event
eb = configuration.eventBuilder(string description);
// mutation only methods as user has access to configuration for reading properties
eb.put("foo", "bar");
eb.put("another", "one");
eb.remove("banana");
// ?? update true by default, when is this ever false?
eb.update(false);
eb.publish();
interface Event {
Optional<String> description(); // maybe not optional
Configuration configuration();
Set<String> modifiedKeys();
// Set<String> removedKeys(); // probably don't need this
}
configuration.onChange(Consumer<Event> listener)
// if only interested in specific properties
configuration.onChange(Consumer<Event> listener, String... onlyKeysImInterestedIn)
Edit: rather than event description maybe event name.
configuration.event(name) // eventBuilder
.put("foo", "42").put("bar", "hi").remove("junk")
.publish();
interface Event {
String name();
Configuration configuration();
Set<String> modifiedKeys();
}
Edit: EventBuilder ...
interface EventBuilder {
EventBuilder put(String key, String value);
EventBuilder remove(String key);
// I'm wanting to leave this out? when is this ever going to be false?
// EventBuilder update(boolean update);
void publish();
}
from avaje-config.
Would this work out for your example?
I think we need to be prepared to change [the concept used in avaje-config] from 'per single property change' to the 'bulk/batch property changes'
... and I think the API should closely reflect that concept.
That means the existing setProperty(), clearProperty(), onChange( ... single property ...)
methods no longer match the concept. It's likely we'd regret not deprecating and removing them altogether.
Edit: Design like they are already gone and then at the end see if they can be deprecated or we just suck up a breaking api change. Which imo we could because I feel the amount of use of setProperty() onChange() is way way less than all the get() reading properties part of the api. My gut says lets do a breaking api change here.
from avaje-config.
Put a comment in here if someone is working on a PR for this ... I'll look to pick it up later if someone else hasn't already started and if I do I'll put a comment in here.
from avaje-config.
I can do it but it would have to be in two weeks (have child with school vacation). I might be able to get some informal changes in on Friday.
from avaje-config.
Related Issues (20)
- ENH: Add Configuration.evalModify() ... to perform evaluation of expressions that modify properties in place
- Use AppLog.getLogger() rather than System.getLogger() to allow customization
- Remove the warning log messages when yml file extension is used rather than yaml
- Change so that properties via command line arguments is ALWAYS read (it wasn't when test resources detected)
- load.properties parameter should load from jar resources HOT 5
- loading from .localdev supports .yaml but not .yml (Add support for .yml with .localdev configuration)
- Maven Plugin Feature (and some other features). HOT 28
- SPI for initialization HOT 46
- Change from System.Logger to use events and control how those events are logged. HOT 2
- Document or fix hard dependency on avaje-inject when using module-path HOT 15
- Interpolation doesn't work in the same resource file.
- Multi-Profile support
- Make a Parser interface
- Support TOML? HOT 5
- Load configuration from a specific file - is it possible? HOT 14
- Extracting property source. HOT 6
- Inconsistency with builder and initial loader. Default resource loader does not use the System class loader? HOT 19
- Use UncheckedIOException rather than IllegalStateException for consistency HOT 4
- Potential NPE in CoreConfigurationBuilder HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from avaje-config.