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 <hedh...@gmail.com> 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" <sandor.nemeth.1...@gmail.com> > 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 <nic...@hedhman.org> 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 > > > > > >
