You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Mark Struberg <st...@yahoo.de> on 2017/08/01 08:45:26 UTC

Re: Other MP Specs @ Geronimo?

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 <rm...@gmail.com>:
> 
> 
> 
> Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a écrit :
> 
> 
> On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <rm...@gmail.com> 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" <jo...@apache.org> 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
> 
> 


Re: Other MP Specs @ Geronimo?

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <jo...@apache.org> 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 <st...@yahoo.de> 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 <
>> rmannibucau@gmail.com>:
>> >
>> >
>> >
>> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a
>> écrit :
>> >
>> >
>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com> 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" <jo...@apache.org> 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
>> >
>> >
>>
>>

Re: Other MP Specs @ Geronimo?

Posted by David Blevins <da...@gmail.com>.
> On Sep 7, 2017, at 5:35 PM, John D. Ament <jo...@apache.org> 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


Re: Other MP Specs @ Geronimo?

Posted by "John D. Ament" <jo...@apache.org>.
On Thu, Sep 7, 2017 at 7:59 PM David Blevins <da...@gmail.com>
wrote:

> > On Sep 4, 2017, at 4:56 PM, John D. Ament <jo...@apache.org> 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
>
>
>
>
>
>
>
>

Re: Other MP Specs @ Geronimo?

Posted by David Blevins <da...@gmail.com>.
> On Sep 4, 2017, at 4:56 PM, John D. Ament <jo...@apache.org> 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








Re: Other MP Specs @ Geronimo?

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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-05 15:07 GMT+02:00 John D. Ament <jo...@apache.org>:

> 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 <rm...@gmail.com>
> 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 <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-05 13:52 GMT+02:00 John D. Ament <jo...@apache.org>:
>>
>>> 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 <st...@yahoo.de> wrote:
>>>
>>>> +1 go ahead. Happy to help!
>>>>
>>>> LieGrue,
>>>> Strub
>>>>
>>>> Am 05.09.2017 um 01:56 schrieb John D. Ament <jo...@apache.org>:
>>>>
>>>> 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 <st...@yahoo.de> 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 <
>>>>> rmannibucau@gmail.com>:
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a
>>>>> écrit :
>>>>> >
>>>>> >
>>>>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> 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" <jo...@apache.org> 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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>

Re: Other MP Specs @ Geronimo?

Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@gmail.com>
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 <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-05 13:52 GMT+02:00 John D. Ament <jo...@apache.org>:
>
>> 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 <st...@yahoo.de> wrote:
>>
>>> +1 go ahead. Happy to help!
>>>
>>> LieGrue,
>>> Strub
>>>
>>> Am 05.09.2017 um 01:56 schrieb John D. Ament <jo...@apache.org>:
>>>
>>> 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 <st...@yahoo.de> 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 <
>>>> rmannibucau@gmail.com>:
>>>> >
>>>> >
>>>> >
>>>> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a
>>>> écrit :
>>>> >
>>>> >
>>>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> 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" <jo...@apache.org> 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
>>>> >
>>>> >
>>>>
>>>>
>

Re: Other MP Specs @ Geronimo?

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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-05 13:52 GMT+02:00 John D. Ament <jo...@apache.org>:

> 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 <st...@yahoo.de> wrote:
>
>> +1 go ahead. Happy to help!
>>
>> LieGrue,
>> Strub
>>
>> Am 05.09.2017 um 01:56 schrieb John D. Ament <jo...@apache.org>:
>>
>> 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 <st...@yahoo.de> 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 <
>>> rmannibucau@gmail.com>:
>>> >
>>> >
>>> >
>>> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a
>>> écrit :
>>> >
>>> >
>>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
>>> rmannibucau@gmail.com> 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" <jo...@apache.org> 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
>>> >
>>> >
>>>
>>>

Re: Other MP Specs @ Geronimo?

Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@yahoo.de> wrote:

> +1 go ahead. Happy to help!
>
> LieGrue,
> Strub
>
> Am 05.09.2017 um 01:56 schrieb John D. Ament <jo...@apache.org>:
>
> 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 <st...@yahoo.de> 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 <
>> rmannibucau@gmail.com>:
>> >
>> >
>> >
>> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a
>> écrit :
>> >
>> >
>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com> 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" <jo...@apache.org> 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
>> >
>> >
>>
>>

Re: Other MP Specs @ Geronimo?

Posted by Mark Struberg <st...@yahoo.de>.
+1 go ahead. Happy to help!

LieGrue,
Strub

> Am 05.09.2017 um 01:56 schrieb John D. Ament <jo...@apache.org>:
> 
> 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 <st...@yahoo.de> 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 <rm...@gmail.com>:
>> >
>> >
>> >
>> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a écrit :
>> >
>> >
>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <rm...@gmail.com> 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" <jo...@apache.org> 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
>> >
>> >
>> 

Re: Other MP Specs @ Geronimo?

Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@yahoo.de> 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 <rmannibucau@gmail.com
> >:
> >
> >
> >
> > Le 30 juil. 2017 23:54, "John D. Ament" <jo...@apache.org> a écrit
> :
> >
> >
> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
> rmannibucau@gmail.com> 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" <jo...@apache.org> 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
> >
> >
>
>