Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <CAGxfHunJF1cUdtixzD6OtEXVvJgB_nqqs8tKLwuZFJHf30pP8w@mail.gmail.com>
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> <CAGxfHunJF1cUdtixzD6OtEXVvJgB_nqqs8tKLwuZFJHf30pP8w@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Sun, 28 Aug 2016 20:04:40 +0800
Message-ID: <CADmm+KevLF2=jpZuqkJ1gwXx_wmifsT3HD0_kou93BUJ9jT+aw@mail.gmail.com>
Subject: Re: Spring
To: Nemeth Sandor <sandor.nemeth.1986@gmail.com>
Cc: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a1141c9f896ddcc053b208eb2
archived-at: Sun, 28 Aug 2016 12:05:06 -0000

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

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 <sandor.nemeth.1986@gmail.com
> 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 <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
>> > >
>> >
>>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--001a1141c9f896ddcc053b208eb2--