Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
References: <CADmm+Ked=5T-WoFiMp3Agv62kq7fOomGYUO6OCSz67_ZjMnhew@mail.gmail.com>
 <CADmm+Kcoi_DKqn9ZHNxgj_TdvwhsKRjS7Qob6D6Fw8J9pBH5Gw@mail.gmail.com>
 <CADmm+Ke4LpNiwTMPW5==9N2yxcQ35Beto5ggmgkjSd4YFCaARg@mail.gmail.com>
 <CADmm+Kc01XRdEZSqAyRARhdkbJJh4rLxSExqS18y+8RrUkCK2g@mail.gmail.com>
 <CADmm+Kcf7g2OPmf0F9nB8A70rcZV9KVmdEibrTyt-5bNhG0qQg@mail.gmail.com>
 <CADmm+KezPv5NHaPTVCfAPcZQ3PkpBBKN-Q4mjemYYkGFVu6UOg@mail.gmail.com>
 <CADmm+Kd2=G_C0H01GFTYuLdEmmGFWB1LfYh-Eyi+73vyMqZ3uw@mail.gmail.com>
 <CADmm+KfD6vOcxUaWSBeNq8oU7E4XGHh-Q3SSYBRidUSdYn0p8g@mail.gmail.com>
 <CAGxfHu=7M0Aiqx4+cLna0OEDSQCo-z=hh688aeSFw+43DcxCiA@mail.gmail.com> <CADmm+Kcqw978eVmyJEoK6vd16r205a388rh14pUahkkpXq=SPA@mail.gmail.com>
In-Reply-To: <CADmm+Kcqw978eVmyJEoK6vd16r205a388rh14pUahkkpXq=SPA@mail.gmail.com>
From: Nemeth Sandor <sandor.nemeth.1986@gmail.com>
Date: Sun, 28 Aug 2016 07:04:56 +0000
Message-ID: <CAGxfHunJF1cUdtixzD6OtEXVvJgB_nqqs8tKLwuZFJHf30pP8w@mail.gmail.com>
Subject: Re: Spring
To: niclas@hedhman.org, dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a113d3eae1ca644053b1c5e30
archived-at: Sun, 28 Aug 2016 07:05:14 -0000

--001a113d3eae1ca644053b1c5e30
Content-Type: text/plain; charset=UTF-8

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 <hedhman@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.1986@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 <niclas@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
> > >
> >
>

--001a113d3eae1ca644053b1c5e30--