Additional Config Sources?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Additional Config Sources?

John D. Ament
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
Reply | Threaded
Open this post in threaded view
|

Re: Additional Config Sources?

Romain Manni-Bucau
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 BlogGithub | LinkedIn | JavaEE Factory

2017-09-20 14:03 GMT+02:00 John D. Ament <[hidden email]>:
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

Reply | Threaded
Open this post in threaded view
|

Re: Additional Config Sources?

Mark Struberg
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 <[hidden email]>:
>
> 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 <[hidden email]>:
> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Additional Config Sources?

John D. Ament-2


On Wed, Sep 20, 2017 at 4:37 PM Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]>:
> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Additional Config Sources?

Romain Manni-Bucau


Le 24 sept. 2017 14:45, "John D. Ament" <[hidden email]> a écrit :


On Wed, Sep 20, 2017 at 4:37 PM Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]>:
> 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
>