I think you are asking for what is already being worked on... https://www.youtube.com/watch?v=PmgF7X6ZgIU
Or? Niclas On Sun, Aug 28, 2016 at 3:04 PM, Nemeth Sandor <[email protected] > wrote: > Hi Niclas, > > thanks for clarifying a bit how Configuration works. So if I understand > right, Zest uses the same mechanism (EntityStore) to store both persistent > data and configuration, right? > > As for the "auto-configuration" I think I stuck a bit with the Spring > naming (too long exposure to Spring usage :) ). What I wanted to say that > if Zest wants to offer the same convenience level, as Spring Boot, it would > be nice to have an (in Zest-terms) AutoAssembler, which assembles the > application based on the included components. > > For example when I include the "entitystore-mongodb" dependency into the > application, the ApplicationAssembler could pick up the dependency using > the "MongoDBAutoAssembler", and build it into the application as a new > Module. It can happen that to achieve this, a new ApplicationAssembler is > needed with some default layering. > > So the "auto-configuration" is much more of a convenience method to > auto-assemble the application from the provided dependencies, without > manually writing any assembly. Also for the "sensible defaults": I would > say that's already implemented in e.g. the MongoMapEntityStoreMixin: > > int port = config.port().get() == null ? 27017 : config.port().get(); > > So that functionality is already there, which is very nice :) > > Best regards, > Sandor > > > On Tue, 23 Aug 2016 at 01:55 Niclas Hedhman <[email protected]> wrote: > >> Nemeth, >> Welcome to the world of Zest. >> >> There is a lot of goodies in your mail, and I agree with a lot of what you >> said. >> >> As for Configuration, what Zest provides out if the box is; >> >> 1. Configuration is an Entity that can be stored, and modified in runtime. >> >> 2. If no Entity is found in the Entity Store (for config), it tries to >> create one from a properties file (your sensible defaults). >> >> 3. Services are expected to do refresh() on the Configuration composite, >> which will reload. >> >> 4. Since implementing an entity store is relatively easy, we are only >> lacking particular implementations. >> >> Finally, there is no "chaining" of stores, which could be used for >> override >> mechanism. So, relatively little effort is needed in your first item. :-) >> >> For auto-configure, I am not sure what you are trying to say. Perhaps you >> are only expressing a need that is more or less already fulfilled with the >> ConfigurationComposite functionality in Zest. >> >> But at "clouding tools" I think you are bringing up new functionality in >> Core.... >> >> Currently, the @Service fulfilment is done inside the Zest Core, but >> perhaps that should be broken out as an SPI (even for the current >> default). >> If we follow the normal way to define an SPI, it would simply be a Service >> that implements something like ServiceProvider interface, but then the >> question is, how is that service being provided for, so a bit of >> chicken-egg problem, but probably doable with a fallback implementation. >> >> The services abstraction already support another highly needed feature in >> remote service scenarios, Availability. What we should add for that is >> CAP-theorem declaration, which would match the need of the client with the >> capability of the service. >> >> And finally, "asynchronous" is a big thing in modern systems, so perhaps a >> new type of abstraction is needed for asynchronous request/response >> pattern >> of services. That is probably a large new feature that should be discussed >> separately... >> >> Cheers >> Niclas >> >> On Aug 22, 2016 15:26, "Nemeth Sandor" <[email protected]> >> wrote: >> >> > Hello Niclas, >> > >> > I would say that Zest do not fit into the Spring world, I think the >> > conceptual gap between the two worlds are way too big. I mean Zest >> doesn't >> > support e.g. POJOs, also provides a different dependency-injection >> method. >> > One could probably force a Spring+Zest combination to work, but it would >> > never be a perfect match. >> > >> > However from my POV it should be possible for Zest to offer the same >> > convenience-level, along with the tooling support. >> > This would have 3 different aspects: >> > >> > 1) configuration management >> > 2) auto-configuration support >> > 3) Cloud tooling >> > >> > Below a description follows, although I am not _that_ familiar with the >> > Zest internals at the moment, so please correct me if I am wrong at any >> > point. >> > >> > The *configuration management* would include providing a concept of >> > configuration override with an ordering, supporting external key-value >> > stores for loading configuration (with reload support). I would propose >> the >> > following order: >> > >> > - External K/V store (etcd, Consul, Spring Cloud Config Server, etc) >> > - Environment variables >> > - External configuration files (outside of the application) >> > - Internal configuration files (packaged with the application) >> > >> > The *auto-configuration* support is a bit tricky from my perspective, >> > because usually one wants to provide default settings which make sense, >> but >> > provide an override capability. I could imagine having something like an >> > _AutoConfiguringApplicationAssembler_ which auto-discovers and >> assembles >> > an >> > application (using Java SPI) but then the user could override it in the >> > _assemble_ method. >> > >> > For the *cloud tooling* Zest could provide a unified service-discovery >> > support for different service-discovery providers, and then provide >> support >> > for different service discovery and load-balancing methods (e.g >> client-side >> > load balancing or 3rd party API gateway). >> > >> > Best regards, >> > Sandor >> > >> > On Wed, 17 Aug 2016 at 03:01 Niclas Hedhman <[email protected]> wrote: >> > >> > > Those who know me well, are well-aware of my generally negative >> opinion >> > > about Spring framework, as it has created more mess in software than >> what >> > > is reasonable for such a framework. >> > > >> > > BUT, I am not stuck about it, and I want to highlight something that >> > looks >> > > really, really cool.... http://start.spring.io >> > > >> > > Also take a look at a frantic presentation by Josh Long about it; >> > > https://www.youtube.com/watch?v=sOP3x6ODQWQ >> > > >> > > With that in your minds, How does Zest fit into that world? >> > > >> > > Cheers >> > > Niclas >> > > >> > >> > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
