Readit News logoReadit News
jeyjeyemem commented on Show HN: Externalized Properties, a modern Java configuration library   github.com/joel-jeremy/ex... · Posted by u/jeyjeyemem
Bjartr · 12 days ago
Reading section III, I see it specifically calls out the value in avoiding on-disk property files and named per-environment groupings of properties as non-scalable anti-patterns. I don't know whether or not I agree with that, but I am curious why you're claiming to be inspired by that section when, by and large, the only thing that seems to align with what's described in section III is not hardcoding the property values directly in code, which isn't really specific to the twelve factor methodology.
jeyjeyemem · 12 days ago
You can still strictly adhere to section III if you choose to - by only loading the environment variables, but Externalized Properties allows more than that if needed.

By using ExternalizedProperties instead of direct System.getenv() you get other useful features such as automatic conversions, variable expansion, and processing (e.g. automatic decryption/automatic base64 decode, etc)

jeyjeyemem commented on Show HN: Externalized Properties, a modern Java configuration library   github.com/joel-jeremy/ex... · Posted by u/jeyjeyemem
elric · 13 days ago
I use PKL for most of my configuration needs these days. But PKL is only a format, it doesn't say where to store the config. Could I use Externalized Properties to e.g. fetch config from some random source but have it be PKL?
jeyjeyemem · 12 days ago
Definitely! There's no limit on what configuration formats Externalized Properties can support as you can implement custom `Resolver`s to retrieve from any source and format e.g.

    public class PklResolver implements Resolver {
        public Optional<String> resolve(InvocationContext context, String propertyName) {
            return getFromPklConfig(propertyName);
        }
    }


    // Register custom resolver when building ExternalizedProperties

    ExternalizedProperties externalizedProperties = ExternalizedProperties.builder()
        .resolvers(new PklResolver(...))
        .build();

    AppProperties appProperties = externalizedProperties.initialize(AppProperties.class);

    // Resolves config from PklResolver

    String myConfig = appProperties.myConfig();

jeyjeyemem commented on Show HN: Externalized Properties, a modern Java configuration library   github.com/joel-jeremy/ex... · Posted by u/jeyjeyemem
kosolam · 13 days ago
How this compares with other libs and frameworks ?
jeyjeyemem · 12 days ago
It's more performant than other similar libraries such as the Owner and cfg4j which no longer seems to be actively developed at this point and others such as Spring's Environment and MicroProfile config implementations

See benchmarks here: https://github.com/joel-jeremy/java-config-library-benchmark...

Aside from the performance, the other advantage of using this config library is how it makes testing easier and how easy it is to integrate with your dependency injection frameworks of choice.

jeyjeyemem commented on Show HN: Externalized Properties, a modern Java configuration library   github.com/joel-jeremy/ex... · Posted by u/jeyjeyemem
jeyjeyemem · 14 days ago
Externalized Properties was inspired by the The Twelve Factor Methodology's section III. Config.

The goal of this library is to make it easy for applications to implement configuration best practices by providing easy-to-use APIs as well as providing the flexibility to choose where to store their configurations/properties.

Externalized Properties takes full advantage of Java's Dynamic Proxies.

Why Dynamic Proxies?

* Dependency Injection Friendly

Since Externalized Properties works with interfaces, it makes it easy to integrate with dependency injection (DI) frameworks. it's as simple as building ExternalizedProperties, initializing a dynamic proxy from an interface, and registering the proxy interface to your chosen DI framework.

* Testing Friendly

Another side-effect of being dependency injection friendly is that it also makes it easy to mock/stub out configurations/properties on unit tests. It's as simple as creating a stub implementation of the proxy interface or using mocking frameworks to mock the proxy interface.

jeyjeyemem commented on Emissary, a fast open-source Java messaging library   github.com/joel-jeremy/em... · Posted by u/jeyjeyemem
RedShift1 · 16 days ago
I'm a big fan of Guava's EventBus. Easy to implement and straightforward to understand. This library does seem to require more setup and I don't see the immediate advantages, also why does it require an instanceProvider? I don't understand what that does.
jeyjeyemem · 15 days ago
Emissary really shines if performance is a top priority.

The setup is more or less similar, you register a bunch of event handlers when initializing the library. The main difference is that, in addition to events, Emissary also supports "request" messages. Requests enforce the invariant that only one handler should handle it - if there are multiple handlers registered for a given request, Emissary will throw an error. That, and some extension points which is only needed for more advance use cases.

The InstanceProvider allows users to let the dependency injection (DI) framework of their choice instantiate the request/event handler classes (see https://github.com/joel-jeremy/emissary?tab=readme-ov-file#e...). This is in contrast to the way EventBus does it where subscribers need to be instantiated at startup time. By leveraging the DI framework, additional services can be injected to the handler's constructor.

jeyjeyemem commented on Emissary, a fast open-source Java messaging library   github.com/joel-jeremy/em... · Posted by u/jeyjeyemem
throw_away_623 · 15 days ago
Are you planning to add persistent events as well, so that events are not lost due to crashes
jeyjeyemem · 15 days ago
This a frequently requested feature. At the moment, it only handles in-process messages but allowing for persistent events is definitely in the roadmap. It's not built-in right now, but this can be achieved by implementing custom RequestHandlerInvocationStrategy and EventHandlerInvocationStrategy. For example, one can implement an invocation strategy to serialize and send certain events to Kafka, queue, or your DB of choice.

See: https://github.com/joel-jeremy/emissary/blob/main/emissary-c...

Here are the default invocation strategies built-in right now: https://github.com/joel-jeremy/emissary/tree/main/emissary-c...

jeyjeyemem commented on Emissary, a fast open-source Java messaging library   github.com/joel-jeremy/em... · Posted by u/jeyjeyemem
azornathogron · 16 days ago
Assuming that you are the author of Emissary, this could be a Show HN, I think.

https://news.ycombinator.com/showhn.html

jeyjeyemem · 15 days ago
Yes, I am the author. I didn't know that, I'll give it a try. Thank you for the tip!
jeyjeyemem commented on Emissary, a fast open-source Java messaging library   github.com/joel-jeremy/em... · Posted by u/jeyjeyemem
jeyjeyemem · 19 days ago
Emissary is a simple-to-use, no dependency, yet BLAZING FAST messaging library for decoupling messages (requests and events) and message handlers.

Emissary aims to take advantage of the simplicity of using the annotations for handlers (e.g. @RequestHandler/@EventHandler) without the drawbacks of reflection (slow).

What differentiates Emissary from other messaging/dispatch libraries? It takes advantage of java.lang.invoke.LambdaMetafactory to avoid the cost of invoking methods reflectively. This results in performance close to directly invoking the request handler and event handler methods.

~ 1000% more throughput compared to other similar libraries (Spring's ApplicationEventPublisher, Pipelinr, EventBus) ~ 90% faster compared to other similar libraries (Spring's ApplicationEventPublisher, Pipelinr, EventBus)

Benchmarks found on the GitHub repository: https://github.com/joel-jeremy/emissary?tab=readme-ov-file#p...

u/jeyjeyemem

KarmaCake day18January 2, 2018View Original