Other MP Specs @ Geronimo?

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

Other MP Specs @ Geronimo?

John D. Ament
All,

I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.

I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.

Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.

I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.  

Any thoughts on bringing these into Geronimo?

John
Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Romain Manni-Bucau
Is there any actual spec?

For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb. 

Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
All,

I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.

I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.

Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.

I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.  

Any thoughts on bringing these into Geronimo?

John

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

John D. Ament


On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
Is there any actual spec?

Not sure what you mean.  Rhetorical question?
 

For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb. 

JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?

 


Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
All,

I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.

I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.

Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.

I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.  

Any thoughts on bringing these into Geronimo?

John

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Romain Manni-Bucau


Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :


On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
Is there any actual spec?

Not sure what you mean.  Rhetorical question?

No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.

 

For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb. 

JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?

It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.



 


Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
All,

I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.

I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.

Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.

I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.  

Any thoughts on bringing these into Geronimo?

John


Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Mark Struberg
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>  
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>  
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.  
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

John D. Ament
Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Romain Manni-Bucau
Go ahead. I d keep geronimo in the package for consistency with the project. Only small thing to take care is probably to not meege ee specs and mp specs in svn to not confuse us ans users.

Le 5 sept. 2017 01:56, "John D. Ament" <[hidden email]> a écrit :
Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Mark Struberg
In reply to this post by John D. Ament
+1 go ahead. Happy to help!

LieGrue,
Strub

Am 05.09.2017 um 01:56 schrieb John D. Ament <[hidden email]>:

Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

John D. Ament
Cool, git repo's been requested.

@Romain I will need your input.  You had implemented semaphores in deltaspike, including that in this project would help align better to the bulkhead requirements.  Any concerns if we base some logic off of that?  A lot can get cleaned up in the mean time since we can base on Java 8.

John

On Tue, Sep 5, 2017 at 6:27 AM Mark Struberg <[hidden email]> wrote:
+1 go ahead. Happy to help!

LieGrue,
Strub

Am 05.09.2017 um 01:56 schrieb John D. Ament <[hidden email]>:

Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Romain Manni-Bucau
Hmm, I would need more details on what you want to build cause semaphores are not always the best for fault tolerances. let me try tp put some thought in a bullet list and maybe start discussing from it to try to be more precise:

- JWT: I'd really go without any lib, it is easy to impl on top of java 8 and avoid to bring in jackson/jose/jjwt and other libs we likely dont want to enforce for stack consistency
- health checker: here we need to be very careful about 2 things: do we want a light monitoring with an aggregated view where healthchecks and gauges are great or do we want an event based monitoring where healthchecks, gauges and counters are useless since the aggregation is done somewhere else (kibana, splunk and a lot of others)
- fault tolerance: here I know 2 different ways to do: local fallback or remote failover, it is mainly just a way to replace a service call by a list through an interceptor (in CDI) - sorting impl with @Priority is quite nice BTW. Only trick is how to handle exception (the parsing needs to be a bit clever to detect 500 etc...)
- ^^ is likely linked to circuit breakers, the simple one of [lang3] can be a good start

It is random thoughts based on my last 5 years so don't read it as "it is the right way" but more as an experience feedback.



Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-09-05 13:52 GMT+02:00 John D. Ament <[hidden email]>:
Cool, git repo's been requested.

@Romain I will need your input.  You had implemented semaphores in deltaspike, including that in this project would help align better to the bulkhead requirements.  Any concerns if we base some logic off of that?  A lot can get cleaned up in the mean time since we can base on Java 8.

John

On Tue, Sep 5, 2017 at 6:27 AM Mark Struberg <[hidden email]> wrote:
+1 go ahead. Happy to help!

LieGrue,
Strub

Am 05.09.2017 um 01:56 schrieb John D. Ament <[hidden email]>:

Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

John D. Ament
MP Fault Tolerance requires both semaphore and threadpool based bulkheads.  What you have in DeltaSpike is the semaphore approach (guarding based on the calling thread count).

Agreed that its not a general solution, its specific to bulkhead based use cases (where you want to limit the number of callers to a specific component).

John

On Tue, Sep 5, 2017 at 8:02 AM Romain Manni-Bucau <[hidden email]> wrote:
Hmm, I would need more details on what you want to build cause semaphores are not always the best for fault tolerances. let me try tp put some thought in a bullet list and maybe start discussing from it to try to be more precise:

- JWT: I'd really go without any lib, it is easy to impl on top of java 8 and avoid to bring in jackson/jose/jjwt and other libs we likely dont want to enforce for stack consistency
- health checker: here we need to be very careful about 2 things: do we want a light monitoring with an aggregated view where healthchecks and gauges are great or do we want an event based monitoring where healthchecks, gauges and counters are useless since the aggregation is done somewhere else (kibana, splunk and a lot of others)
- fault tolerance: here I know 2 different ways to do: local fallback or remote failover, it is mainly just a way to replace a service call by a list through an interceptor (in CDI) - sorting impl with @Priority is quite nice BTW. Only trick is how to handle exception (the parsing needs to be a bit clever to detect 500 etc...)
- ^^ is likely linked to circuit breakers, the simple one of [lang3] can be a good start

