juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bognar <jamesbog...@apache.org>
Subject Re: Microservice API changes.
Date Sun, 25 Nov 2018 14:59:24 GMT
Hi Marcelo,

If you're interested in developing this, feel free to implement your
own ConfigStores in the org.apache.juneau.config.store package of the
juneau-config project.  Currently we only have ConfigFileStore and
ConfigMemoryStore, but I'd be very interested in seeing something like
a Github store.  That appears to be a common design pattern for
storing configuration files.
On Sun, Nov 25, 2018 at 3:50 AM Marcelo Souza Vieira
<marcelosouzav@gmail.com> wrote:
>
> Hi. Got it. This is very massive.
>
> let me explain the way I use the configuration system. I use a standalone configuration
server with its file store in Github. it follows a pattern. in my application, every time
it goes up, it sends a request to that server, and lowers its settings. hence to indicate
even the branch you want to read. This makes it easy to set up production environment, homologation,
etc.
>
> but it's just a way of working. as I said some things make production much easier, when
many microsservices are being managed.
>
> Marcelo
>
> Em sáb, 24 de nov de 2018 18:17, James Bognar <jamesbognar@apache.org escreveu:
>>
>> One of the interesting features of the Config API is that file storage
>> is only one of the persistence options.
>>
>> The persistence layer itself, ConfigStore, is an interface that can be
>> implemented:
>> http://juneau.apache.org/site/apidocs-7.2.2/overview-summary.html#juneau-config.ConfigStores
>>
>> ConfigFileStore is just the default implementation.
>>
>> I provide an example of how you could store configuration data in a
>> relational database:
>> http://juneau.apache.org/site/apidocs-7.2.2/overview-summary.html#juneau-config.ConfigStores.CustomConfigStores
>>
>> So connecting to an external configuration service would simply mean
>> implementing your own ConfigStore for reading and writing config file
>> contents from wherever you chose.
>>
>> The Config API also has listener APIs for listening for changes at the
>> file, section, or entry level.  What's really cool is that it will
>> properly listen to and merge changes when they occur from both sides.
>> Any modifications you make locally are stored as replayable events.
>> When you call save(), it retrieves the config from the store and
>> compares it with the local contents.  If different, we find the
>> differences and create events for those changes.  After invoking
>> listeners for those changes, we then apply our replayable events on to
>> the new file contents and try to save it again.  We continue this for
>> as long as the remote contents are changing so that it's impossible to
>> lose changes made locally or remotely.
>>
>>
>>
>>
>> On Sat, Nov 24, 2018 at 2:47 PM Marcelo Souza Vieira
>> <marcelosouzav@gmail.com> wrote:
>> >
>> > Hi.
>> > 1+
>> >  It would be interesting to make it possible to use an external configuration
server. It is a standard for microsservice and really makes it much easier when the system
is in production.
>> > I would give Juneau a server and create a server.
>> >
>> > Marcelo
>> >
>> > Em sáb, 24 de nov de 2018 17:37, Steve Blackmon <sblackmon@apache.org escreveu:
>> >>
>> >> +1 this would be useful when adding resources whose configuration may vary
at runtime.
>> >>
>> >> Bonus points if user code can reinitialize the microservice and rerun the
setup step if conditions change
>> >>
>> >> On Sat, Nov 24, 2018, 12:33 PM James Bognar <jamesbognar@apache.org wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> I'm going to do some refactoring in the Microservice APIs.
>> >>>
>> >>> Here are some of the changes I want to make (nothing should be breaking):
>> >>>
>> >>> 1) Add builders for the microservice classes.
>> >>> Something like this:
>> >>> RestMicroservice.create().resources(RootResources.class).port(10000).build().start();
>> >>>
>> >>> 2) Allow the external config file to be entirely optional by allowing
>> >>> you to define settings programmatically via the builder.  Default
>> >>> behavior still uses the config file though.
>> >>>
>> >>> 3) Break up the projects like so:
>> >>>  - juneau-microservice-core - Contains base Microservice class and
>> >>> default console commands.
>> >>>  - juneau-microservice-jetty - Contains RestMicroservice and
>> >>> Jetty-related stuff.
>> >>>  - juneau-microservice-springboot - Contains new microservice code from
Marcelo.
>> >>>  - juneau-microservice-jetty-template - Template project using Jetty.
>> >>>  - juneau-microservice-springboot-template - Template project using
Spring Boot.

Mime
View raw message