You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "John D. Ament" <jo...@apache.org> on 2017/09/20 12:03:58 UTC
Additional Config Sources?
HI All,
I was wondering, would it make sense if we created, perhaps separate from
the core of Geronimo Config (maybe new repo?) a set of reusable Config
Sources based on MP Config? This way if people were planning to use etcd,
consul, zookeeper, archaius (to name a few) we could have a built in, out
of the box solution to support their use cases?
John
Re: Additional Config Sources?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 24 sept. 2017 14:45, "John D. Ament" <jo...@gmail.com> a écrit :
On Wed, Sep 20, 2017 at 4:37 PM Mark Struberg <st...@yahoo.de> wrote:
> Good arguments on both sides.
>
> In anything which goes beyond the core spec we really should also consider
> Tamaya for it in the long run.
> This of course also depends on in which technical and mental state Tamaya
> is these days.
>
> You know, the reason why I left Tamaya behind was not the lots of
> connectors and modules (they are great indeed) but because they tried to
> add all this complexity into their core API. And in my personal opinion
> this was the wrong decision. But it's effectively the whole community which
> decides.
>
> For MicroProfile-Config I'd say we just add another module in
> geronimo-config.
> For the upcoming Configuration API JSR-382 we need to discuss all the
> possible options.
>
> Do we like to implement this in geronimo-config?
> Do we again join forces with Tamaya and start from scratch? The main
> question (for me) is whether Tamaya people are willing to clean up bloat
> and go back to a much more straight forward design.
> How to maintain mp-config over here? How to maintain the old Tamaya API?
> Lots of open questions. In any case I'd love to keep things rather basic
> and not (again) overengineer the design and implementation as such products
> tends to become hard to handle by users.
>
> What we have to be clear about is whether these additional modules are
> purely based on the plain API - that would mean they can be used on every
> MicroProfile server.
> Or whether they make use of internal geronimo-config classes. In which
> case they will obviously only work with g-config...
>
> John, which of the 2 options did you have in mind?
>
I had intended that everything was based on the pure MicroProfile Config
API. I'm not sure there's an internal Geronimo Config API that could be
leveraged for this.
Also what I thought, +1 to try as much as possible and push another spec
release if not enough.
FWIW, I'm ignoring the Tamaya part of this conversation. I think we need
to figure out how we want the Geronimo project to grow.
Think we should think more asf than project here. If you look at bigdata
area we are highly inconsistent. I still hope we dont do it everywhere.
>
> LieGrue,
> strub
>
>
> > Am 20.09.2017 um 14:11 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi John,
> >
> > We can have an extensions/ parent submodule but we should surely sync
> with tamaya as well since we'll overlap a lot and it is quite unconfortable
> at that time to do twice the exact same thing @asf. We should probably try
> to converge at some point.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> > 2017-09-20 14:03 GMT+02:00 John D. Ament <jo...@apache.org>:
> > HI All,
> >
> > I was wondering, would it make sense if we created, perhaps separate
> from the core of Geronimo Config (maybe new repo?) a set of reusable Config
> Sources based on MP Config? This way if people were planning to use etcd,
> consul, zookeeper, archaius (to name a few) we could have a built in, out
> of the box solution to support their use cases?
> >
> > John
> >
>
>
Re: Additional Config Sources?
Posted by "John D. Ament" <jo...@gmail.com>.
On Wed, Sep 20, 2017 at 4:37 PM Mark Struberg <st...@yahoo.de> wrote:
> Good arguments on both sides.
>
> In anything which goes beyond the core spec we really should also consider
> Tamaya for it in the long run.
> This of course also depends on in which technical and mental state Tamaya
> is these days.
>
> You know, the reason why I left Tamaya behind was not the lots of
> connectors and modules (they are great indeed) but because they tried to
> add all this complexity into their core API. And in my personal opinion
> this was the wrong decision. But it's effectively the whole community which
> decides.
>
> For MicroProfile-Config I'd say we just add another module in
> geronimo-config.
> For the upcoming Configuration API JSR-382 we need to discuss all the
> possible options.
>
> Do we like to implement this in geronimo-config?
> Do we again join forces with Tamaya and start from scratch? The main
> question (for me) is whether Tamaya people are willing to clean up bloat
> and go back to a much more straight forward design.
> How to maintain mp-config over here? How to maintain the old Tamaya API?
> Lots of open questions. In any case I'd love to keep things rather basic
> and not (again) overengineer the design and implementation as such products
> tends to become hard to handle by users.
>
> What we have to be clear about is whether these additional modules are
> purely based on the plain API - that would mean they can be used on every
> MicroProfile server.
> Or whether they make use of internal geronimo-config classes. In which
> case they will obviously only work with g-config...
>
> John, which of the 2 options did you have in mind?
>
I had intended that everything was based on the pure MicroProfile Config
API. I'm not sure there's an internal Geronimo Config API that could be
leveraged for this.
FWIW, I'm ignoring the Tamaya part of this conversation. I think we need
to figure out how we want the Geronimo project to grow.
>
> LieGrue,
> strub
>
>
> > Am 20.09.2017 um 14:11 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Hi John,
> >
> > We can have an extensions/ parent submodule but we should surely sync
> with tamaya as well since we'll overlap a lot and it is quite unconfortable
> at that time to do twice the exact same thing @asf. We should probably try
> to converge at some point.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >
> > 2017-09-20 14:03 GMT+02:00 John D. Ament <jo...@apache.org>:
> > HI All,
> >
> > I was wondering, would it make sense if we created, perhaps separate
> from the core of Geronimo Config (maybe new repo?) a set of reusable Config
> Sources based on MP Config? This way if people were planning to use etcd,
> consul, zookeeper, archaius (to name a few) we could have a built in, out
> of the box solution to support their use cases?
> >
> > John
> >
>
>
Re: Additional Config Sources?
Posted by Mark Struberg <st...@yahoo.de>.
Good arguments on both sides.
In anything which goes beyond the core spec we really should also consider Tamaya for it in the long run.
This of course also depends on in which technical and mental state Tamaya is these days.
You know, the reason why I left Tamaya behind was not the lots of connectors and modules (they are great indeed) but because they tried to add all this complexity into their core API. And in my personal opinion this was the wrong decision. But it's effectively the whole community which decides.
For MicroProfile-Config I'd say we just add another module in geronimo-config.
For the upcoming Configuration API JSR-382 we need to discuss all the possible options.
Do we like to implement this in geronimo-config?
Do we again join forces with Tamaya and start from scratch? The main question (for me) is whether Tamaya people are willing to clean up bloat and go back to a much more straight forward design.
How to maintain mp-config over here? How to maintain the old Tamaya API?
Lots of open questions. In any case I'd love to keep things rather basic and not (again) overengineer the design and implementation as such products tends to become hard to handle by users.
What we have to be clear about is whether these additional modules are purely based on the plain API - that would mean they can be used on every MicroProfile server.
Or whether they make use of internal geronimo-config classes. In which case they will obviously only work with g-config...
John, which of the 2 options did you have in mind?
LieGrue,
strub
> Am 20.09.2017 um 14:11 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Hi John,
>
> We can have an extensions/ parent submodule but we should surely sync with tamaya as well since we'll overlap a lot and it is quite unconfortable at that time to do twice the exact same thing @asf. We should probably try to converge at some point.
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>
> 2017-09-20 14:03 GMT+02:00 John D. Ament <jo...@apache.org>:
> HI All,
>
> I was wondering, would it make sense if we created, perhaps separate from the core of Geronimo Config (maybe new repo?) a set of reusable Config Sources based on MP Config? This way if people were planning to use etcd, consul, zookeeper, archaius (to name a few) we could have a built in, out of the box solution to support their use cases?
>
> John
>
Re: Additional Config Sources?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi John,
We can have an extensions/ parent submodule but we should surely sync with
tamaya as well since we'll overlap a lot and it is quite unconfortable at
that time to do twice the exact same thing @asf. We should probably try to
converge at some point.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-09-20 14:03 GMT+02:00 John D. Ament <jo...@apache.org>:
> HI All,
>
> I was wondering, would it make sense if we created, perhaps separate from
> the core of Geronimo Config (maybe new repo?) a set of reusable Config
> Sources based on MP Config? This way if people were planning to use etcd,
> consul, zookeeper, archaius (to name a few) we could have a built in, out
> of the box solution to support their use cases?
>
> John
>