It is random thoughts based on my last 5 years so don't read it as "it is the right way" but more as an experience feedback.



Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-09-05 13:52 GMT+02:00 John D. Ament <[hidden email]>:
Cool, git repo's been requested.

@Romain I will need your input.  You had implemented semaphores in deltaspike, including that in this project would help align better to the bulkhead requirements.  Any concerns if we base some logic off of that?  A lot can get cleaned up in the mean time since we can base on Java 8.

John

On Tue, Sep 5, 2017 at 6:27 AM Mark Struberg <[hidden email]> wrote:
+1 go ahead. Happy to help!

LieGrue,
Strub

Am 05.09.2017 um 01:56 schrieb John D. Ament <[hidden email]>:

Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

Romain Manni-Bucau
Yep, thinking about it we can need something flexible on that area (exact vs approximative but lock free for instance). A bench would say it ;)


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-09-05 15:07 GMT+02:00 John D. Ament <[hidden email]>:
MP Fault Tolerance requires both semaphore and threadpool based bulkheads.  What you have in DeltaSpike is the semaphore approach (guarding based on the calling thread count).

Agreed that its not a general solution, its specific to bulkhead based use cases (where you want to limit the number of callers to a specific component).

John


On Tue, Sep 5, 2017 at 8:02 AM Romain Manni-Bucau <[hidden email]> wrote:
Hmm, I would need more details on what you want to build cause semaphores are not always the best for fault tolerances. let me try tp put some thought in a bullet list and maybe start discussing from it to try to be more precise:

- JWT: I'd really go without any lib, it is easy to impl on top of java 8 and avoid to bring in jackson/jose/jjwt and other libs we likely dont want to enforce for stack consistency
- health checker: here we need to be very careful about 2 things: do we want a light monitoring with an aggregated view where healthchecks and gauges are great or do we want an event based monitoring where healthchecks, gauges and counters are useless since the aggregation is done somewhere else (kibana, splunk and a lot of others)
- fault tolerance: here I know 2 different ways to do: local fallback or remote failover, it is mainly just a way to replace a service call by a list through an interceptor (in CDI) - sorting impl with @Priority is quite nice BTW. Only trick is how to handle exception (the parsing needs to be a bit clever to detect 500 etc...)
- ^^ is likely linked to circuit breakers, the simple one of [lang3] can be a good start

It is random thoughts based on my last 5 years so don't read it as "it is the right way" but more as an experience feedback.



Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-09-05 13:52 GMT+02:00 John D. Ament <[hidden email]>:
Cool, git repo's been requested.

@Romain I will need your input.  You had implemented semaphores in deltaspike, including that in this project would help align better to the bulkhead requirements.  Any concerns if we base some logic off of that?  A lot can get cleaned up in the mean time since we can base on Java 8.

John

On Tue, Sep 5, 2017 at 6:27 AM Mark Struberg <[hidden email]> wrote:
+1 go ahead. Happy to help!

LieGrue,
Strub

Am 05.09.2017 um 01:56 schrieb John D. Ament <[hidden email]>:

Gah zombie thread.

So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I've given it a bit more thought as well.  While I'm cautious about Failsafe's future, its something where we can start off as a dependency and grow and replace, or look to get a grant or just import the source code leaving the original headers if need be.

I do have a preference to create this as a git repo.

John

On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[hidden email]> wrote:
I would love implementing the mp jwt spec at Geronimo.
But I've not closely followed the discussions and current state.
So I cannot really make an educated guess right now about whether it already makes sense to implement it.

Although I think it cannot be wrong to start tinkering with it in a seperate component.
And then we know a lot better what it is able to and what not.
This is not yet a guarantee that we release anything in that direction.
But by playing with it we don't loose anything. An the worst case we learn a lot ;)

LieGrue,
strub


> Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau <[hidden email]>:
>
>
>
> Le 30 juil. 2017 23:54, "John D. Ament" <[hidden email]> a écrit :
>
>
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <[hidden email]> wrote:
> Is there any actual spec?
>
> Not sure what you mean.  Rhetorical question?
>
> No no, for now MP is a lot of marketing - server part is nothing for instance. If no spec but future specs I d wait it is close to release.
>
>
>
> For jwt we can impl from scratch, it is not hard and would avoid  a big dep and enable some consistency using jsonb.
>
> JWT is a lot more complicated than that.  It's more than reading the JSON, but also ensuring proper crypto signatures, on the generation and consumption side.  You need to be able to reach out to other servers to fetch keys and handle extra validation checks.  There's a standard set of claims that's being requested as well.  Yes, the json smart dependency bites, maybe we can convince the author to switch to the javax.json namespace?
>
> It is trivial to impl on java once you have json link, ~200 lines for the needed part. Javax.json is maybe not rigyt bit building on it sounds right - actually did on johnzon with quite successes.
>
>
>
>
>
>
> Le 30 juil. 2017 23:28, "John D. Ament" <[hidden email]> a écrit :
> All,
>
> I know Mark brought in Config to Geronimo.  We have at least 3 more specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly Metrics and OpenTracing.
>
> I have a fully functioning JWT Processing impl based on jose ( https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be happy to bring over to Geronimo.
>
> Health is a tricky one, may make sense to start from scratch, or bring in pieces of the former Sirona podling to start a health checker.
>
> I had started on a Fault Tolerance implementation, based on the work from failsafe.  However, from talking to the developer offline I'm a bit worried about relying on Failsafe.
>
> Any thoughts on bringing these into Geronimo?
>
> John
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

David Blevins-2
In reply to this post by John D. Ament
> On Sep 4, 2017, at 4:56 PM, John D. Ament <[hidden email]> wrote:
>
> So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I have a strong preference for “org.apache.safeguard" over “org.apache.geronimo.safeguard”.  We have 14 years of Google search results to work against and a few million developers brains that say Geronimo is an app server.  Every time we put “Geronimo” on something, it’s a strike against Hammok, Meecrowave and TomEE and any MP implementation that may want to use it but not confuse the world that “Geronimo is back".

If we do want a parent package, I repeat we can use org.apache.xbean if we like.  It was meant for common reusable stuff.  We do not need to shackle ourselves with any self-imposed restrictions like “xbean needs to be all released at once”.  That was only done out of laziness.


-David







Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

John D. Ament


On Thu, Sep 7, 2017 at 7:59 PM David Blevins <[hidden email]> wrote:
> On Sep 4, 2017, at 4:56 PM, John D. Ament <[hidden email]> wrote:
>
> So I want to pick back up at least with fault tolerance.  Would anyone be opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so that it would either be "org.apache.safeguard" or "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, config the latter).

I have a strong preference for “org.apache.safeguard" over “org.apache.geronimo.safeguard”.  We have 14 years of Google search results to work against and a few million developers brains that say Geronimo is an app server.  Every time we put “Geronimo” on something, it’s a strike against Hammok, Meecrowave and TomEE and any MP implementation that may want to use it but not confuse the world that “Geronimo is back".

My preference is to keep "org.apache.safeguard" as well.  I've created the base skeleton with "org.apache.geronimo.safeguard" but not sure it'll stay.  Would be good to get a solid response on naming recommendations, so we'll see.  Most other sub-projects just use their own name.
 

If we do want a parent package, I repeat we can use org.apache.xbean if we like.  It was meant for common reusable stuff.  We do not need to shackle ourselves with any self-imposed restrictions like “xbean needs to be all released at once”.  That was only done out of laziness.


The reason I'm hesitant to look at XBean, it seems to be focused on a single target (which is good for a sub-project).  It would start to confuse things to make more stuff XBean.  Plus its a kind of odd name, I'm guessing the X is for XML.
 

-David







Reply | Threaded
Open this post in threaded view
|

Re: Other MP Specs @ Geronimo?

David Blevins-2
> On Sep 7, 2017, at 5:35 PM, John D. Ament <[hidden email]> wrote:
>
> The reason I'm hesitant to look at XBean, it seems to be focused on a single target (which is good for a sub-project).  It would start to confuse things to make more stuff XBean.

Can you elaborate on what you mean by single target?  I’m happy to give the history behind XBean, but the long and short of it is it was largely made by OpenEJB, ActiveMQ and ServiceMix as a place to share code we thought each other might want to reuse.  A lot of it wasn’t used by Geronimo till later.  Nearly all of it is unrelated and goes across the board.  It’s the closest Apache has gotten to an EE commons.

 - xbean-spring = Configuration library for Spring apps that want to use custom xml

         Used by: ActiveMQ, ServiceMix

 - xbean-finder = Annotation scanning library

         Used by: OpenEJB, Geronimo, ServiceMix, ActiveMQ, Aries,
                  Netflix Governator, Netflix Zuul, OPS4j, CrateDB

 - xbean-blueprint = OSGi blueprint related stuff

         Used by: Geronimio, ServiceMix, ActiveMQ, Aries, Fabric8,
                  Osgiliath

 - xbean-naming = JNDI implementation

         Used by: Geronimo, OpenEJB, ServiceMix, Ode, Nuxeo.org,
                  Osgiliath

 - xbean-reflect = Lightweight pojo creator/injector

         Used by: OpenEJB, Geronimo, ServiceMix, Plexus, BatchEE,
                  Meecrowave, Fabric8, Sonatype Nexus, JOnAS, OPS4j,
                  Osgiliath, DataTorrent, more


> Plus its a kind of odd name, I'm guessing the X is for XML.

“Odd name” is a fine enough reason for me.  I certainly prefer that over arguing what XBean is or isn’t, cause then I feel like I need to give a history lesson.  XBean *is* “app server commons”.  It has no other purpose than that.

There are better names.  Let’s definitely use them if we can find them.  My preference would be for us to keep using xbean-* when we can’t think of a better name.


-David