Implementing Microprofile JWT

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Hi all,

I was wondering if we could have the Microprofile JWT implemented in TomEE.
What do you think?

I was reading the spec and I'd like to contribute that in.

Jean-Louis

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: Let's do better

[Romain Manni-Bucau <rm...@gmail.com>]

Agreeing with Mark. The answer to the first "why" mail would have removed
the ambiguity my comment would have been "move the examples with others in
examples/ instead of creating a new microprofile branch".


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-13 10:25 GMT+01:00 Mark Struberg <st...@yahoo.de.invalid>:

> It's our duty as PMC members to review committs. And of course a commit
> with the comment 'starting a thing which was decided not to be done' should
> spark EVERYONES curiosity.
>
> All the PMC members at TomEE and Geronimo have been aware of the
> discussions and nobody said anything against putting the reusable parts at
> Geronimo. Au contraire it was widely agreed. Both the Geronimo PMC and also
> the TomEE PMC have been discussing this for months.
>
> Romain and I spent lots of time to find a viable compromise which is in
> the best interest of the broader communities. This included the option of
> moving the existing Geronimo parts to TomEE. Actually whether those parts
> are hosted at TomEE or Geronimo is really a minor point. After all the
> _active_ people are the same in both projects anyway.
>
> Andy made his intent clear now, I applogized. And I don't feel bad for it.
> Because it was very important to clarify the situation.
>
> LieGrue,
> strub
>
>
> > Am 13.02.2018 um 09:52 schrieb Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com>:
> >
> > Morning Mark,
> >
> > I appreciate the feedback, but I disagree.
> >
> > Adding an @Ignore on a test failing does not fix the issue (either the
> test
> > or the code)
> > Putting a napkin over some c... does not clean it up.
> >
> > This is not the first time it happens, so I'd rather prefer the community
> > to vent, put the problems on the table so we can tackle them, instead of
> > pretending the problem is solved and in one month from now, we are in the
> > same position.
> >
> > I do not plan to put fuel on the fire.
> >
> > I'm suggesting that instead of shooting at the daughter and therefor not
> > getting any chance to know it was a present, one should first ask
> > questions.
> > "My sweet heart, why do you have the keys of the car?"
> > "What do you plan to do with them?"
> >
> > I was trying to add some guidance to your good example of the daughter
> and
> > her father.
> >
> > You are a father, so am I.
> >
> > Hope it helps.
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> >> Please all stop putting fuel into the fire.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <
> >> jlmonteiro@tomitribe.com>:
> >>>
> >>> Instead of shooting to someone or start arguing. Simply asking would
> take
> >>> all misunderstand off and avoid this disgusting mess.
> >>>
> >>> Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
> >>> écrit :
> >>>
> >>>> +1  words - and especially brief once as emails - are just a mapping
> >> from
> >>>> the reality to some 'transport mechanism' (Claude Shannon sender
> >> theoreme
> >>>> anyone?).
> >>>> And of course each 'map' is a huge simplification from the reality and
> >>>> thus prone to be misinterpreted.
> >>>>
> >>>> The important part here is that those clashes bring up some difference
> >> in
> >>>> view.
> >>>> And yes, I also think this has nothing to do with immature or
> childish.
> >> We
> >>>> are all just passionate.
> >>>> So the first very important step is to identify the pain point.
> >>>>
> >>>> For Romain and me, etc is to avoid duplication of work which already
> got
> >>>> done in other ASF projects.
> >>>> And to not have those modules hardcoded bound to the TomEE Application
> >>>> Server but to be reusable for other projects.
> >>>> Please note that I'm talking about the Appliation Server only and not
> >>>> about the TomEE project as governance body.
> >>>>
> >>>> I also had an important lesson in the 90s:
> >>>>
> >>>> If you have a problem
> >>>> 1.) solve it
> >>>> 2.) if you cannot solve it, live with it
> >>>> 3.) if you cannot live with it, leave it.
> >>>>
> >>>> More generally:
> >>>> There are some points which totally doesn't matter to someone.
> >>>> There are other points which we would love to see a certain outcome,
> but
> >>>> we would also perfectly accept a compromise.
> >>>> And is also a category of points where we simply cannot live with a
> >>>> compromise. Or where we would simply stop being part of it.
> >>>>
> >>>> In the current situation it's pretty easy. NONE of the cases fits.
> >>>> It was simply a misunderstanding.
> >>>> Andy wanted to commit samples and integrate mp-config to TomEE.
> >>>> This is perfectly fine, but the commit comment and the location was
> very
> >>>> easy to get misinterpreted.
> >>>> And that's exactly what happens.
> >>>>
> >>>> That's like you forbid your daughter to use your car and then she
> >> snatches
> >>>> your keys.
> >>>> You shout at her, but only after she bursts out in tears you find out
> >> that
> >>>> she only wanted to wash your car as a birthday present...
> >>>>
> >>>> And now back to work pretty please ;)
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
> >>>>>
> >>>>> All,
> >>>>>
> >>>>> I followed what David calls "incidents" or "childish" quite closely
> in
> >>>> the
> >>>>> past. Why? Cause such situations are quite familiar to me. I've been
> >>>> there
> >>>>> thousands of times and what I can tell for granted is that non of
> these
> >>>>> situations are neither "incidents" nor "childish".
> >>>>>
> >>>>> As a matter of fact each individual has a certain believe system on
> one
> >>>>> hand and on the other hand lives on his/her own island. The latter I
> >> use
> >>>> as
> >>>>> an explanation for the fact that we all have our own perception of
> what
> >>>> we
> >>>>> think reality is and it usually isn't congruent with the perception
> of
> >>>>> others. If either your believe systems are conflicting or your
> >> perception
> >>>>> of what you think is reality are clashing, you usually have such
> >>>>> "incidents".
> >>>>>
> >>>>> That said I learned the hard way that usually you are not fighting,
> >> like
> >>>> in
> >>>>> this case, about backed out code but it's usually something
> >>>> inter-personal.
> >>>>> What makes me wondering especially if I think about all the Twitter
> and
> >>>>> Facebook posts where I see you guys hanging out together is, that
> such,
> >>>> as
> >>>>> I suspect it inter-personal conflicts, erupt on the mailing list or
> >> over
> >>>>> code commits, where my naive understanding is, that you could talk
> >>>>> face-to-face to nail down what really drives you crazy.
> >>>>>
> >>>>> What I learned is that it doesn't quite help, neither from the
> >>>> perspective
> >>>>> of somebody that is involved, nor from the perspective of somebody
> who
> >>>> is a
> >>>>> leader to finger point or to call out individuals. In the end you
> >> turned
> >>>>> this into a mess and thus you have to fix it TOGETHER. If necessary
> you
> >>>>> could even pull in a coach from outside. I for myself applied for a
> >> coach
> >>>>> back in 2015. It's not a silver bullet and does not fix everything
> you
> >>>>> screwed up in the past but it sometimes helps to have somebody with a
> >>>>> neutral view and another opinion.
> >>>>>
> >>>>> In the end my perception of reality on my little island is that you
> all
> >>>>> bond a very strong team. I saw and worked with teams that were no
> real
> >>>> team
> >>>>> in the end. In your case I don't have such a perception and thus I
> >>>> believe
> >>>>> that you get this sorted out in a sustainable manner. Take it as a
> >> growth
> >>>>> opportunity!
> >>>>>
> >>>>> Cheers
> >>>>> Daniel
> >>>>>
> >>>>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <
> >> david.blevins@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Ok, community, we have to have another quick talk and then hopefully
> >> we
> >>>>>> can go back to being awesome.
> >>>>>>
> >>>>>> This thread got very negative and bares a striking resemblance to
> the
> >>>>>> "Suffocating Development Environment" thread from the June 27th
> >>>> incident.
> >>>>>> Yes, I've written about it enough times in the board reports that I
> >> have
> >>>>>> the date memorized.  What I've written is mostly positive and been
> >>>> praised
> >>>>>> by the board for our handling of a hard situation.  You're all
> making
> >> a
> >>>>>> liar out of me. :)
> >>>>>>
> >>>>>> I was delicate in the first situation, but now I have to be a bit
> more
> >>>>>> direct.
> >>>>>>
> >>>>>>
> >>>>>> In the June 27th incident we had Andy committing code, Romain
> >> reverting
> >>>>>> it, the two exchanging insults for one hour till Andy quit
> complaining
> >>>> that
> >>>>>> he's working in his spare time implies Romain is killing the
> project.
> >>>> Mark
> >>>>>> joins attempting to take some heat off of Romain.  Jon joins
> >> attempting
> >>>> to
> >>>>>> be as neutral as possible.  In the end both Mark and Jon apologize.
> >>>> Andy's
> >>>>>> code stays reverted.
> >>>>>>
> >>>>>> In this incident Andy committed code. Mark and Romain begin arguing.
> >>>>>> Insults are exchanged for one hour till Andy quits complaining that
> >> he's
> >>>>>> working in his spare time and implies Romain is killing the project.
> >>>> Jon
> >>>>>> joins attempting to be as neutral as possible.  In the end both Mark
> >> and
> >>>>>> Jon apologize.  Andy's code stays reverted.  This time it's all
> >>>> Tomitribe's
> >>>>>> fault.
> >>>>>>
> >>>>>>
> >>>>>> Am I the only one to notice a pattern?  That pattern is not one
> >> person's
> >>>>>> fault.  The pattern is we are behaving like children.
> >>>>>>
> >>>>>>
> >>>>>> This will not get better if each of us is expecting the other guy to
> >>>>>> change.  If your only response to this email is find flaws in
> others,
> >> I
> >>>>>> guarantee nothing will get better.
> >>>>>>
> >>>>>> Mark, you got there in the end which is great.  You pointed out
> >>>> something
> >>>>>> you could have done better and something Andy could do better.
> That's
> >>>> the
> >>>>>> right pattern.  People are much more willing to accept feedback when
> >>>> they
> >>>>>> see you're also willing to accept it.
> >>>>>>
> >>>>>> We need to get there sooner next time and we need more than one
> person
> >>>>>> doing it.
> >>>>>>
> >>>>>>
> >>>>>> So with all that said, how do we turn this into an awesome learning
> >>>>>> experience that makes us stronger?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -David
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <
> >> agumbrecht@tomitribe.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Added project stubs: https://github.com/apache/
> >>>>>> tomee/tree/master/microprofile
> >>>>>>>
> >>>>>>> Andy.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Ok thanks guys.
> >>>>>>>> @Rudy, you are most welcome :)
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Louis Monteiro
> >>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>> http://www.tomitribe.com
> >>>>>>>>
> >>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >>>>>> rdebusscher@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I think it is a very important spec, also for non-microprofile
> >>>>>>>>> implementations as it can enhance the interoperability of all
> >>>> servers.
> >>>>>>>>>
> >>>>>>>>> I'm also very interested in the implementation (and want to help
> a
> >>>> bit
> >>>>>> with
> >>>>>>>>> it also :) )
> >>>>>>>>>
> >>>>>>>>> regards
> >>>>>>>>> Rudy
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
> >> <struberg@yahoo.de.invalid
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> To clarify this even further:
> >>>>>>>>>> The Geronimo Server is now officially dead.
> >>>>>>>>>> But the Geronimo project is not. It alredy contains quite a few
> >>>>>> modular
> >>>>>>>>>> parts which are reused in many ASF projects and also outside.
> >>>>>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >>>>>>>>>> geronimo-config, xbean-finder, etc
> >>>>>>>>>>
> >>>>>>>>>> Of course it would probably make sense to fold those 2 projects
> >>>>>> together,
> >>>>>>>>>> as already discussed in the past.
> >>>>>>>>>> I'm still all open to it, but I have an important criterium to
> >>>> fulfil:
> >>>>>>>>>> If we move those portable parts to TomEE, then this would mean
> >> that
> >>>>>> TomEE
> >>>>>>>>>> would become an 'Umbrella project'.
> >>>>>>>>>> And further that we would need a new name for those portable
> >> parts.
> >>>>>>>>>> They would effectively be mainatained by the TomEE community
> >> (which
> >>>>>> has a
> >>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly
> be
> >>>>>>>>>> recognized separately from TomEE.
> >>>>>>>>>>
> >>>>>>>>>> Otherwise people will assume that those parts only work within
> >>>> TomEE -
> >>>>>>>>>> where in reality they would even work on WildFly or Liberty,
> etc.
> >> or
> >>>>>>>>> even a
> >>>>>>>>>> naked Tomcat.
> >>>>>>>>>> Got me?
> >>>>>>>>>>
> >>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> >> Department'
> >>>> :)
> >>>>>>>>>>
> >>>>>>>>>> LieGrue,
> >>>>>>>>>> strub
> >>>>>>>>>>
> >>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name
> to
> >>>> ease
> >>>>>>>>>> backward compatibility.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>>>>>>>> rmannibucau@gmail.com
> >>>>>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>>>>>>>> osantana@tomitribe.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>> Guys, I have a question:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why not a project to each implementation?
> >>>>>>>>>>>>
> >>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> This way I can use just a specific if I want also.
> >>>>>>>>>>>>
> >>>>>>>>>>> exactly the goal and user usage AFAIK ;)
> >>>>>>>>>>>
> >>>>>>>>>>> long story short: we learnt from the past errors and since
> always
> >>>> the
> >>>>>>>>>> same
> >>>>>>>>>>> people work on these projects it is better to not split it
> >> accross
> >>>> N
> >>>>>>>>>>> communities since
> >>>>>>>>>>> it leads to a lot of efforts for these people. Having a single
> >>>>>> umbrella
> >>>>>>>>>>> project with N subprojects reduces the administrative work etc
> >> and
> >>>>>>>>>> enhance
> >>>>>>>>>>> the projects productivity.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi JL,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
> >> already
> >>>>>>>>> spoke
> >>>>>>>>>>>>> about it I think. Would probably saner to keep it all at the
> >> same
> >>>>>>>>> place
> >>>>>>>>>>>> for
> >>>>>>>>>>>>> the foundation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/
> >>>>>>>>>>>>> rmannibucau> |
> >>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>>>>>>>> ee-8-high-performance>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>>>>>>>> jlmonteiro@tomitribe.com
> >>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
> >>>> implemented
> >>>>>> in
> >>>>>>>>>>>>> TomEE.
> >>>>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jean-Louis
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Andy Gumbrecht
> >>>>>>> https://twitter.com/AndyGeeDe
> >>>>>>> http://www.tomitribe.com
> >>>>>>> https://www.tomitribe.io
> >>>>>>>
> >>>>>>>
> >>>>>>> Ubique
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: Let's do better

[Matthew Broadhead <ma...@nbmlaw.co.uk>]

i don't even know what argument this discussion relates to but my 2 
cents are that email and text are a terrible medium for long term 
communication and people should regularly have face to face discussions 
on hangouts or similar.   it is easy to read between the lines of text 
communications and perceive insults that were never intended.  i also 
agree it is good to have things out in the open rather than festering 
below the surface

On 13/02/2018 11:33, Andy Gumbrecht wrote:
> Totally agree with you Mark. My initial response was polite as usual, 
> I acknowledged my mistake and reverted quickly and explained my 
> intention. Then comes the all too familiar b... slap, another one - 
> Jean-Louis response is the best one, but that also can misfire - "What 
> are you 'f'ing doing with my car?", will instantly change the tone and 
> you end up resenting the fact you even considered washing it. My 
> problem is I never slap first, but I really don't respond well when I 
> get one - It's the old soldier in me I guess.
>
> I take the premise, you're standing in a bar. I'm an extremely happy 
> drinker, but don't ask me "What you lookin at?" or spill my beer - In 
> fact, if you do, my first response is "Excuse me?" (Diplomacy), it's 
> the "I said, what are you looking at?" that tips the balance for me. I 
> make an equal effort to be courteous and not spill anyone else's beer 
> in a bar. If I keep getting my beer spilt then as Mark points out, 
> find another pub. Only one choice for me, as I really don't want to 
> fight. That doesn't mean I can't.
>
> Andy.
>
>
> On 13/02/18 10:25, Mark Struberg wrote:
>> It's our duty as PMC members to review committs. And of course a 
>> commit with the comment 'starting a thing which was decided not to be 
>> done' should spark EVERYONES curiosity.
>>
>> All the PMC members at TomEE and Geronimo have been aware of the 
>> discussions and nobody said anything against putting the reusable 
>> parts at Geronimo. Au contraire it was widely agreed. Both the 
>> Geronimo PMC and also the TomEE PMC have been discussing this for 
>> months.
>>
>> Romain and I spent lots of time to find a viable compromise which is 
>> in the best interest of the broader communities. This included the 
>> option of moving the existing Geronimo parts to TomEE. Actually 
>> whether those parts are hosted at TomEE or Geronimo is really a minor 
>> point. After all the _active_ people are the same in both projects 
>> anyway.
>>
>> Andy made his intent clear now, I applogized. And I don't feel bad 
>> for it. Because it was very important to clarify the situation.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 13.02.2018 um 09:52 schrieb Jean-Louis Monteiro 
>>> <jl...@tomitribe.com>:
>>>
>>> Morning Mark,
>>>
>>> I appreciate the feedback, but I disagree.
>>>
>>> Adding an @Ignore on a test failing does not fix the issue (either 
>>> the test
>>> or the code)
>>> Putting a napkin over some c... does not clean it up.
>>>
>>> This is not the first time it happens, so I'd rather prefer the 
>>> community
>>> to vent, put the problems on the table so we can tackle them, 
>>> instead of
>>> pretending the problem is solved and in one month from now, we are 
>>> in the
>>> same position.
>>>
>>> I do not plan to put fuel on the fire.
>>>
>>> I'm suggesting that instead of shooting at the daughter and therefor 
>>> not
>>> getting any chance to know it was a present, one should first ask
>>> questions.
>>> "My sweet heart, why do you have the keys of the car?"
>>> "What do you plan to do with them?"
>>>
>>> I was trying to add some guidance to your good example of the 
>>> daughter and
>>> her father.
>>>
>>> You are a father, so am I.
>>>
>>> Hope it helps.
>>>
>>>
>>>
>>> -- 
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>> On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg 
>>> <st...@yahoo.de.invalid>
>>> wrote:
>>>
>>>> Please all stop putting fuel into the fire.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>> Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <
>>>> jlmonteiro@tomitribe.com>:
>>>>> Instead of shooting to someone or start arguing. Simply asking 
>>>>> would take
>>>>> all misunderstand off and avoid this disgusting mess.
>>>>>
>>>>> Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
>>>>> écrit :
>>>>>
>>>>>> +1  words - and especially brief once as emails - are just a mapping
>>>> from
>>>>>> the reality to some 'transport mechanism' (Claude Shannon sender
>>>> theoreme
>>>>>> anyone?).
>>>>>> And of course each 'map' is a huge simplification from the 
>>>>>> reality and
>>>>>> thus prone to be misinterpreted.
>>>>>>
>>>>>> The important part here is that those clashes bring up some 
>>>>>> difference
>>>> in
>>>>>> view.
>>>>>> And yes, I also think this has nothing to do with immature or 
>>>>>> childish.
>>>> We
>>>>>> are all just passionate.
>>>>>> So the first very important step is to identify the pain point.
>>>>>>
>>>>>> For Romain and me, etc is to avoid duplication of work which 
>>>>>> already got
>>>>>> done in other ASF projects.
>>>>>> And to not have those modules hardcoded bound to the TomEE 
>>>>>> Application
>>>>>> Server but to be reusable for other projects.
>>>>>> Please note that I'm talking about the Appliation Server only and 
>>>>>> not
>>>>>> about the TomEE project as governance body.
>>>>>>
>>>>>> I also had an important lesson in the 90s:
>>>>>>
>>>>>> If you have a problem
>>>>>> 1.) solve it
>>>>>> 2.) if you cannot solve it, live with it
>>>>>> 3.) if you cannot live with it, leave it.
>>>>>>
>>>>>> More generally:
>>>>>> There are some points which totally doesn't matter to someone.
>>>>>> There are other points which we would love to see a certain 
>>>>>> outcome, but
>>>>>> we would also perfectly accept a compromise.
>>>>>> And is also a category of points where we simply cannot live with a
>>>>>> compromise. Or where we would simply stop being part of it.
>>>>>>
>>>>>> In the current situation it's pretty easy. NONE of the cases fits.
>>>>>> It was simply a misunderstanding.
>>>>>> Andy wanted to commit samples and integrate mp-config to TomEE.
>>>>>> This is perfectly fine, but the commit comment and the location 
>>>>>> was very
>>>>>> easy to get misinterpreted.
>>>>>> And that's exactly what happens.
>>>>>>
>>>>>> That's like you forbid your daughter to use your car and then she
>>>> snatches
>>>>>> your keys.
>>>>>> You shout at her, but only after she bursts out in tears you find 
>>>>>> out
>>>> that
>>>>>> she only wanted to wash your car as a birthday present...
>>>>>>
>>>>>> And now back to work pretty please ;)
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I followed what David calls "incidents" or "childish" quite 
>>>>>>> closely in
>>>>>> the
>>>>>>> past. Why? Cause such situations are quite familiar to me. I've 
>>>>>>> been
>>>>>> there
>>>>>>> thousands of times and what I can tell for granted is that non 
>>>>>>> of these
>>>>>>> situations are neither "incidents" nor "childish".
>>>>>>>
>>>>>>> As a matter of fact each individual has a certain believe system 
>>>>>>> on one
>>>>>>> hand and on the other hand lives on his/her own island. The 
>>>>>>> latter I
>>>> use
>>>>>> as
>>>>>>> an explanation for the fact that we all have our own perception 
>>>>>>> of what
>>>>>> we
>>>>>>> think reality is and it usually isn't congruent with the 
>>>>>>> perception of
>>>>>>> others. If either your believe systems are conflicting or your
>>>> perception
>>>>>>> of what you think is reality are clashing, you usually have such
>>>>>>> "incidents".
>>>>>>>
>>>>>>> That said I learned the hard way that usually you are not fighting,
>>>> like
>>>>>> in
>>>>>>> this case, about backed out code but it's usually something
>>>>>> inter-personal.
>>>>>>> What makes me wondering especially if I think about all the 
>>>>>>> Twitter and
>>>>>>> Facebook posts where I see you guys hanging out together is, 
>>>>>>> that such,
>>>>>> as
>>>>>>> I suspect it inter-personal conflicts, erupt on the mailing list or
>>>> over
>>>>>>> code commits, where my naive understanding is, that you could talk
>>>>>>> face-to-face to nail down what really drives you crazy.
>>>>>>>
>>>>>>> What I learned is that it doesn't quite help, neither from the
>>>>>> perspective
>>>>>>> of somebody that is involved, nor from the perspective of 
>>>>>>> somebody who
>>>>>> is a
>>>>>>> leader to finger point or to call out individuals. In the end you
>>>> turned
>>>>>>> this into a mess and thus you have to fix it TOGETHER. If 
>>>>>>> necessary you
>>>>>>> could even pull in a coach from outside. I for myself applied for a
>>>> coach
>>>>>>> back in 2015. It's not a silver bullet and does not fix 
>>>>>>> everything you
>>>>>>> screwed up in the past but it sometimes helps to have somebody 
>>>>>>> with a
>>>>>>> neutral view and another opinion.
>>>>>>>
>>>>>>> In the end my perception of reality on my little island is that 
>>>>>>> you all
>>>>>>> bond a very strong team. I saw and worked with teams that were 
>>>>>>> no real
>>>>>> team
>>>>>>> in the end. In your case I don't have such a perception and thus I
>>>>>> believe
>>>>>>> that you get this sorted out in a sustainable manner. Take it as a
>>>> growth
>>>>>>> opportunity!
>>>>>>>
>>>>>>> Cheers
>>>>>>> Daniel
>>>>>>>
>>>>>>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <
>>>> david.blevins@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ok, community, we have to have another quick talk and then 
>>>>>>>> hopefully
>>>> we
>>>>>>>> can go back to being awesome.
>>>>>>>>
>>>>>>>> This thread got very negative and bares a striking resemblance 
>>>>>>>> to the
>>>>>>>> "Suffocating Development Environment" thread from the June 27th
>>>>>> incident.
>>>>>>>> Yes, I've written about it enough times in the board reports 
>>>>>>>> that I
>>>> have
>>>>>>>> the date memorized.  What I've written is mostly positive and been
>>>>>> praised
>>>>>>>> by the board for our handling of a hard situation.  You're all 
>>>>>>>> making
>>>> a
>>>>>>>> liar out of me. :)
>>>>>>>>
>>>>>>>> I was delicate in the first situation, but now I have to be a 
>>>>>>>> bit more
>>>>>>>> direct.
>>>>>>>>
>>>>>>>>
>>>>>>>> In the June 27th incident we had Andy committing code, Romain
>>>> reverting
>>>>>>>> it, the two exchanging insults for one hour till Andy quit 
>>>>>>>> complaining
>>>>>> that
>>>>>>>> he's working in his spare time implies Romain is killing the 
>>>>>>>> project.
>>>>>> Mark
>>>>>>>> joins attempting to take some heat off of Romain.  Jon joins
>>>> attempting
>>>>>> to
>>>>>>>> be as neutral as possible.  In the end both Mark and Jon 
>>>>>>>> apologize.
>>>>>> Andy's
>>>>>>>> code stays reverted.
>>>>>>>>
>>>>>>>> In this incident Andy committed code. Mark and Romain begin 
>>>>>>>> arguing.
>>>>>>>> Insults are exchanged for one hour till Andy quits complaining 
>>>>>>>> that
>>>> he's
>>>>>>>> working in his spare time and implies Romain is killing the 
>>>>>>>> project.
>>>>>> Jon
>>>>>>>> joins attempting to be as neutral as possible.  In the end both 
>>>>>>>> Mark
>>>> and
>>>>>>>> Jon apologize.  Andy's code stays reverted.  This time it's all
>>>>>> Tomitribe's
>>>>>>>> fault.
>>>>>>>>
>>>>>>>>
>>>>>>>> Am I the only one to notice a pattern?  That pattern is not one
>>>> person's
>>>>>>>> fault.  The pattern is we are behaving like children.
>>>>>>>>
>>>>>>>>
>>>>>>>> This will not get better if each of us is expecting the other 
>>>>>>>> guy to
>>>>>>>> change.  If your only response to this email is find flaws in 
>>>>>>>> others,
>>>> I
>>>>>>>> guarantee nothing will get better.
>>>>>>>>
>>>>>>>> Mark, you got there in the end which is great.  You pointed out
>>>>>> something
>>>>>>>> you could have done better and something Andy could do better.  
>>>>>>>> That's
>>>>>> the
>>>>>>>> right pattern.  People are much more willing to accept feedback 
>>>>>>>> when
>>>>>> they
>>>>>>>> see you're also willing to accept it.
>>>>>>>>
>>>>>>>> We need to get there sooner next time and we need more than one 
>>>>>>>> person
>>>>>>>> doing it.
>>>>>>>>
>>>>>>>>
>>>>>>>> So with all that said, how do we turn this into an awesome 
>>>>>>>> learning
>>>>>>>> experience that makes us stronger?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <
>>>> agumbrecht@tomitribe.com
>>>>>>>> wrote:
>>>>>>>>> Added project stubs: https://github.com/apache/
>>>>>>>> tomee/tree/master/microprofile
>>>>>>>>> Andy.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Ok thanks guys.
>>>>>>>>>> @Rudy, you are most welcome :)
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>
>>>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>>>>>>> rdebusscher@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I think it is a very important spec, also for non-microprofile
>>>>>>>>>>> implementations as it can enhance the interoperability of all
>>>>>> servers.
>>>>>>>>>>> I'm also very interested in the implementation (and want to 
>>>>>>>>>>> help a
>>>>>> bit
>>>>>>>> with
>>>>>>>>>>> it also :) )
>>>>>>>>>>>
>>>>>>>>>>> regards
>>>>>>>>>>> Rudy
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
>>>> <struberg@yahoo.de.invalid
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> To clarify this even further:
>>>>>>>>>>>> The Geronimo Server is now officially dead.
>>>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a 
>>>>>>>>>>>> few
>>>>>>>> modular
>>>>>>>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>>>>>>>> Examples is the geronimo-transaction-manager, 
>>>>>>>>>>>> geronimo-javamail,
>>>>>>>>>>>> geronimo-config, xbean-finder, etc
>>>>>>>>>>>>
>>>>>>>>>>>> Of course it would probably make sense to fold those 2 
>>>>>>>>>>>> projects
>>>>>>>> together,
>>>>>>>>>>>> as already discussed in the past.
>>>>>>>>>>>> I'm still all open to it, but I have an important criterium to
>>>>>> fulfil:
>>>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
>>>> that
>>>>>>>> TomEE
>>>>>>>>>>>> would become an 'Umbrella project'.
>>>>>>>>>>>> And further that we would need a new name for those portable
>>>> parts.
>>>>>>>>>>>> They would effectively be mainatained by the TomEE community
>>>> (which
>>>>>>>> has a
>>>>>>>>>>>> big overlap with Geronimo anyway) but those parts must 
>>>>>>>>>>>> clearly be
>>>>>>>>>>>> recognized separately from TomEE.
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise people will assume that those parts only work within
>>>>>> TomEE -
>>>>>>>>>>>> where in reality they would even work on WildFly or 
>>>>>>>>>>>> Liberty, etc.
>>>> or
>>>>>>>>>>> even a
>>>>>>>>>>>> naked Tomcat.
>>>>>>>>>>>> Got me?
>>>>>>>>>>>>
>>>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
>>>> Department'
>>>>>> :)
>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>> strub
>>>>>>>>>>>>
>>>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package 
>>>>>>>>>>>> name to
>>>>>> ease
>>>>>>>>>>>> backward compatibility.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>>>>>>>> osantana@tomitribe.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Guys, I have a question:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why not a project to each implementation?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>>>>>>>
>>>>>>>>>>>>> long story short: we learnt from the past errors and since 
>>>>>>>>>>>>> always
>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>>> people work on these projects it is better to not split it
>>>> accross
>>>>>> N
>>>>>>>>>>>>> communities since
>>>>>>>>>>>>> it leads to a lot of efforts for these people. Having a 
>>>>>>>>>>>>> single
>>>>>>>> umbrella
>>>>>>>>>>>>> project with N subprojects reduces the administrative work 
>>>>>>>>>>>>> etc
>>>> and
>>>>>>>>>>>> enhance
>>>>>>>>>>>>> the projects productivity.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi JL,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
>>>> already
>>>>>>>>>>> spoke
>>>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at 
>>>>>>>>>>>>>>> the
>>>> same
>>>>>>>>>>> place
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the foundation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>> https://github.com/
>>>>>>>>>>>>>>> rmannibucau> |
>>>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>>>>>>>> ee-8-high-performance>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>>>>>>>> jlmonteiro@tomitribe.com
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
>>>>>> implemented
>>>>>>>> in
>>>>>>>>>>>>>>> TomEE.
>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jean-Louis
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Andy Gumbrecht
>>>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>>>> http://www.tomitribe.com
>>>>>>>>> https://www.tomitribe.io
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ubique
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>

Re: Let's do better

[Andy Gumbrecht <ag...@tomitribe.com>]

Totally agree with you Mark. My initial response was polite as usual, I 
acknowledged my mistake and reverted quickly and explained my intention. 
Then comes the all too familiar b... slap, another one - Jean-Louis 
response is the best one, but that also can misfire - "What are you 
'f'ing doing with my car?", will instantly change the tone and you end 
up resenting the fact you even considered washing it. My problem is I 
never slap first, but I really don't respond well when I get one - It's 
the old soldier in me I guess.

I take the premise, you're standing in a bar. I'm an extremely happy 
drinker, but don't ask me "What you lookin at?" or spill my beer - In 
fact, if you do, my first response is "Excuse me?" (Diplomacy), it's the 
"I said, what are you looking at?" that tips the balance for me. I make 
an equal effort to be courteous and not spill anyone else's beer in a 
bar. If I keep getting my beer spilt then as Mark points out, find 
another pub. Only one choice for me, as I really don't want to fight. 
That doesn't mean I can't.

Andy.


On 13/02/18 10:25, Mark Struberg wrote:
> It's our duty as PMC members to review committs. And of course a commit with the comment 'starting a thing which was decided not to be done' should spark EVERYONES curiosity.
>
> All the PMC members at TomEE and Geronimo have been aware of the discussions and nobody said anything against putting the reusable parts at Geronimo. Au contraire it was widely agreed. Both the Geronimo PMC and also the TomEE PMC have been discussing this for months.
>
> Romain and I spent lots of time to find a viable compromise which is in the best interest of the broader communities. This included the option of moving the existing Geronimo parts to TomEE. Actually whether those parts are hosted at TomEE or Geronimo is really a minor point. After all the _active_ people are the same in both projects anyway.
>
> Andy made his intent clear now, I applogized. And I don't feel bad for it. Because it was very important to clarify the situation.
>
> LieGrue,
> strub
>
>
>> Am 13.02.2018 um 09:52 schrieb Jean-Louis Monteiro <jl...@tomitribe.com>:
>>
>> Morning Mark,
>>
>> I appreciate the feedback, but I disagree.
>>
>> Adding an @Ignore on a test failing does not fix the issue (either the test
>> or the code)
>> Putting a napkin over some c... does not clean it up.
>>
>> This is not the first time it happens, so I'd rather prefer the community
>> to vent, put the problems on the table so we can tackle them, instead of
>> pretending the problem is solved and in one month from now, we are in the
>> same position.
>>
>> I do not plan to put fuel on the fire.
>>
>> I'm suggesting that instead of shooting at the daughter and therefor not
>> getting any chance to know it was a present, one should first ask
>> questions.
>> "My sweet heart, why do you have the keys of the car?"
>> "What do you plan to do with them?"
>>
>> I was trying to add some guidance to your good example of the daughter and
>> her father.
>>
>> You are a father, so am I.
>>
>> Hope it helps.
>>
>>
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>>
>>> Please all stop putting fuel into the fire.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com>:
>>>> Instead of shooting to someone or start arguing. Simply asking would take
>>>> all misunderstand off and avoid this disgusting mess.
>>>>
>>>> Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
>>>> écrit :
>>>>
>>>>> +1  words - and especially brief once as emails - are just a mapping
>>> from
>>>>> the reality to some 'transport mechanism' (Claude Shannon sender
>>> theoreme
>>>>> anyone?).
>>>>> And of course each 'map' is a huge simplification from the reality and
>>>>> thus prone to be misinterpreted.
>>>>>
>>>>> The important part here is that those clashes bring up some difference
>>> in
>>>>> view.
>>>>> And yes, I also think this has nothing to do with immature or childish.
>>> We
>>>>> are all just passionate.
>>>>> So the first very important step is to identify the pain point.
>>>>>
>>>>> For Romain and me, etc is to avoid duplication of work which already got
>>>>> done in other ASF projects.
>>>>> And to not have those modules hardcoded bound to the TomEE Application
>>>>> Server but to be reusable for other projects.
>>>>> Please note that I'm talking about the Appliation Server only and not
>>>>> about the TomEE project as governance body.
>>>>>
>>>>> I also had an important lesson in the 90s:
>>>>>
>>>>> If you have a problem
>>>>> 1.) solve it
>>>>> 2.) if you cannot solve it, live with it
>>>>> 3.) if you cannot live with it, leave it.
>>>>>
>>>>> More generally:
>>>>> There are some points which totally doesn't matter to someone.
>>>>> There are other points which we would love to see a certain outcome, but
>>>>> we would also perfectly accept a compromise.
>>>>> And is also a category of points where we simply cannot live with a
>>>>> compromise. Or where we would simply stop being part of it.
>>>>>
>>>>> In the current situation it's pretty easy. NONE of the cases fits.
>>>>> It was simply a misunderstanding.
>>>>> Andy wanted to commit samples and integrate mp-config to TomEE.
>>>>> This is perfectly fine, but the commit comment and the location was very
>>>>> easy to get misinterpreted.
>>>>> And that's exactly what happens.
>>>>>
>>>>> That's like you forbid your daughter to use your car and then she
>>> snatches
>>>>> your keys.
>>>>> You shout at her, but only after she bursts out in tears you find out
>>> that
>>>>> she only wanted to wash your car as a birthday present...
>>>>>
>>>>> And now back to work pretty please ;)
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> I followed what David calls "incidents" or "childish" quite closely in
>>>>> the
>>>>>> past. Why? Cause such situations are quite familiar to me. I've been
>>>>> there
>>>>>> thousands of times and what I can tell for granted is that non of these
>>>>>> situations are neither "incidents" nor "childish".
>>>>>>
>>>>>> As a matter of fact each individual has a certain believe system on one
>>>>>> hand and on the other hand lives on his/her own island. The latter I
>>> use
>>>>> as
>>>>>> an explanation for the fact that we all have our own perception of what
>>>>> we
>>>>>> think reality is and it usually isn't congruent with the perception of
>>>>>> others. If either your believe systems are conflicting or your
>>> perception
>>>>>> of what you think is reality are clashing, you usually have such
>>>>>> "incidents".
>>>>>>
>>>>>> That said I learned the hard way that usually you are not fighting,
>>> like
>>>>> in
>>>>>> this case, about backed out code but it's usually something
>>>>> inter-personal.
>>>>>> What makes me wondering especially if I think about all the Twitter and
>>>>>> Facebook posts where I see you guys hanging out together is, that such,
>>>>> as
>>>>>> I suspect it inter-personal conflicts, erupt on the mailing list or
>>> over
>>>>>> code commits, where my naive understanding is, that you could talk
>>>>>> face-to-face to nail down what really drives you crazy.
>>>>>>
>>>>>> What I learned is that it doesn't quite help, neither from the
>>>>> perspective
>>>>>> of somebody that is involved, nor from the perspective of somebody who
>>>>> is a
>>>>>> leader to finger point or to call out individuals. In the end you
>>> turned
>>>>>> this into a mess and thus you have to fix it TOGETHER. If necessary you
>>>>>> could even pull in a coach from outside. I for myself applied for a
>>> coach
>>>>>> back in 2015. It's not a silver bullet and does not fix everything you
>>>>>> screwed up in the past but it sometimes helps to have somebody with a
>>>>>> neutral view and another opinion.
>>>>>>
>>>>>> In the end my perception of reality on my little island is that you all
>>>>>> bond a very strong team. I saw and worked with teams that were no real
>>>>> team
>>>>>> in the end. In your case I don't have such a perception and thus I
>>>>> believe
>>>>>> that you get this sorted out in a sustainable manner. Take it as a
>>> growth
>>>>>> opportunity!
>>>>>>
>>>>>> Cheers
>>>>>> Daniel
>>>>>>
>>>>>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <
>>> david.blevins@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok, community, we have to have another quick talk and then hopefully
>>> we
>>>>>>> can go back to being awesome.
>>>>>>>
>>>>>>> This thread got very negative and bares a striking resemblance to the
>>>>>>> "Suffocating Development Environment" thread from the June 27th
>>>>> incident.
>>>>>>> Yes, I've written about it enough times in the board reports that I
>>> have
>>>>>>> the date memorized.  What I've written is mostly positive and been
>>>>> praised
>>>>>>> by the board for our handling of a hard situation.  You're all making
>>> a
>>>>>>> liar out of me. :)
>>>>>>>
>>>>>>> I was delicate in the first situation, but now I have to be a bit more
>>>>>>> direct.
>>>>>>>
>>>>>>>
>>>>>>> In the June 27th incident we had Andy committing code, Romain
>>> reverting
>>>>>>> it, the two exchanging insults for one hour till Andy quit complaining
>>>>> that
>>>>>>> he's working in his spare time implies Romain is killing the project.
>>>>> Mark
>>>>>>> joins attempting to take some heat off of Romain.  Jon joins
>>> attempting
>>>>> to
>>>>>>> be as neutral as possible.  In the end both Mark and Jon apologize.
>>>>> Andy's
>>>>>>> code stays reverted.
>>>>>>>
>>>>>>> In this incident Andy committed code. Mark and Romain begin arguing.
>>>>>>> Insults are exchanged for one hour till Andy quits complaining that
>>> he's
>>>>>>> working in his spare time and implies Romain is killing the project.
>>>>> Jon
>>>>>>> joins attempting to be as neutral as possible.  In the end both Mark
>>> and
>>>>>>> Jon apologize.  Andy's code stays reverted.  This time it's all
>>>>> Tomitribe's
>>>>>>> fault.
>>>>>>>
>>>>>>>
>>>>>>> Am I the only one to notice a pattern?  That pattern is not one
>>> person's
>>>>>>> fault.  The pattern is we are behaving like children.
>>>>>>>
>>>>>>>
>>>>>>> This will not get better if each of us is expecting the other guy to
>>>>>>> change.  If your only response to this email is find flaws in others,
>>> I
>>>>>>> guarantee nothing will get better.
>>>>>>>
>>>>>>> Mark, you got there in the end which is great.  You pointed out
>>>>> something
>>>>>>> you could have done better and something Andy could do better.  That's
>>>>> the
>>>>>>> right pattern.  People are much more willing to accept feedback when
>>>>> they
>>>>>>> see you're also willing to accept it.
>>>>>>>
>>>>>>> We need to get there sooner next time and we need more than one person
>>>>>>> doing it.
>>>>>>>
>>>>>>>
>>>>>>> So with all that said, how do we turn this into an awesome learning
>>>>>>> experience that makes us stronger?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <
>>> agumbrecht@tomitribe.com
>>>>>>> wrote:
>>>>>>>> Added project stubs: https://github.com/apache/
>>>>>>> tomee/tree/master/microprofile
>>>>>>>> Andy.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Ok thanks guys.
>>>>>>>>> @Rudy, you are most welcome :)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>
>>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>>>>>> rdebusscher@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I think it is a very important spec, also for non-microprofile
>>>>>>>>>> implementations as it can enhance the interoperability of all
>>>>> servers.
>>>>>>>>>> I'm also very interested in the implementation (and want to help a
>>>>> bit
>>>>>>> with
>>>>>>>>>> it also :) )
>>>>>>>>>>
>>>>>>>>>> regards
>>>>>>>>>> Rudy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
>>> <struberg@yahoo.de.invalid
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> To clarify this even further:
>>>>>>>>>>> The Geronimo Server is now officially dead.
>>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a few
>>>>>>> modular
>>>>>>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>>>>>>>>> geronimo-config, xbean-finder, etc
>>>>>>>>>>>
>>>>>>>>>>> Of course it would probably make sense to fold those 2 projects
>>>>>>> together,
>>>>>>>>>>> as already discussed in the past.
>>>>>>>>>>> I'm still all open to it, but I have an important criterium to
>>>>> fulfil:
>>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
>>> that
>>>>>>> TomEE
>>>>>>>>>>> would become an 'Umbrella project'.
>>>>>>>>>>> And further that we would need a new name for those portable
>>> parts.
>>>>>>>>>>> They would effectively be mainatained by the TomEE community
>>> (which
>>>>>>> has a
>>>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>>>>>>>>> recognized separately from TomEE.
>>>>>>>>>>>
>>>>>>>>>>> Otherwise people will assume that those parts only work within
>>>>> TomEE -
>>>>>>>>>>> where in reality they would even work on WildFly or Liberty, etc.
>>> or
>>>>>>>>>> even a
>>>>>>>>>>> naked Tomcat.
>>>>>>>>>>> Got me?
>>>>>>>>>>>
>>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
>>> Department'
>>>>> :)
>>>>>>>>>>> LieGrue,
>>>>>>>>>>> strub
>>>>>>>>>>>
>>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to
>>>>> ease
>>>>>>>>>>> backward compatibility.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>>>>>>> osantana@tomitribe.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Guys, I have a question:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why not a project to each implementation?
>>>>>>>>>>>>>
>>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>>>>>>
>>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>>>>>>
>>>>>>>>>>>> long story short: we learnt from the past errors and since always
>>>>> the
>>>>>>>>>>> same
>>>>>>>>>>>> people work on these projects it is better to not split it
>>> accross
>>>>> N
>>>>>>>>>>>> communities since
>>>>>>>>>>>> it leads to a lot of efforts for these people. Having a single
>>>>>>> umbrella
>>>>>>>>>>>> project with N subprojects reduces the administrative work etc
>>> and
>>>>>>>>>>> enhance
>>>>>>>>>>>> the projects productivity.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi JL,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
>>> already
>>>>>>>>>> spoke
>>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at the
>>> same
>>>>>>>>>> place
>>>>>>>>>>>>> for
>>>>>>>>>>>>>> the foundation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/
>>>>>>>>>>>>>> rmannibucau> |
>>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>>>>>>> ee-8-high-performance>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>>>>>>> jlmonteiro@tomitribe.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
>>>>> implemented
>>>>>>> in
>>>>>>>>>>>>>> TomEE.
>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jean-Louis
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Andy Gumbrecht
>>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>>> http://www.tomitribe.com
>>>>>>>> https://www.tomitribe.io
>>>>>>>>
>>>>>>>>
>>>>>>>> Ubique
>>>>>>>>
>>>>>>>
>>>>>
>>>
>

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Let's do better

[Mark Struberg <st...@yahoo.de.INVALID>]

It's our duty as PMC members to review committs. And of course a commit with the comment 'starting a thing which was decided not to be done' should spark EVERYONES curiosity.

All the PMC members at TomEE and Geronimo have been aware of the discussions and nobody said anything against putting the reusable parts at Geronimo. Au contraire it was widely agreed. Both the Geronimo PMC and also the TomEE PMC have been discussing this for months.

Romain and I spent lots of time to find a viable compromise which is in the best interest of the broader communities. This included the option of moving the existing Geronimo parts to TomEE. Actually whether those parts are hosted at TomEE or Geronimo is really a minor point. After all the _active_ people are the same in both projects anyway.

Andy made his intent clear now, I applogized. And I don't feel bad for it. Because it was very important to clarify the situation. 

LieGrue,
strub


> Am 13.02.2018 um 09:52 schrieb Jean-Louis Monteiro <jl...@tomitribe.com>:
> 
> Morning Mark,
> 
> I appreciate the feedback, but I disagree.
> 
> Adding an @Ignore on a test failing does not fix the issue (either the test
> or the code)
> Putting a napkin over some c... does not clean it up.
> 
> This is not the first time it happens, so I'd rather prefer the community
> to vent, put the problems on the table so we can tackle them, instead of
> pretending the problem is solved and in one month from now, we are in the
> same position.
> 
> I do not plan to put fuel on the fire.
> 
> I'm suggesting that instead of shooting at the daughter and therefor not
> getting any chance to know it was a present, one should first ask
> questions.
> "My sweet heart, why do you have the keys of the car?"
> "What do you plan to do with them?"
> 
> I was trying to add some guidance to your good example of the daughter and
> her father.
> 
> You are a father, so am I.
> 
> Hope it helps.
> 
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
> 
>> Please all stop putting fuel into the fire.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <
>> jlmonteiro@tomitribe.com>:
>>> 
>>> Instead of shooting to someone or start arguing. Simply asking would take
>>> all misunderstand off and avoid this disgusting mess.
>>> 
>>> Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
>>> écrit :
>>> 
>>>> +1  words - and especially brief once as emails - are just a mapping
>> from
>>>> the reality to some 'transport mechanism' (Claude Shannon sender
>> theoreme
>>>> anyone?).
>>>> And of course each 'map' is a huge simplification from the reality and
>>>> thus prone to be misinterpreted.
>>>> 
>>>> The important part here is that those clashes bring up some difference
>> in
>>>> view.
>>>> And yes, I also think this has nothing to do with immature or childish.
>> We
>>>> are all just passionate.
>>>> So the first very important step is to identify the pain point.
>>>> 
>>>> For Romain and me, etc is to avoid duplication of work which already got
>>>> done in other ASF projects.
>>>> And to not have those modules hardcoded bound to the TomEE Application
>>>> Server but to be reusable for other projects.
>>>> Please note that I'm talking about the Appliation Server only and not
>>>> about the TomEE project as governance body.
>>>> 
>>>> I also had an important lesson in the 90s:
>>>> 
>>>> If you have a problem
>>>> 1.) solve it
>>>> 2.) if you cannot solve it, live with it
>>>> 3.) if you cannot live with it, leave it.
>>>> 
>>>> More generally:
>>>> There are some points which totally doesn't matter to someone.
>>>> There are other points which we would love to see a certain outcome, but
>>>> we would also perfectly accept a compromise.
>>>> And is also a category of points where we simply cannot live with a
>>>> compromise. Or where we would simply stop being part of it.
>>>> 
>>>> In the current situation it's pretty easy. NONE of the cases fits.
>>>> It was simply a misunderstanding.
>>>> Andy wanted to commit samples and integrate mp-config to TomEE.
>>>> This is perfectly fine, but the commit comment and the location was very
>>>> easy to get misinterpreted.
>>>> And that's exactly what happens.
>>>> 
>>>> That's like you forbid your daughter to use your car and then she
>> snatches
>>>> your keys.
>>>> You shout at her, but only after she bursts out in tears you find out
>> that
>>>> she only wanted to wash your car as a birthday present...
>>>> 
>>>> And now back to work pretty please ;)
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>>> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
>>>>> 
>>>>> All,
>>>>> 
>>>>> I followed what David calls "incidents" or "childish" quite closely in
>>>> the
>>>>> past. Why? Cause such situations are quite familiar to me. I've been
>>>> there
>>>>> thousands of times and what I can tell for granted is that non of these
>>>>> situations are neither "incidents" nor "childish".
>>>>> 
>>>>> As a matter of fact each individual has a certain believe system on one
>>>>> hand and on the other hand lives on his/her own island. The latter I
>> use
>>>> as
>>>>> an explanation for the fact that we all have our own perception of what
>>>> we
>>>>> think reality is and it usually isn't congruent with the perception of
>>>>> others. If either your believe systems are conflicting or your
>> perception
>>>>> of what you think is reality are clashing, you usually have such
>>>>> "incidents".
>>>>> 
>>>>> That said I learned the hard way that usually you are not fighting,
>> like
>>>> in
>>>>> this case, about backed out code but it's usually something
>>>> inter-personal.
>>>>> What makes me wondering especially if I think about all the Twitter and
>>>>> Facebook posts where I see you guys hanging out together is, that such,
>>>> as
>>>>> I suspect it inter-personal conflicts, erupt on the mailing list or
>> over
>>>>> code commits, where my naive understanding is, that you could talk
>>>>> face-to-face to nail down what really drives you crazy.
>>>>> 
>>>>> What I learned is that it doesn't quite help, neither from the
>>>> perspective
>>>>> of somebody that is involved, nor from the perspective of somebody who
>>>> is a
>>>>> leader to finger point or to call out individuals. In the end you
>> turned
>>>>> this into a mess and thus you have to fix it TOGETHER. If necessary you
>>>>> could even pull in a coach from outside. I for myself applied for a
>> coach
>>>>> back in 2015. It's not a silver bullet and does not fix everything you
>>>>> screwed up in the past but it sometimes helps to have somebody with a
>>>>> neutral view and another opinion.
>>>>> 
>>>>> In the end my perception of reality on my little island is that you all
>>>>> bond a very strong team. I saw and worked with teams that were no real
>>>> team
>>>>> in the end. In your case I don't have such a perception and thus I
>>>> believe
>>>>> that you get this sorted out in a sustainable manner. Take it as a
>> growth
>>>>> opportunity!
>>>>> 
>>>>> Cheers
>>>>> Daniel
>>>>> 
>>>>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <
>> david.blevins@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Ok, community, we have to have another quick talk and then hopefully
>> we
>>>>>> can go back to being awesome.
>>>>>> 
>>>>>> This thread got very negative and bares a striking resemblance to the
>>>>>> "Suffocating Development Environment" thread from the June 27th
>>>> incident.
>>>>>> Yes, I've written about it enough times in the board reports that I
>> have
>>>>>> the date memorized.  What I've written is mostly positive and been
>>>> praised
>>>>>> by the board for our handling of a hard situation.  You're all making
>> a
>>>>>> liar out of me. :)
>>>>>> 
>>>>>> I was delicate in the first situation, but now I have to be a bit more
>>>>>> direct.
>>>>>> 
>>>>>> 
>>>>>> In the June 27th incident we had Andy committing code, Romain
>> reverting
>>>>>> it, the two exchanging insults for one hour till Andy quit complaining
>>>> that
>>>>>> he's working in his spare time implies Romain is killing the project.
>>>> Mark
>>>>>> joins attempting to take some heat off of Romain.  Jon joins
>> attempting
>>>> to
>>>>>> be as neutral as possible.  In the end both Mark and Jon apologize.
>>>> Andy's
>>>>>> code stays reverted.
>>>>>> 
>>>>>> In this incident Andy committed code. Mark and Romain begin arguing.
>>>>>> Insults are exchanged for one hour till Andy quits complaining that
>> he's
>>>>>> working in his spare time and implies Romain is killing the project.
>>>> Jon
>>>>>> joins attempting to be as neutral as possible.  In the end both Mark
>> and
>>>>>> Jon apologize.  Andy's code stays reverted.  This time it's all
>>>> Tomitribe's
>>>>>> fault.
>>>>>> 
>>>>>> 
>>>>>> Am I the only one to notice a pattern?  That pattern is not one
>> person's
>>>>>> fault.  The pattern is we are behaving like children.
>>>>>> 
>>>>>> 
>>>>>> This will not get better if each of us is expecting the other guy to
>>>>>> change.  If your only response to this email is find flaws in others,
>> I
>>>>>> guarantee nothing will get better.
>>>>>> 
>>>>>> Mark, you got there in the end which is great.  You pointed out
>>>> something
>>>>>> you could have done better and something Andy could do better.  That's
>>>> the
>>>>>> right pattern.  People are much more willing to accept feedback when
>>>> they
>>>>>> see you're also willing to accept it.
>>>>>> 
>>>>>> We need to get there sooner next time and we need more than one person
>>>>>> doing it.
>>>>>> 
>>>>>> 
>>>>>> So with all that said, how do we turn this into an awesome learning
>>>>>> experience that makes us stronger?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -David
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <
>> agumbrecht@tomitribe.com
>>>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>> Added project stubs: https://github.com/apache/
>>>>>> tomee/tree/master/microprofile
>>>>>>> 
>>>>>>> Andy.
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Ok thanks guys.
>>>>>>>> @Rudy, you are most welcome :)
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Jean-Louis Monteiro
>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>> http://www.tomitribe.com
>>>>>>>> 
>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>>>>> rdebusscher@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I think it is a very important spec, also for non-microprofile
>>>>>>>>> implementations as it can enhance the interoperability of all
>>>> servers.
>>>>>>>>> 
>>>>>>>>> I'm also very interested in the implementation (and want to help a
>>>> bit
>>>>>> with
>>>>>>>>> it also :) )
>>>>>>>>> 
>>>>>>>>> regards
>>>>>>>>> Rudy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
>> <struberg@yahoo.de.invalid
>>>>> 
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> To clarify this even further:
>>>>>>>>>> The Geronimo Server is now officially dead.
>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a few
>>>>>> modular
>>>>>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>>>>>>>> geronimo-config, xbean-finder, etc
>>>>>>>>>> 
>>>>>>>>>> Of course it would probably make sense to fold those 2 projects
>>>>>> together,
>>>>>>>>>> as already discussed in the past.
>>>>>>>>>> I'm still all open to it, but I have an important criterium to
>>>> fulfil:
>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
>> that
>>>>>> TomEE
>>>>>>>>>> would become an 'Umbrella project'.
>>>>>>>>>> And further that we would need a new name for those portable
>> parts.
>>>>>>>>>> They would effectively be mainatained by the TomEE community
>> (which
>>>>>> has a
>>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>>>>>>>> recognized separately from TomEE.
>>>>>>>>>> 
>>>>>>>>>> Otherwise people will assume that those parts only work within
>>>> TomEE -
>>>>>>>>>> where in reality they would even work on WildFly or Liberty, etc.
>> or
>>>>>>>>> even a
>>>>>>>>>> naked Tomcat.
>>>>>>>>>> Got me?
>>>>>>>>>> 
>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
>> Department'
>>>> :)
>>>>>>>>>> 
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>> 
>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to
>>>> ease
>>>>>>>>>> backward compatibility.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>> :
>>>>>>>>>>> 
>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>>>>>> osantana@tomitribe.com>:
>>>>>>>>>>> 
>>>>>>>>>>>> Guys, I have a question:
>>>>>>>>>>>> 
>>>>>>>>>>>> Why not a project to each implementation?
>>>>>>>>>>>> 
>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>>>>> 
>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>>>>> 
>>>>>>>>>>> long story short: we learnt from the past errors and since always
>>>> the
>>>>>>>>>> same
>>>>>>>>>>> people work on these projects it is better to not split it
>> accross
>>>> N
>>>>>>>>>>> communities since
>>>>>>>>>>> it leads to a lot of efforts for these people. Having a single
>>>>>> umbrella
>>>>>>>>>>> project with N subprojects reduces the administrative work etc
>> and
>>>>>>>>>> enhance
>>>>>>>>>>> the projects productivity.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi JL,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
>> already
>>>>>>>>> spoke
>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at the
>> same
>>>>>>>>> place
>>>>>>>>>>>> for
>>>>>>>>>>>>> the foundation.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/
>>>>>>>>>>>>> rmannibucau> |
>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>>>>>> ee-8-high-performance>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>>>>>> jlmonteiro@tomitribe.com
>>>>>>>>>>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
>>>> implemented
>>>>>> in
>>>>>>>>>>>>> TomEE.
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Jean-Louis
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Andy Gumbrecht
>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>> http://www.tomitribe.com
>>>>>>> https://www.tomitribe.io
>>>>>>> 
>>>>>>> 
>>>>>>> Ubique
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: Let's do better

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Morning Mark,

I appreciate the feedback, but I disagree.

Adding an @Ignore on a test failing does not fix the issue (either the test
or the code)
Putting a napkin over some c... does not clean it up.

This is not the first time it happens, so I'd rather prefer the community
to vent, put the problems on the table so we can tackle them, instead of
pretending the problem is solved and in one month from now, we are in the
same position.

I do not plan to put fuel on the fire.

I'm suggesting that instead of shooting at the daughter and therefor not
getting any chance to know it was a present, one should first ask
questions.
"My sweet heart, why do you have the keys of the car?"
"What do you plan to do with them?"

I was trying to add some guidance to your good example of the daughter and
her father.

You are a father, so am I.

Hope it helps.



--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> Please all stop putting fuel into the fire.
>
> LieGrue,
> strub
>
>
> > Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com>:
> >
> > Instead of shooting to someone or start arguing. Simply asking would take
> > all misunderstand off and avoid this disgusting mess.
> >
> > Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
> > écrit :
> >
> >> +1  words - and especially brief once as emails - are just a mapping
> from
> >> the reality to some 'transport mechanism' (Claude Shannon sender
> theoreme
> >> anyone?).
> >> And of course each 'map' is a huge simplification from the reality and
> >> thus prone to be misinterpreted.
> >>
> >> The important part here is that those clashes bring up some difference
> in
> >> view.
> >> And yes, I also think this has nothing to do with immature or childish.
> We
> >> are all just passionate.
> >> So the first very important step is to identify the pain point.
> >>
> >> For Romain and me, etc is to avoid duplication of work which already got
> >> done in other ASF projects.
> >> And to not have those modules hardcoded bound to the TomEE Application
> >> Server but to be reusable for other projects.
> >> Please note that I'm talking about the Appliation Server only and not
> >> about the TomEE project as governance body.
> >>
> >> I also had an important lesson in the 90s:
> >>
> >> If you have a problem
> >> 1.) solve it
> >> 2.) if you cannot solve it, live with it
> >> 3.) if you cannot live with it, leave it.
> >>
> >> More generally:
> >> There are some points which totally doesn't matter to someone.
> >> There are other points which we would love to see a certain outcome, but
> >> we would also perfectly accept a compromise.
> >> And is also a category of points where we simply cannot live with a
> >> compromise. Or where we would simply stop being part of it.
> >>
> >> In the current situation it's pretty easy. NONE of the cases fits.
> >> It was simply a misunderstanding.
> >> Andy wanted to commit samples and integrate mp-config to TomEE.
> >> This is perfectly fine, but the commit comment and the location was very
> >> easy to get misinterpreted.
> >> And that's exactly what happens.
> >>
> >> That's like you forbid your daughter to use your car and then she
> snatches
> >> your keys.
> >> You shout at her, but only after she bursts out in tears you find out
> that
> >> she only wanted to wash your car as a birthday present...
> >>
> >> And now back to work pretty please ;)
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
> >>>
> >>> All,
> >>>
> >>> I followed what David calls "incidents" or "childish" quite closely in
> >> the
> >>> past. Why? Cause such situations are quite familiar to me. I've been
> >> there
> >>> thousands of times and what I can tell for granted is that non of these
> >>> situations are neither "incidents" nor "childish".
> >>>
> >>> As a matter of fact each individual has a certain believe system on one
> >>> hand and on the other hand lives on his/her own island. The latter I
> use
> >> as
> >>> an explanation for the fact that we all have our own perception of what
> >> we
> >>> think reality is and it usually isn't congruent with the perception of
> >>> others. If either your believe systems are conflicting or your
> perception
> >>> of what you think is reality are clashing, you usually have such
> >>> "incidents".
> >>>
> >>> That said I learned the hard way that usually you are not fighting,
> like
> >> in
> >>> this case, about backed out code but it's usually something
> >> inter-personal.
> >>> What makes me wondering especially if I think about all the Twitter and
> >>> Facebook posts where I see you guys hanging out together is, that such,
> >> as
> >>> I suspect it inter-personal conflicts, erupt on the mailing list or
> over
> >>> code commits, where my naive understanding is, that you could talk
> >>> face-to-face to nail down what really drives you crazy.
> >>>
> >>> What I learned is that it doesn't quite help, neither from the
> >> perspective
> >>> of somebody that is involved, nor from the perspective of somebody who
> >> is a
> >>> leader to finger point or to call out individuals. In the end you
> turned
> >>> this into a mess and thus you have to fix it TOGETHER. If necessary you
> >>> could even pull in a coach from outside. I for myself applied for a
> coach
> >>> back in 2015. It's not a silver bullet and does not fix everything you
> >>> screwed up in the past but it sometimes helps to have somebody with a
> >>> neutral view and another opinion.
> >>>
> >>> In the end my perception of reality on my little island is that you all
> >>> bond a very strong team. I saw and worked with teams that were no real
> >> team
> >>> in the end. In your case I don't have such a perception and thus I
> >> believe
> >>> that you get this sorted out in a sustainable manner. Take it as a
> growth
> >>> opportunity!
> >>>
> >>> Cheers
> >>> Daniel
> >>>
> >>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <
> david.blevins@gmail.com>
> >>> wrote:
> >>>
> >>>> Ok, community, we have to have another quick talk and then hopefully
> we
> >>>> can go back to being awesome.
> >>>>
> >>>> This thread got very negative and bares a striking resemblance to the
> >>>> "Suffocating Development Environment" thread from the June 27th
> >> incident.
> >>>> Yes, I've written about it enough times in the board reports that I
> have
> >>>> the date memorized.  What I've written is mostly positive and been
> >> praised
> >>>> by the board for our handling of a hard situation.  You're all making
> a
> >>>> liar out of me. :)
> >>>>
> >>>> I was delicate in the first situation, but now I have to be a bit more
> >>>> direct.
> >>>>
> >>>>
> >>>> In the June 27th incident we had Andy committing code, Romain
> reverting
> >>>> it, the two exchanging insults for one hour till Andy quit complaining
> >> that
> >>>> he's working in his spare time implies Romain is killing the project.
> >> Mark
> >>>> joins attempting to take some heat off of Romain.  Jon joins
> attempting
> >> to
> >>>> be as neutral as possible.  In the end both Mark and Jon apologize.
> >> Andy's
> >>>> code stays reverted.
> >>>>
> >>>> In this incident Andy committed code. Mark and Romain begin arguing.
> >>>> Insults are exchanged for one hour till Andy quits complaining that
> he's
> >>>> working in his spare time and implies Romain is killing the project.
> >> Jon
> >>>> joins attempting to be as neutral as possible.  In the end both Mark
> and
> >>>> Jon apologize.  Andy's code stays reverted.  This time it's all
> >> Tomitribe's
> >>>> fault.
> >>>>
> >>>>
> >>>> Am I the only one to notice a pattern?  That pattern is not one
> person's
> >>>> fault.  The pattern is we are behaving like children.
> >>>>
> >>>>
> >>>> This will not get better if each of us is expecting the other guy to
> >>>> change.  If your only response to this email is find flaws in others,
> I
> >>>> guarantee nothing will get better.
> >>>>
> >>>> Mark, you got there in the end which is great.  You pointed out
> >> something
> >>>> you could have done better and something Andy could do better.  That's
> >> the
> >>>> right pattern.  People are much more willing to accept feedback when
> >> they
> >>>> see you're also willing to accept it.
> >>>>
> >>>> We need to get there sooner next time and we need more than one person
> >>>> doing it.
> >>>>
> >>>>
> >>>> So with all that said, how do we turn this into an awesome learning
> >>>> experience that makes us stronger?
> >>>>
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>>
> >>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <
> agumbrecht@tomitribe.com
> >>>
> >>>> wrote:
> >>>>>
> >>>>> Added project stubs: https://github.com/apache/
> >>>> tomee/tree/master/microprofile
> >>>>>
> >>>>> Andy.
> >>>>>
> >>>>>
> >>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Ok thanks guys.
> >>>>>> @Rudy, you are most welcome :)
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Louis Monteiro
> >>>>>> http://twitter.com/jlouismonteiro
> >>>>>> http://www.tomitribe.com
> >>>>>>
> >>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >>>> rdebusscher@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I think it is a very important spec, also for non-microprofile
> >>>>>>> implementations as it can enhance the interoperability of all
> >> servers.
> >>>>>>>
> >>>>>>> I'm also very interested in the implementation (and want to help a
> >> bit
> >>>> with
> >>>>>>> it also :) )
> >>>>>>>
> >>>>>>> regards
> >>>>>>> Rudy
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2 February 2018 at 11:23, Mark Struberg
> <struberg@yahoo.de.invalid
> >>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> To clarify this even further:
> >>>>>>>> The Geronimo Server is now officially dead.
> >>>>>>>> But the Geronimo project is not. It alredy contains quite a few
> >>>> modular
> >>>>>>>> parts which are reused in many ASF projects and also outside.
> >>>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >>>>>>>> geronimo-config, xbean-finder, etc
> >>>>>>>>
> >>>>>>>> Of course it would probably make sense to fold those 2 projects
> >>>> together,
> >>>>>>>> as already discussed in the past.
> >>>>>>>> I'm still all open to it, but I have an important criterium to
> >> fulfil:
> >>>>>>>> If we move those portable parts to TomEE, then this would mean
> that
> >>>> TomEE
> >>>>>>>> would become an 'Umbrella project'.
> >>>>>>>> And further that we would need a new name for those portable
> parts.
> >>>>>>>> They would effectively be mainatained by the TomEE community
> (which
> >>>> has a
> >>>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
> >>>>>>>> recognized separately from TomEE.
> >>>>>>>>
> >>>>>>>> Otherwise people will assume that those parts only work within
> >> TomEE -
> >>>>>>>> where in reality they would even work on WildFly or Liberty, etc.
> or
> >>>>>>> even a
> >>>>>>>> naked Tomcat.
> >>>>>>>> Got me?
> >>>>>>>>
> >>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> Department'
> >> :)
> >>>>>>>>
> >>>>>>>> LieGrue,
> >>>>>>>> strub
> >>>>>>>>
> >>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to
> >> ease
> >>>>>>>> backward compatibility.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>>>>>> rmannibucau@gmail.com
> >>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>>>>>> osantana@tomitribe.com>:
> >>>>>>>>>
> >>>>>>>>>> Guys, I have a question:
> >>>>>>>>>>
> >>>>>>>>>> Why not a project to each implementation?
> >>>>>>>>>>
> >>>>>>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> This way I can use just a specific if I want also.
> >>>>>>>>>>
> >>>>>>>>> exactly the goal and user usage AFAIK ;)
> >>>>>>>>>
> >>>>>>>>> long story short: we learnt from the past errors and since always
> >> the
> >>>>>>>> same
> >>>>>>>>> people work on these projects it is better to not split it
> accross
> >> N
> >>>>>>>>> communities since
> >>>>>>>>> it leads to a lot of efforts for these people. Having a single
> >>>> umbrella
> >>>>>>>>> project with N subprojects reduces the administrative work etc
> and
> >>>>>>>> enhance
> >>>>>>>>> the projects productivity.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi JL,
> >>>>>>>>>>>
> >>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
> already
> >>>>>>> spoke
> >>>>>>>>>>> about it I think. Would probably saner to keep it all at the
> same
> >>>>>>> place
> >>>>>>>>>> for
> >>>>>>>>>>> the foundation.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/
> >>>>>>>>>>> rmannibucau> |
> >>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>>>>>> ee-8-high-performance>
> >>>>>>>>>>>
> >>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>>>>>> jlmonteiro@tomitribe.com
> >>>>>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
> >> implemented
> >>>> in
> >>>>>>>>>>> TomEE.
> >>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jean-Louis
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>> --
> >>>>> Andy Gumbrecht
> >>>>> https://twitter.com/AndyGeeDe
> >>>>> http://www.tomitribe.com
> >>>>> https://www.tomitribe.io
> >>>>>
> >>>>>
> >>>>> Ubique
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: Let's do better

[Mark Struberg <st...@yahoo.de.INVALID>]

Please all stop putting fuel into the fire. 

LieGrue,
strub


> Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <jl...@tomitribe.com>:
> 
> Instead of shooting to someone or start arguing. Simply asking would take
> all misunderstand off and avoid this disgusting mess.
> 
> Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
> écrit :
> 
>> +1  words - and especially brief once as emails - are just a mapping from
>> the reality to some 'transport mechanism' (Claude Shannon sender theoreme
>> anyone?).
>> And of course each 'map' is a huge simplification from the reality and
>> thus prone to be misinterpreted.
>> 
>> The important part here is that those clashes bring up some difference in
>> view.
>> And yes, I also think this has nothing to do with immature or childish. We
>> are all just passionate.
>> So the first very important step is to identify the pain point.
>> 
>> For Romain and me, etc is to avoid duplication of work which already got
>> done in other ASF projects.
>> And to not have those modules hardcoded bound to the TomEE Application
>> Server but to be reusable for other projects.
>> Please note that I'm talking about the Appliation Server only and not
>> about the TomEE project as governance body.
>> 
>> I also had an important lesson in the 90s:
>> 
>> If you have a problem
>> 1.) solve it
>> 2.) if you cannot solve it, live with it
>> 3.) if you cannot live with it, leave it.
>> 
>> More generally:
>> There are some points which totally doesn't matter to someone.
>> There are other points which we would love to see a certain outcome, but
>> we would also perfectly accept a compromise.
>> And is also a category of points where we simply cannot live with a
>> compromise. Or where we would simply stop being part of it.
>> 
>> In the current situation it's pretty easy. NONE of the cases fits.
>> It was simply a misunderstanding.
>> Andy wanted to commit samples and integrate mp-config to TomEE.
>> This is perfectly fine, but the commit comment and the location was very
>> easy to get misinterpreted.
>> And that's exactly what happens.
>> 
>> That's like you forbid your daughter to use your car and then she snatches
>> your keys.
>> You shout at her, but only after she bursts out in tears you find out that
>> she only wanted to wash your car as a birthday present...
>> 
>> And now back to work pretty please ;)
>> 
>> LieGrue,
>> strub
>> 
>>> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
>>> 
>>> All,
>>> 
>>> I followed what David calls "incidents" or "childish" quite closely in
>> the
>>> past. Why? Cause such situations are quite familiar to me. I've been
>> there
>>> thousands of times and what I can tell for granted is that non of these
>>> situations are neither "incidents" nor "childish".
>>> 
>>> As a matter of fact each individual has a certain believe system on one
>>> hand and on the other hand lives on his/her own island. The latter I use
>> as
>>> an explanation for the fact that we all have our own perception of what
>> we
>>> think reality is and it usually isn't congruent with the perception of
>>> others. If either your believe systems are conflicting or your perception
>>> of what you think is reality are clashing, you usually have such
>>> "incidents".
>>> 
>>> That said I learned the hard way that usually you are not fighting, like
>> in
>>> this case, about backed out code but it's usually something
>> inter-personal.
>>> What makes me wondering especially if I think about all the Twitter and
>>> Facebook posts where I see you guys hanging out together is, that such,
>> as
>>> I suspect it inter-personal conflicts, erupt on the mailing list or over
>>> code commits, where my naive understanding is, that you could talk
>>> face-to-face to nail down what really drives you crazy.
>>> 
>>> What I learned is that it doesn't quite help, neither from the
>> perspective
>>> of somebody that is involved, nor from the perspective of somebody who
>> is a
>>> leader to finger point or to call out individuals. In the end you turned
>>> this into a mess and thus you have to fix it TOGETHER. If necessary you
>>> could even pull in a coach from outside. I for myself applied for a coach
>>> back in 2015. It's not a silver bullet and does not fix everything you
>>> screwed up in the past but it sometimes helps to have somebody with a
>>> neutral view and another opinion.
>>> 
>>> In the end my perception of reality on my little island is that you all
>>> bond a very strong team. I saw and worked with teams that were no real
>> team
>>> in the end. In your case I don't have such a perception and thus I
>> believe
>>> that you get this sorted out in a sustainable manner. Take it as a growth
>>> opportunity!
>>> 
>>> Cheers
>>> Daniel
>>> 
>>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <da...@gmail.com>
>>> wrote:
>>> 
>>>> Ok, community, we have to have another quick talk and then hopefully we
>>>> can go back to being awesome.
>>>> 
>>>> This thread got very negative and bares a striking resemblance to the
>>>> "Suffocating Development Environment" thread from the June 27th
>> incident.
>>>> Yes, I've written about it enough times in the board reports that I have
>>>> the date memorized.  What I've written is mostly positive and been
>> praised
>>>> by the board for our handling of a hard situation.  You're all making a
>>>> liar out of me. :)
>>>> 
>>>> I was delicate in the first situation, but now I have to be a bit more
>>>> direct.
>>>> 
>>>> 
>>>> In the June 27th incident we had Andy committing code, Romain reverting
>>>> it, the two exchanging insults for one hour till Andy quit complaining
>> that
>>>> he's working in his spare time implies Romain is killing the project.
>> Mark
>>>> joins attempting to take some heat off of Romain.  Jon joins attempting
>> to
>>>> be as neutral as possible.  In the end both Mark and Jon apologize.
>> Andy's
>>>> code stays reverted.
>>>> 
>>>> In this incident Andy committed code. Mark and Romain begin arguing.
>>>> Insults are exchanged for one hour till Andy quits complaining that he's
>>>> working in his spare time and implies Romain is killing the project.
>> Jon
>>>> joins attempting to be as neutral as possible.  In the end both Mark and
>>>> Jon apologize.  Andy's code stays reverted.  This time it's all
>> Tomitribe's
>>>> fault.
>>>> 
>>>> 
>>>> Am I the only one to notice a pattern?  That pattern is not one person's
>>>> fault.  The pattern is we are behaving like children.
>>>> 
>>>> 
>>>> This will not get better if each of us is expecting the other guy to
>>>> change.  If your only response to this email is find flaws in others, I
>>>> guarantee nothing will get better.
>>>> 
>>>> Mark, you got there in the end which is great.  You pointed out
>> something
>>>> you could have done better and something Andy could do better.  That's
>> the
>>>> right pattern.  People are much more willing to accept feedback when
>> they
>>>> see you're also willing to accept it.
>>>> 
>>>> We need to get there sooner next time and we need more than one person
>>>> doing it.
>>>> 
>>>> 
>>>> So with all that said, how do we turn this into an awesome learning
>>>> experience that makes us stronger?
>>>> 
>>>> 
>>>> 
>>>> -David
>>>> 
>>>> 
>>>> 
>>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <agumbrecht@tomitribe.com
>>> 
>>>> wrote:
>>>>> 
>>>>> Added project stubs: https://github.com/apache/
>>>> tomee/tree/master/microprofile
>>>>> 
>>>>> Andy.
>>>>> 
>>>>> 
>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Ok thanks guys.
>>>>>> @Rudy, you are most welcome :)
>>>>>> 
>>>>>> --
>>>>>> Jean-Louis Monteiro
>>>>>> http://twitter.com/jlouismonteiro
>>>>>> http://www.tomitribe.com
>>>>>> 
>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>>> rdebusscher@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I think it is a very important spec, also for non-microprofile
>>>>>>> implementations as it can enhance the interoperability of all
>> servers.
>>>>>>> 
>>>>>>> I'm also very interested in the implementation (and want to help a
>> bit
>>>> with
>>>>>>> it also :) )
>>>>>>> 
>>>>>>> regards
>>>>>>> Rudy
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> To clarify this even further:
>>>>>>>> The Geronimo Server is now officially dead.
>>>>>>>> But the Geronimo project is not. It alredy contains quite a few
>>>> modular
>>>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>>>>>> geronimo-config, xbean-finder, etc
>>>>>>>> 
>>>>>>>> Of course it would probably make sense to fold those 2 projects
>>>> together,
>>>>>>>> as already discussed in the past.
>>>>>>>> I'm still all open to it, but I have an important criterium to
>> fulfil:
>>>>>>>> If we move those portable parts to TomEE, then this would mean that
>>>> TomEE
>>>>>>>> would become an 'Umbrella project'.
>>>>>>>> And further that we would need a new name for those portable parts.
>>>>>>>> They would effectively be mainatained by the TomEE community (which
>>>> has a
>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>>>>>> recognized separately from TomEE.
>>>>>>>> 
>>>>>>>> Otherwise people will assume that those parts only work within
>> TomEE -
>>>>>>>> where in reality they would even work on WildFly or Liberty, etc. or
>>>>>>> even a
>>>>>>>> naked Tomcat.
>>>>>>>> Got me?
>>>>>>>> 
>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department'
>> :)
>>>>>>>> 
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>> 
>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to
>> ease
>>>>>>>> backward compatibility.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com
>>>>>>>>> :
>>>>>>>>> 
>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>>>> osantana@tomitribe.com>:
>>>>>>>>> 
>>>>>>>>>> Guys, I have a question:
>>>>>>>>>> 
>>>>>>>>>> Why not a project to each implementation?
>>>>>>>>>> 
>>>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>>> 
>>>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>>> 
>>>>>>>>> long story short: we learnt from the past errors and since always
>> the
>>>>>>>> same
>>>>>>>>> people work on these projects it is better to not split it accross
>> N
>>>>>>>>> communities since
>>>>>>>>> it leads to a lot of efforts for these people. Having a single
>>>> umbrella
>>>>>>>>> project with N subprojects reduces the administrative work etc and
>>>>>>>> enhance
>>>>>>>>> the projects productivity.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi JL,
>>>>>>>>>>> 
>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John already
>>>>>>> spoke
>>>>>>>>>>> about it I think. Would probably saner to keep it all at the same
>>>>>>> place
>>>>>>>>>> for
>>>>>>>>>>> the foundation.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>>>>>>> rmannibucau> |
>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>>>> ee-8-high-performance>
>>>>>>>>>>> 
>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>>>> jlmonteiro@tomitribe.com
>>>>>>>>>>> :
>>>>>>>>>>> 
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>> 
>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
>> implemented
>>>> in
>>>>>>>>>>> TomEE.
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>> 
>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>>> 
>>>>>>>>>>>> Jean-Louis
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>> 
>>>>>>>> 
>>>>> 
>>>>> --
>>>>> Andy Gumbrecht
>>>>> https://twitter.com/AndyGeeDe
>>>>> http://www.tomitribe.com
>>>>> https://www.tomitribe.io
>>>>> 
>>>>> 
>>>>> Ubique
>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: Let's do better

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Instead of shooting to someone or start arguing. Simply asking would take
all misunderstand off and avoid this disgusting mess.

Le 13 févr. 2018 08:33, "Mark Struberg" <st...@yahoo.de.invalid> a
écrit :

> +1  words - and especially brief once as emails - are just a mapping from
> the reality to some 'transport mechanism' (Claude Shannon sender theoreme
> anyone?).
> And of course each 'map' is a huge simplification from the reality and
> thus prone to be misinterpreted.
>
> The important part here is that those clashes bring up some difference in
> view.
> And yes, I also think this has nothing to do with immature or childish. We
> are all just passionate.
> So the first very important step is to identify the pain point.
>
> For Romain and me, etc is to avoid duplication of work which already got
> done in other ASF projects.
> And to not have those modules hardcoded bound to the TomEE Application
> Server but to be reusable for other projects.
> Please note that I'm talking about the Appliation Server only and not
> about the TomEE project as governance body.
>
> I also had an important lesson in the 90s:
>
> If you have a problem
> 1.) solve it
> 2.) if you cannot solve it, live with it
> 3.) if you cannot live with it, leave it.
>
> More generally:
> There are some points which totally doesn't matter to someone.
> There are other points which we would love to see a certain outcome, but
> we would also perfectly accept a compromise.
> And is also a category of points where we simply cannot live with a
> compromise. Or where we would simply stop being part of it.
>
> In the current situation it's pretty easy. NONE of the cases fits.
> It was simply a misunderstanding.
> Andy wanted to commit samples and integrate mp-config to TomEE.
> This is perfectly fine, but the commit comment and the location was very
> easy to get misinterpreted.
> And that's exactly what happens.
>
> That's like you forbid your daughter to use your car and then she snatches
> your keys.
> You shout at her, but only after she bursts out in tears you find out that
> she only wanted to wash your car as a birthday present...
>
> And now back to work pretty please ;)
>
> LieGrue,
> strub
>
> > Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
> >
> > All,
> >
> > I followed what David calls "incidents" or "childish" quite closely in
> the
> > past. Why? Cause such situations are quite familiar to me. I've been
> there
> > thousands of times and what I can tell for granted is that non of these
> > situations are neither "incidents" nor "childish".
> >
> > As a matter of fact each individual has a certain believe system on one
> > hand and on the other hand lives on his/her own island. The latter I use
> as
> > an explanation for the fact that we all have our own perception of what
> we
> > think reality is and it usually isn't congruent with the perception of
> > others. If either your believe systems are conflicting or your perception
> > of what you think is reality are clashing, you usually have such
> > "incidents".
> >
> > That said I learned the hard way that usually you are not fighting, like
> in
> > this case, about backed out code but it's usually something
> inter-personal.
> > What makes me wondering especially if I think about all the Twitter and
> > Facebook posts where I see you guys hanging out together is, that such,
> as
> > I suspect it inter-personal conflicts, erupt on the mailing list or over
> > code commits, where my naive understanding is, that you could talk
> > face-to-face to nail down what really drives you crazy.
> >
> > What I learned is that it doesn't quite help, neither from the
> perspective
> > of somebody that is involved, nor from the perspective of somebody who
> is a
> > leader to finger point or to call out individuals. In the end you turned
> > this into a mess and thus you have to fix it TOGETHER. If necessary you
> > could even pull in a coach from outside. I for myself applied for a coach
> > back in 2015. It's not a silver bullet and does not fix everything you
> > screwed up in the past but it sometimes helps to have somebody with a
> > neutral view and another opinion.
> >
> > In the end my perception of reality on my little island is that you all
> > bond a very strong team. I saw and worked with teams that were no real
> team
> > in the end. In your case I don't have such a perception and thus I
> believe
> > that you get this sorted out in a sustainable manner. Take it as a growth
> > opportunity!
> >
> > Cheers
> > Daniel
> >
> > On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <da...@gmail.com>
> > wrote:
> >
> >> Ok, community, we have to have another quick talk and then hopefully we
> >> can go back to being awesome.
> >>
> >> This thread got very negative and bares a striking resemblance to the
> >> "Suffocating Development Environment" thread from the June 27th
> incident.
> >> Yes, I've written about it enough times in the board reports that I have
> >> the date memorized.  What I've written is mostly positive and been
> praised
> >> by the board for our handling of a hard situation.  You're all making a
> >> liar out of me. :)
> >>
> >> I was delicate in the first situation, but now I have to be a bit more
> >> direct.
> >>
> >>
> >> In the June 27th incident we had Andy committing code, Romain reverting
> >> it, the two exchanging insults for one hour till Andy quit complaining
> that
> >> he's working in his spare time implies Romain is killing the project.
> Mark
> >> joins attempting to take some heat off of Romain.  Jon joins attempting
> to
> >> be as neutral as possible.  In the end both Mark and Jon apologize.
> Andy's
> >> code stays reverted.
> >>
> >> In this incident Andy committed code. Mark and Romain begin arguing.
> >> Insults are exchanged for one hour till Andy quits complaining that he's
> >> working in his spare time and implies Romain is killing the project.
> Jon
> >> joins attempting to be as neutral as possible.  In the end both Mark and
> >> Jon apologize.  Andy's code stays reverted.  This time it's all
> Tomitribe's
> >> fault.
> >>
> >>
> >> Am I the only one to notice a pattern?  That pattern is not one person's
> >> fault.  The pattern is we are behaving like children.
> >>
> >>
> >> This will not get better if each of us is expecting the other guy to
> >> change.  If your only response to this email is find flaws in others, I
> >> guarantee nothing will get better.
> >>
> >> Mark, you got there in the end which is great.  You pointed out
> something
> >> you could have done better and something Andy could do better.  That's
> the
> >> right pattern.  People are much more willing to accept feedback when
> they
> >> see you're also willing to accept it.
> >>
> >> We need to get there sooner next time and we need more than one person
> >> doing it.
> >>
> >>
> >> So with all that said, how do we turn this into an awesome learning
> >> experience that makes us stronger?
> >>
> >>
> >>
> >> -David
> >>
> >>
> >>
> >>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <agumbrecht@tomitribe.com
> >
> >> wrote:
> >>>
> >>> Added project stubs: https://github.com/apache/
> >> tomee/tree/master/microprofile
> >>>
> >>> Andy.
> >>>
> >>>
> >>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >>>> Hi,
> >>>>
> >>>> Ok thanks guys.
> >>>> @Rudy, you are most welcome :)
> >>>>
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >> rdebusscher@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> I think it is a very important spec, also for non-microprofile
> >>>>> implementations as it can enhance the interoperability of all
> servers.
> >>>>>
> >>>>> I'm also very interested in the implementation (and want to help a
> bit
> >> with
> >>>>> it also :) )
> >>>>>
> >>>>> regards
> >>>>> Rudy
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
> >
> >>>>> wrote:
> >>>>>
> >>>>>> To clarify this even further:
> >>>>>> The Geronimo Server is now officially dead.
> >>>>>> But the Geronimo project is not. It alredy contains quite a few
> >> modular
> >>>>>> parts which are reused in many ASF projects and also outside.
> >>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >>>>>> geronimo-config, xbean-finder, etc
> >>>>>>
> >>>>>> Of course it would probably make sense to fold those 2 projects
> >> together,
> >>>>>> as already discussed in the past.
> >>>>>> I'm still all open to it, but I have an important criterium to
> fulfil:
> >>>>>> If we move those portable parts to TomEE, then this would mean that
> >> TomEE
> >>>>>> would become an 'Umbrella project'.
> >>>>>> And further that we would need a new name for those portable parts.
> >>>>>> They would effectively be mainatained by the TomEE community (which
> >> has a
> >>>>>> big overlap with Geronimo anyway) but those parts must clearly be
> >>>>>> recognized separately from TomEE.
> >>>>>>
> >>>>>> Otherwise people will assume that those parts only work within
> TomEE -
> >>>>>> where in reality they would even work on WildFly or Liberty, etc. or
> >>>>> even a
> >>>>>> naked Tomcat.
> >>>>>> Got me?
> >>>>>>
> >>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department'
> :)
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>> PS: I'd also love to keep the org.apache.geronimo package name to
> ease
> >>>>>> backward compatibility.
> >>>>>>
> >>>>>>
> >>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com
> >>>>>>> :
> >>>>>>>
> >>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>>>> osantana@tomitribe.com>:
> >>>>>>>
> >>>>>>>> Guys, I have a question:
> >>>>>>>>
> >>>>>>>> Why not a project to each implementation?
> >>>>>>>>
> >>>>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>>>
> >>>>>>>
> >>>>>>>> This way I can use just a specific if I want also.
> >>>>>>>>
> >>>>>>> exactly the goal and user usage AFAIK ;)
> >>>>>>>
> >>>>>>> long story short: we learnt from the past errors and since always
> the
> >>>>>> same
> >>>>>>> people work on these projects it is better to not split it accross
> N
> >>>>>>> communities since
> >>>>>>> it leads to a lot of efforts for these people. Having a single
> >> umbrella
> >>>>>>> project with N subprojects reduces the administrative work etc and
> >>>>>> enhance
> >>>>>>> the projects productivity.
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>>>> rmannibucau@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi JL,
> >>>>>>>>>
> >>>>>>>>> Microprofile apache effort is hosted in geronimo and John already
> >>>>> spoke
> >>>>>>>>> about it I think. Would probably saner to keep it all at the same
> >>>>> place
> >>>>>>>> for
> >>>>>>>>> the foundation.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Romain Manni-Bucau
> >>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >>>>>>>>> rmannibucau> |
> >>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>>>> ee-8-high-performance>
> >>>>>>>>>
> >>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>>>> jlmonteiro@tomitribe.com
> >>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> I was wondering if we could have the Microprofile JWT
> implemented
> >> in
> >>>>>>>>> TomEE.
> >>>>>>>>>> What do you think?
> >>>>>>>>>>
> >>>>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>>>
> >>>>>>>>>> Jean-Louis
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>
> >>>>>>
> >>>
> >>> --
> >>> Andy Gumbrecht
> >>> https://twitter.com/AndyGeeDe
> >>> http://www.tomitribe.com
> >>> https://www.tomitribe.io
> >>>
> >>>
> >>> Ubique
> >>>
> >>
> >>
>
>

Re: Let's do better

[Mark Struberg <st...@yahoo.de.INVALID>]

+1  words - and especially brief once as emails - are just a mapping from the reality to some 'transport mechanism' (Claude Shannon sender theoreme anyone?).
And of course each 'map' is a huge simplification from the reality and thus prone to be misinterpreted.

The important part here is that those clashes bring up some difference in view. 
And yes, I also think this has nothing to do with immature or childish. We are all just passionate.
So the first very important step is to identify the pain point. 

For Romain and me, etc is to avoid duplication of work which already got done in other ASF projects.
And to not have those modules hardcoded bound to the TomEE Application Server but to be reusable for other projects. 
Please note that I'm talking about the Appliation Server only and not about the TomEE project as governance body.

I also had an important lesson in the 90s:

If you have a problem
1.) solve it
2.) if you cannot solve it, live with it
3.) if you cannot live with it, leave it.

More generally:
There are some points which totally doesn't matter to someone. 
There are other points which we would love to see a certain outcome, but we would also perfectly accept a compromise.
And is also a category of points where we simply cannot live with a compromise. Or where we would simply stop being part of it.

In the current situation it's pretty easy. NONE of the cases fits. 
It was simply a misunderstanding. 
Andy wanted to commit samples and integrate mp-config to TomEE.
This is perfectly fine, but the commit comment and the location was very easy to get misinterpreted.
And that's exactly what happens. 

That's like you forbid your daughter to use your car and then she snatches your keys.
You shout at her, but only after she bursts out in tears you find out that she only wanted to wash your car as a birthday present...

And now back to work pretty please ;)

LieGrue,
strub

> Am 13.02.2018 um 07:38 schrieb dsh <da...@gmail.com>:
> 
> All,
> 
> I followed what David calls "incidents" or "childish" quite closely in the
> past. Why? Cause such situations are quite familiar to me. I've been there
> thousands of times and what I can tell for granted is that non of these
> situations are neither "incidents" nor "childish".
> 
> As a matter of fact each individual has a certain believe system on one
> hand and on the other hand lives on his/her own island. The latter I use as
> an explanation for the fact that we all have our own perception of what we
> think reality is and it usually isn't congruent with the perception of
> others. If either your believe systems are conflicting or your perception
> of what you think is reality are clashing, you usually have such
> "incidents".
> 
> That said I learned the hard way that usually you are not fighting, like in
> this case, about backed out code but it's usually something inter-personal.
> What makes me wondering especially if I think about all the Twitter and
> Facebook posts where I see you guys hanging out together is, that such, as
> I suspect it inter-personal conflicts, erupt on the mailing list or over
> code commits, where my naive understanding is, that you could talk
> face-to-face to nail down what really drives you crazy.
> 
> What I learned is that it doesn't quite help, neither from the perspective
> of somebody that is involved, nor from the perspective of somebody who is a
> leader to finger point or to call out individuals. In the end you turned
> this into a mess and thus you have to fix it TOGETHER. If necessary you
> could even pull in a coach from outside. I for myself applied for a coach
> back in 2015. It's not a silver bullet and does not fix everything you
> screwed up in the past but it sometimes helps to have somebody with a
> neutral view and another opinion.
> 
> In the end my perception of reality on my little island is that you all
> bond a very strong team. I saw and worked with teams that were no real team
> in the end. In your case I don't have such a perception and thus I believe
> that you get this sorted out in a sustainable manner. Take it as a growth
> opportunity!
> 
> Cheers
> Daniel
> 
> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <da...@gmail.com>
> wrote:
> 
>> Ok, community, we have to have another quick talk and then hopefully we
>> can go back to being awesome.
>> 
>> This thread got very negative and bares a striking resemblance to the
>> "Suffocating Development Environment" thread from the June 27th incident.
>> Yes, I've written about it enough times in the board reports that I have
>> the date memorized.  What I've written is mostly positive and been praised
>> by the board for our handling of a hard situation.  You're all making a
>> liar out of me. :)
>> 
>> I was delicate in the first situation, but now I have to be a bit more
>> direct.
>> 
>> 
>> In the June 27th incident we had Andy committing code, Romain reverting
>> it, the two exchanging insults for one hour till Andy quit complaining that
>> he's working in his spare time implies Romain is killing the project.  Mark
>> joins attempting to take some heat off of Romain.  Jon joins attempting to
>> be as neutral as possible.  In the end both Mark and Jon apologize.  Andy's
>> code stays reverted.
>> 
>> In this incident Andy committed code. Mark and Romain begin arguing.
>> Insults are exchanged for one hour till Andy quits complaining that he's
>> working in his spare time and implies Romain is killing the project.  Jon
>> joins attempting to be as neutral as possible.  In the end both Mark and
>> Jon apologize.  Andy's code stays reverted.  This time it's all Tomitribe's
>> fault.
>> 
>> 
>> Am I the only one to notice a pattern?  That pattern is not one person's
>> fault.  The pattern is we are behaving like children.
>> 
>> 
>> This will not get better if each of us is expecting the other guy to
>> change.  If your only response to this email is find flaws in others, I
>> guarantee nothing will get better.
>> 
>> Mark, you got there in the end which is great.  You pointed out something
>> you could have done better and something Andy could do better.  That's the
>> right pattern.  People are much more willing to accept feedback when they
>> see you're also willing to accept it.
>> 
>> We need to get there sooner next time and we need more than one person
>> doing it.
>> 
>> 
>> So with all that said, how do we turn this into an awesome learning
>> experience that makes us stronger?
>> 
>> 
>> 
>> -David
>> 
>> 
>> 
>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <ag...@tomitribe.com>
>> wrote:
>>> 
>>> Added project stubs: https://github.com/apache/
>> tomee/tree/master/microprofile
>>> 
>>> Andy.
>>> 
>>> 
>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>> Hi,
>>>> 
>>>> Ok thanks guys.
>>>> @Rudy, you are most welcome :)
>>>> 
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>> 
>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>> rdebusscher@gmail.com>
>>>> wrote:
>>>> 
>>>>> I think it is a very important spec, also for non-microprofile
>>>>> implementations as it can enhance the interoperability of all servers.
>>>>> 
>>>>> I'm also very interested in the implementation (and want to help a bit
>> with
>>>>> it also :) )
>>>>> 
>>>>> regards
>>>>> Rudy
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
>>>>> wrote:
>>>>> 
>>>>>> To clarify this even further:
>>>>>> The Geronimo Server is now officially dead.
>>>>>> But the Geronimo project is not. It alredy contains quite a few
>> modular
>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>>>> geronimo-config, xbean-finder, etc
>>>>>> 
>>>>>> Of course it would probably make sense to fold those 2 projects
>> together,
>>>>>> as already discussed in the past.
>>>>>> I'm still all open to it, but I have an important criterium to fulfil:
>>>>>> If we move those portable parts to TomEE, then this would mean that
>> TomEE
>>>>>> would become an 'Umbrella project'.
>>>>>> And further that we would need a new name for those portable parts.
>>>>>> They would effectively be mainatained by the TomEE community (which
>> has a
>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>>>> recognized separately from TomEE.
>>>>>> 
>>>>>> Otherwise people will assume that those parts only work within TomEE -
>>>>>> where in reality they would even work on WildFly or Liberty, etc. or
>>>>> even a
>>>>>> naked Tomcat.
>>>>>> Got me?
>>>>>> 
>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>>>>> backward compatibility.
>>>>>> 
>>>>>> 
>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com
>>>>>>> :
>>>>>>> 
>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>> osantana@tomitribe.com>:
>>>>>>> 
>>>>>>>> Guys, I have a question:
>>>>>>>> 
>>>>>>>> Why not a project to each implementation?
>>>>>>>> 
>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>> 
>>>>>>> 
>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>> 
>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>> 
>>>>>>> long story short: we learnt from the past errors and since always the
>>>>>> same
>>>>>>> people work on these projects it is better to not split it accross N
>>>>>>> communities since
>>>>>>> it leads to a lot of efforts for these people. Having a single
>> umbrella
>>>>>>> project with N subprojects reduces the administrative work etc and
>>>>>> enhance
>>>>>>> the projects productivity.
>>>>>>> 
>>>>>>> 
>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi JL,
>>>>>>>>> 
>>>>>>>>> Microprofile apache effort is hosted in geronimo and John already
>>>>> spoke
>>>>>>>>> about it I think. Would probably saner to keep it all at the same
>>>>> place
>>>>>>>> for
>>>>>>>>> the foundation.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>>>>> rmannibucau> |
>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>> ee-8-high-performance>
>>>>>>>>> 
>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>> jlmonteiro@tomitribe.com
>>>>>>>>> :
>>>>>>>>> 
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> I was wondering if we could have the Microprofile JWT implemented
>> in
>>>>>>>>> TomEE.
>>>>>>>>>> What do you think?
>>>>>>>>>> 
>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>> 
>>>>>>>>>> Jean-Louis
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>> 
>>>>>> 
>>> 
>>> --
>>> Andy Gumbrecht
>>> https://twitter.com/AndyGeeDe
>>> http://www.tomitribe.com
>>> https://www.tomitribe.io
>>> 
>>> 
>>> Ubique
>>> 
>> 
>> 

Re: Let's do better

[dsh <da...@gmail.com>]

All,

I followed what David calls "incidents" or "childish" quite closely in the
past. Why? Cause such situations are quite familiar to me. I've been there
thousands of times and what I can tell for granted is that non of these
situations are neither "incidents" nor "childish".

As a matter of fact each individual has a certain believe system on one
hand and on the other hand lives on his/her own island. The latter I use as
an explanation for the fact that we all have our own perception of what we
think reality is and it usually isn't congruent with the perception of
others. If either your believe systems are conflicting or your perception
of what you think is reality are clashing, you usually have such
"incidents".

That said I learned the hard way that usually you are not fighting, like in
this case, about backed out code but it's usually something inter-personal.
What makes me wondering especially if I think about all the Twitter and
Facebook posts where I see you guys hanging out together is, that such, as
I suspect it inter-personal conflicts, erupt on the mailing list or over
code commits, where my naive understanding is, that you could talk
face-to-face to nail down what really drives you crazy.

What I learned is that it doesn't quite help, neither from the perspective
of somebody that is involved, nor from the perspective of somebody who is a
leader to finger point or to call out individuals. In the end you turned
this into a mess and thus you have to fix it TOGETHER. If necessary you
could even pull in a coach from outside. I for myself applied for a coach
back in 2015. It's not a silver bullet and does not fix everything you
screwed up in the past but it sometimes helps to have somebody with a
neutral view and another opinion.

In the end my perception of reality on my little island is that you all
bond a very strong team. I saw and worked with teams that were no real team
in the end. In your case I don't have such a perception and thus I believe
that you get this sorted out in a sustainable manner. Take it as a growth
opportunity!

Cheers
Daniel

On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <da...@gmail.com>
wrote:

> Ok, community, we have to have another quick talk and then hopefully we
> can go back to being awesome.
>
> This thread got very negative and bares a striking resemblance to the
> "Suffocating Development Environment" thread from the June 27th incident.
> Yes, I've written about it enough times in the board reports that I have
> the date memorized.  What I've written is mostly positive and been praised
> by the board for our handling of a hard situation.  You're all making a
> liar out of me. :)
>
> I was delicate in the first situation, but now I have to be a bit more
> direct.
>
>
> In the June 27th incident we had Andy committing code, Romain reverting
> it, the two exchanging insults for one hour till Andy quit complaining that
> he's working in his spare time implies Romain is killing the project.  Mark
> joins attempting to take some heat off of Romain.  Jon joins attempting to
> be as neutral as possible.  In the end both Mark and Jon apologize.  Andy's
> code stays reverted.
>
> In this incident Andy committed code. Mark and Romain begin arguing.
> Insults are exchanged for one hour till Andy quits complaining that he's
> working in his spare time and implies Romain is killing the project.  Jon
> joins attempting to be as neutral as possible.  In the end both Mark and
> Jon apologize.  Andy's code stays reverted.  This time it's all Tomitribe's
> fault.
>
>
> Am I the only one to notice a pattern?  That pattern is not one person's
> fault.  The pattern is we are behaving like children.
>
>
> This will not get better if each of us is expecting the other guy to
> change.  If your only response to this email is find flaws in others, I
> guarantee nothing will get better.
>
> Mark, you got there in the end which is great.  You pointed out something
> you could have done better and something Andy could do better.  That's the
> right pattern.  People are much more willing to accept feedback when they
> see you're also willing to accept it.
>
> We need to get there sooner next time and we need more than one person
> doing it.
>
>
> So with all that said, how do we turn this into an awesome learning
> experience that makes us stronger?
>
>
>
> -David
>
>
>
> > On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <ag...@tomitribe.com>
> wrote:
> >
> > Added project stubs: https://github.com/apache/
> tomee/tree/master/microprofile
> >
> > Andy.
> >
> >
> > On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >> Hi,
> >>
> >> Ok thanks guys.
> >> @Rudy, you are most welcome :)
> >>
> >> --
> >> Jean-Louis Monteiro
> >> http://twitter.com/jlouismonteiro
> >> http://www.tomitribe.com
> >>
> >> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> rdebusscher@gmail.com>
> >> wrote:
> >>
> >>> I think it is a very important spec, also for non-microprofile
> >>> implementations as it can enhance the interoperability of all servers.
> >>>
> >>> I'm also very interested in the implementation (and want to help a bit
> with
> >>> it also :) )
> >>>
> >>> regards
> >>> Rudy
> >>>
> >>>
> >>>
> >>> On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
> >>> wrote:
> >>>
> >>>> To clarify this even further:
> >>>> The Geronimo Server is now officially dead.
> >>>> But the Geronimo project is not. It alredy contains quite a few
> modular
> >>>> parts which are reused in many ASF projects and also outside.
> >>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >>>> geronimo-config, xbean-finder, etc
> >>>>
> >>>> Of course it would probably make sense to fold those 2 projects
> together,
> >>>> as already discussed in the past.
> >>>> I'm still all open to it, but I have an important criterium to fulfil:
> >>>> If we move those portable parts to TomEE, then this would mean that
> TomEE
> >>>> would become an 'Umbrella project'.
> >>>> And further that we would need a new name for those portable parts.
> >>>> They would effectively be mainatained by the TomEE community (which
> has a
> >>>> big overlap with Geronimo anyway) but those parts must clearly be
> >>>> recognized separately from TomEE.
> >>>>
> >>>> Otherwise people will assume that those parts only work within TomEE -
> >>>> where in reality they would even work on WildFly or Liberty, etc. or
> >>> even a
> >>>> naked Tomcat.
> >>>> Got me?
> >>>>
> >>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
> >>>> backward compatibility.
> >>>>
> >>>>
> >>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>> rmannibucau@gmail.com
> >>>>> :
> >>>>>
> >>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>> osantana@tomitribe.com>:
> >>>>>
> >>>>>> Guys, I have a question:
> >>>>>>
> >>>>>> Why not a project to each implementation?
> >>>>>>
> >>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>
> >>>>>
> >>>>>> This way I can use just a specific if I want also.
> >>>>>>
> >>>>> exactly the goal and user usage AFAIK ;)
> >>>>>
> >>>>> long story short: we learnt from the past errors and since always the
> >>>> same
> >>>>> people work on these projects it is better to not split it accross N
> >>>>> communities since
> >>>>> it leads to a lot of efforts for these people. Having a single
> umbrella
> >>>>> project with N subprojects reduces the administrative work etc and
> >>>> enhance
> >>>>> the projects productivity.
> >>>>>
> >>>>>
> >>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>> rmannibucau@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi JL,
> >>>>>>>
> >>>>>>> Microprofile apache effort is hosted in geronimo and John already
> >>> spoke
> >>>>>>> about it I think. Would probably saner to keep it all at the same
> >>> place
> >>>>>> for
> >>>>>>> the foundation.
> >>>>>>>
> >>>>>>>
> >>>>>>> Romain Manni-Bucau
> >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >>>>>>> rmannibucau> |
> >>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>> ee-8-high-performance>
> >>>>>>>
> >>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>> jlmonteiro@tomitribe.com
> >>>>>>> :
> >>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> I was wondering if we could have the Microprofile JWT implemented
> in
> >>>>>>> TomEE.
> >>>>>>>> What do you think?
> >>>>>>>>
> >>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>
> >>>>>>>> Jean-Louis
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Louis Monteiro
> >>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>> http://www.tomitribe.com
> >>>>>>>>
> >>>>
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> > https://www.tomitribe.io
> >
> >
> > Ubique
> >
>
>

Let's do better

[David Blevins <da...@gmail.com>]

Ok, community, we have to have another quick talk and then hopefully we can go back to being awesome.

This thread got very negative and bares a striking resemblance to the "Suffocating Development Environment" thread from the June 27th incident.  Yes, I've written about it enough times in the board reports that I have the date memorized.  What I've written is mostly positive and been praised by the board for our handling of a hard situation.  You're all making a liar out of me. :)

I was delicate in the first situation, but now I have to be a bit more direct.


In the June 27th incident we had Andy committing code, Romain reverting it, the two exchanging insults for one hour till Andy quit complaining that he's working in his spare time implies Romain is killing the project.  Mark joins attempting to take some heat off of Romain.  Jon joins attempting to be as neutral as possible.  In the end both Mark and Jon apologize.  Andy's code stays reverted.

In this incident Andy committed code. Mark and Romain begin arguing. Insults are exchanged for one hour till Andy quits complaining that he's working in his spare time and implies Romain is killing the project.  Jon joins attempting to be as neutral as possible.  In the end both Mark and Jon apologize.  Andy's code stays reverted.  This time it's all Tomitribe's fault.


Am I the only one to notice a pattern?  That pattern is not one person's fault.  The pattern is we are behaving like children.


This will not get better if each of us is expecting the other guy to change.  If your only response to this email is find flaws in others, I guarantee nothing will get better.

Mark, you got there in the end which is great.  You pointed out something you could have done better and something Andy could do better.  That's the right pattern.  People are much more willing to accept feedback when they see you're also willing to accept it.

We need to get there sooner next time and we need more than one person doing it.


So with all that said, how do we turn this into an awesome learning experience that makes us stronger?



-David



> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <ag...@tomitribe.com> wrote:
> 
> Added project stubs: https://github.com/apache/tomee/tree/master/microprofile
> 
> Andy.
> 
> 
> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>> Hi,
>> 
>> Ok thanks guys.
>> @Rudy, you are most welcome :)
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 
>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <rd...@gmail.com>
>> wrote:
>> 
>>> I think it is a very important spec, also for non-microprofile
>>> implementations as it can enhance the interoperability of all servers.
>>> 
>>> I'm also very interested in the implementation (and want to help a bit with
>>> it also :) )
>>> 
>>> regards
>>> Rudy
>>> 
>>> 
>>> 
>>> On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
>>> wrote:
>>> 
>>>> To clarify this even further:
>>>> The Geronimo Server is now officially dead.
>>>> But the Geronimo project is not. It alredy contains quite a few modular
>>>> parts which are reused in many ASF projects and also outside.
>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>> geronimo-config, xbean-finder, etc
>>>> 
>>>> Of course it would probably make sense to fold those 2 projects together,
>>>> as already discussed in the past.
>>>> I'm still all open to it, but I have an important criterium to fulfil:
>>>> If we move those portable parts to TomEE, then this would mean that TomEE
>>>> would become an 'Umbrella project'.
>>>> And further that we would need a new name for those portable parts.
>>>> They would effectively be mainatained by the TomEE community (which has a
>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>> recognized separately from TomEE.
>>>> 
>>>> Otherwise people will assume that those parts only work within TomEE -
>>>> where in reality they would even work on WildFly or Liberty, etc. or
>>> even a
>>>> naked Tomcat.
>>>> Got me?
>>>> 
>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>>> backward compatibility.
>>>> 
>>>> 
>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>>>> :
>>>>> 
>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>> osantana@tomitribe.com>:
>>>>> 
>>>>>> Guys, I have a question:
>>>>>> 
>>>>>> Why not a project to each implementation?
>>>>>> 
>>>>> this is the case but geronimo is used as an umbrella project.
>>>>> 
>>>>> 
>>>>>> This way I can use just a specific if I want also.
>>>>>> 
>>>>> exactly the goal and user usage AFAIK ;)
>>>>> 
>>>>> long story short: we learnt from the past errors and since always the
>>>> same
>>>>> people work on these projects it is better to not split it accross N
>>>>> communities since
>>>>> it leads to a lot of efforts for these people. Having a single umbrella
>>>>> project with N subprojects reduces the administrative work etc and
>>>> enhance
>>>>> the projects productivity.
>>>>> 
>>>>> 
>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi JL,
>>>>>>> 
>>>>>>> Microprofile apache effort is hosted in geronimo and John already
>>> spoke
>>>>>>> about it I think. Would probably saner to keep it all at the same
>>> place
>>>>>> for
>>>>>>> the foundation.
>>>>>>> 
>>>>>>> 
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>>> rmannibucau> |
>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>> ee-8-high-performance>
>>>>>>> 
>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>> jlmonteiro@tomitribe.com
>>>>>>> :
>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> I was wondering if we could have the Microprofile JWT implemented in
>>>>>>> TomEE.
>>>>>>>> What do you think?
>>>>>>>> 
>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>> 
>>>>>>>> Jean-Louis
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Jean-Louis Monteiro
>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>> http://www.tomitribe.com
>>>>>>>> 
>>>> 
> 
> -- 
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
> 
> 
> Ubique
> 

Re: Implementing Microprofile JWT

[Andy Gumbrecht <ag...@tomitribe.com>]

Any issues let me know and I'll fix tomorrow - not staying up for the 
buildbot.


On 12/02/18 21:14, Andy Gumbrecht wrote:
>
> "Parts of the components skeletons you just created"
>
> They're just logically named empty modules for pending work?
>
>
> On 12/02/18 20:42, Mark Struberg wrote:
>> And what's that for?
>>
>> Is there any behind the scene stuff going on at Tomitribe or can we 
>> finally get back to discussing such things on the Apache lists?
>>
>> Before we go on I'd would first finish the discussion how we want to 
>> turn TomEE into an umbrella project or how the structure would be. 
>> And whether/how we want to integrate the modular Geronimo parts into 
>> one project or not.
>>
>> Parts of the components skeletons you just created do already exist 
>> at the ASF.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
>> <ag...@tomitribe.com> wrote:
>>
>>
>> Added project stubs:
>> https://github.com/apache/tomee/tree/master/microprofile
>>
>> Andy.
>>
>>
>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>> > Hi,
>> >
>> > Ok thanks guys.
>> > @Rudy, you are most welcome :)
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
>> <rdebusscher@gmail.com <ma...@gmail.com>>
>> > wrote:
>> >
>> >> I think it is a very important spec, also for non-microprofile
>> >> implementations as it can enhance the interoperability of all servers.
>> >>
>> >> I'm also very interested in the implementation (and want to help a 
>> bit with
>> >> it also :) )
>> >>
>> >> regards
>> >> Rudy
>> >>
>> >>
>> >>
>> >> On 2 February 2018 at 11:23, Mark Struberg 
>> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>
>> >> wrote:
>> >>
>> >>> To clarify this even further:
>> >>> The Geronimo Server is now officially dead.
>> >>> But the Geronimo project is not. It alredy contains quite a few 
>> modular
>> >>> parts which are reused in many ASF projects and also outside.
>> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>> >>> geronimo-config, xbean-finder, etc
>> >>>
>> >>> Of course it would probably make sense to fold those 2 projects 
>> together,
>> >>> as already discussed in the past.
>> >>> I'm still all open to it, but I have an important criterium to 
>> fulfil:
>> >>> If we move those portable parts to TomEE, then this would mean 
>> that TomEE
>> >>> would become an 'Umbrella project'.
>> >>> And further that we would need a new name for those portable parts.
>> >>> They would effectively be mainatained by the TomEE community 
>> (which has a
>> >>> big overlap with Geronimo anyway) but those parts must clearly be
>> >>> recognized separately from TomEE.
>> >>>
>> >>> Otherwise people will assume that those parts only work within 
>> TomEE -
>> >>> where in reality they would even work on WildFly or Liberty, etc. or
>> >> even a
>> >>> naked Tomcat.
>> >>> Got me?
>> >>>
>> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts 
>> Department' :)
>> >>>
>> >>> LieGrue,
>> >>> strub
>> >>>
>> >>> PS: I'd also love to keep the org.apache.geronimo package name to 
>> ease
>> >>> backward compatibility.
>> >>>
>> >>>
>> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> >> rmannibucau@gmail.com <ma...@gmail.com>
>> >>>> :
>> >>>>
>> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>> >>>>
>> >>>>> Guys, I have a question:
>> >>>>>
>> >>>>> Why not a project to each implementation?
>> >>>>>
>> >>>> this is the case but geronimo is used as an umbrella project.
>> >>>>
>> >>>>
>> >>>>> This way I can use just a specific if I want also.
>> >>>>>
>> >>>> exactly the goal and user usage AFAIK ;)
>> >>>>
>> >>>> long story short: we learnt from the past errors and since 
>> always the
>> >>> same
>> >>>> people work on these projects it is better to not split it accross N
>> >>>> communities since
>> >>>> it leads to a lot of efforts for these people. Having a single 
>> umbrella
>> >>>> project with N subprojects reduces the administrative work etc and
>> >>> enhance
>> >>>> the projects productivity.
>> >>>>
>> >>>>
>> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>> >>> rmannibucau@gmail.com <ma...@gmail.com>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi JL,
>> >>>>>>
>> >>>>>> Microprofile apache effort is hosted in geronimo and John already
>> >> spoke
>> >>>>>> about it I think. Would probably saner to keep it all at the same
>> >> place
>> >>>>> for
>> >>>>>> the foundation.
>> >>>>>>
>> >>>>>>
>> >>>>>> Romain Manni-Bucau
>> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> >>>>>> rmannibucau> |
>> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >>>>>> <https://www.packtpub.com/application-development/java-
>> >>>>>> ee-8-high-performance>
>> >>>>>>
>> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>> >>>>>> :
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> I was wondering if we could have the Microprofile JWT 
>> implemented in
>> >>>>>> TomEE.
>> >>>>>>> What do you think?
>> >>>>>>>
>> >>>>>>> I was reading the spec and I'd like to contribute that in.
>> >>>>>>>
>> >>>>>>> Jean-Louis
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Jean-Louis Monteiro
>> >>>>>>> http://twitter.com/jlouismonteiro
>> >>>>>>> http://www.tomitribe.com
>> >>>>>>>
>> >>>
>>
>> -- 
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>>
>> http://www.tomitribe.com
>>
>> https://www.tomitribe.io
>>
>>
>> Ubique
>>
>>
>
> -- 
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

2018-02-13 12:43 GMT+01:00 John D. Ament <jo...@apache.org>:

>
>
> On 2018/02/12 20:42:58, Jonathan Gallimore <jo...@gmail.com>
> wrote:
> > On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > No Andy, as mentionned in the discussion Geronimo hosts the
> microprofile
> > > @asf. This is why jwt should probably be done in geronimo which is the
> asf
> > > ee related project umbrella.
> > >
> >
> > I don't recall that discussion. Where did it take place?
>
> I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
> I had mentioned bringing over an impl based on Jose4J, Romain felt very
> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that is,
> but it seemed based on the discussion we had two different aims so it
> wasn't something I pushed forward on.  If there's interest within TomEE to
> get a JWT impl up and running, I'd be happy to help (though I do feel
> strongly relying on a 3rd party lib for the actual signature validation +
> external sig support is important; to avoid that overhead).
>
>
Was more referring to the discussion on the umbrella project and effort
aggregator than jwt spec in particular. This is the discussion Mark spoke
about in the other thread.


> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> about what projects are allowed to host.  For example, there's interest
> within Skywalking to host the CDI and JAX-RS extensions to support OpenApi;
> but this spec doesn't represent something any server vendor would support
> since its really about your APM solution.  CXF happily took on the MP Rest
> Client when I proposed it; though I would hope TomEE relies on the CXF
> library instead of crafting their own client (selfish desires).  The JWT
> spec is weird, because it defined non MP runtime behavior in addition to MP
> runtime behavior; so there may be more integration work in a fuller app
> server like TomEE.
>

Yep, rule was more to try to put it where it fits naturally (like you did
for cxf) and if there is no natural home put it in the umbrella project
which is G today.
The dependency point is something we can discuss, my rational was 1. to
avoid conflicts which will happen with jjwt, jose etc... (you can also say
"happens" if you consider cxf ecosystem and usages) and 2. avoid to build a
200M server for that few features. Since this code is pretty simple I would
do it from scratch but a well configured shade can be an acceptable first
step to gain time as mentionned in the discussion about fault-tolerance.


>
> </peanut-gallery>
>
> John
>
> [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>
> >
> >
> > >
> > > I understand it is not the most convenient for tomitribe which probably
> > > perfers to own the full project(s) but as a foundation member I d
> really
> > > like to not let company details pollute projects
> >
> >
> > > Also the discussion made clear to not do it in current repo whatever
> > > project is used as umbrella so we should revert that and finish the
> > > discussion before any action to not kill tomee project by a hard
> company
> > > driven management making it no more in the OSS spirit.
> > >
> >
> > I agree the discussion should happen first, and I note that the change
> has
> > been reverted. I recall that we agreed on this list that we'd create new
> > git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> > other components sit under TomEE, I imagine that they would follow the
> same
> > pattern - i.e. discuss first, agree location, create repo or move things
> > around as appropriate.
> >
> > I don't know what your specific issues are here, but I think you are
> making
> > some assumptions that are simply not true.
> >
> > Jon
> >
> >
> >
> > >
> > > Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> > > écrit :
> > >
> > > > "Parts of the components skeletons you just created"
> > > >
> > > > They're just logically named empty modules for pending work?
> > > >
> > > >
> > > > On 12/02/18 20:42, Mark Struberg wrote:
> > > >
> > > >> And what's that for?
> > > >>
> > > >> Is there any behind the scene stuff going on at Tomitribe or can we
> > > >> finally get back to discussing such things on the Apache lists?
> > > >>
> > > >> Before we go on I'd would first finish the discussion how we want to
> > > turn
> > > >> TomEE into an umbrella project or how the structure would be. And
> > > >> whether/how we want to integrate the modular Geronimo parts into one
> > > >> project or not.
> > > >>
> > > >> Parts of the components skeletons you just created do already exist
> at
> > > >> the ASF.
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > > >> agumbrecht@tomitribe.com> wrote:
> > > >>
> > > >>
> > > >> Added project stubs:
> > > >> https://github.com/apache/tomee/tree/master/microprofile
> > > >>
> > > >> Andy.
> > > >>
> > > >>
> > > >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> > > >> > Hi,
> > > >> >
> > > >> > Ok thanks guys.
> > > >> > @Rudy, you are most welcome :)
> > > >> >
> > > >> > --
> > > >> > Jean-Louis Monteiro
> > > >> > http://twitter.com/jlouismonteiro
> > > >> > http://www.tomitribe.com
> > > >> >
> > > >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> > > >> rdebusscher@gmail.com <ma...@gmail.com>>
> > > >> > wrote:
> > > >> >
> > > >> >> I think it is a very important spec, also for non-microprofile
> > > >> >> implementations as it can enhance the interoperability of all
> > > servers.
> > > >> >>
> > > >> >> I'm also very interested in the implementation (and want to help
> a
> > > bit
> > > >> with
> > > >> >> it also :) )
> > > >> >>
> > > >> >> regards
> > > >> >> Rudy
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> On 2 February 2018 at 11:23, Mark Struberg
> <struberg@yahoo.de.invalid
> > > >> <ma...@yahoo.de.invalid>>
> > > >> >> wrote:
> > > >> >>
> > > >> >>> To clarify this even further:
> > > >> >>> The Geronimo Server is now officially dead.
> > > >> >>> But the Geronimo project is not. It alredy contains quite a few
> > > >> modular
> > > >> >>> parts which are reused in many ASF projects and also outside.
> > > >> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> > > >> >>> geronimo-config, xbean-finder, etc
> > > >> >>>
> > > >> >>> Of course it would probably make sense to fold those 2 projects
> > > >> together,
> > > >> >>> as already discussed in the past.
> > > >> >>> I'm still all open to it, but I have an important criterium to
> > > fulfil:
> > > >> >>> If we move those portable parts to TomEE, then this would mean
> that
> > > >> TomEE
> > > >> >>> would become an 'Umbrella project'.
> > > >> >>> And further that we would need a new name for those portable
> parts.
> > > >> >>> They would effectively be mainatained by the TomEE community
> (which
> > > >> has a
> > > >> >>> big overlap with Geronimo anyway) but those parts must clearly
> be
> > > >> >>> recognized separately from TomEE.
> > > >> >>>
> > > >> >>> Otherwise people will assume that those parts only work within
> > > TomEE -
> > > >> >>> where in reality they would even work on WildFly or Liberty,
> etc. or
> > > >> >> even a
> > > >> >>> naked Tomcat.
> > > >> >>> Got me?
> > > >> >>>
> > > >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> Department'
> > > :)
> > > >> >>>
> > > >> >>> LieGrue,
> > > >> >>> strub
> > > >> >>>
> > > >> >>> PS: I'd also love to keep the org.apache.geronimo package name
> to
> > > ease
> > > >> >>> backward compatibility.
> > > >> >>>
> > > >> >>>
> > > >> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> > > >> >> rmannibucau@gmail.com <ma...@gmail.com>
> > > >> >>>> :
> > > >> >>>>
> > > >> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > > >> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> > > >> >>>>
> > > >> >>>>> Guys, I have a question:
> > > >> >>>>>
> > > >> >>>>> Why not a project to each implementation?
> > > >> >>>>>
> > > >> >>>> this is the case but geronimo is used as an umbrella project.
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>> This way I can use just a specific if I want also.
> > > >> >>>>>
> > > >> >>>> exactly the goal and user usage AFAIK ;)
> > > >> >>>>
> > > >> >>>> long story short: we learnt from the past errors and since
> always
> > > the
> > > >> >>> same
> > > >> >>>> people work on these projects it is better to not split it
> accross
> > > N
> > > >> >>>> communities since
> > > >> >>>> it leads to a lot of efforts for these people. Having a single
> > > >> umbrella
> > > >> >>>> project with N subprojects reduces the administrative work etc
> and
> > > >> >>> enhance
> > > >> >>>> the projects productivity.
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> > > >> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> > > >> >>>>> wrote:
> > > >> >>>>>
> > > >> >>>>>> Hi JL,
> > > >> >>>>>>
> > > >> >>>>>> Microprofile apache effort is hosted in geronimo and John
> already
> > > >> >> spoke
> > > >> >>>>>> about it I think. Would probably saner to keep it all at the
> same
> > > >> >> place
> > > >> >>>>> for
> > > >> >>>>>> the foundation.
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>> Romain Manni-Bucau
> > > >> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > >> >>>>>> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/
> > > >> >>>>>> rmannibucau> |
> > > >> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > >> >>>>>> <https://www.packtpub.com/application-development/java-
> > > >> >>>>>> ee-8-high-performance>
> > > >> >>>>>>
> > > >> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> > > >> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> > > >> >>>>>> :
> > > >> >>>>>>
> > > >> >>>>>>> Hi all,
> > > >> >>>>>>>
> > > >> >>>>>>> I was wondering if we could have the Microprofile JWT
> > > implemented
> > > >> in
> > > >> >>>>>> TomEE.
> > > >> >>>>>>> What do you think?
> > > >> >>>>>>>
> > > >> >>>>>>> I was reading the spec and I'd like to contribute that in.
> > > >> >>>>>>>
> > > >> >>>>>>> Jean-Louis
> > > >> >>>>>>>
> > > >> >>>>>>> --
> > > >> >>>>>>> Jean-Louis Monteiro
> > > >> >>>>>>> http://twitter.com/jlouismonteiro
> > > >> >>>>>>> http://www.tomitribe.com
> > > >> >>>>>>>
> > > >> >>>
> > > >>
> > > >> --
> > > >> Andy Gumbrecht
> > > >> https://twitter.com/AndyGeeDe
> > > >>
> > > >> http://www.tomitribe.com
> > > >>
> > > >> https://www.tomitribe.io
> > > >>
> > > >>
> > > >> Ubique
> > > >>
> > > >>
> > > >>
> > > > --
> > > > Andy Gumbrecht
> > > > https://twitter.com/AndyGeeDe
> > > > http://www.tomitribe.com
> > > > https://www.tomitribe.io
> > > >
> > > >
> > > > Ubique
> > > >
> > > >
> > >
> >
>

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Too early for me to figure this out. Really need to get an example working
so that I can think of a cleaner design.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Feb 13, 2018 at 4:58 PM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> Might do as well.
> But the JSON-P part is really well abstracted. So this is easy to plug-in.
>
> I'm more worried about the authorisation and authentication interface.
> Anything EE security seems way too heavyweight for me. This might work out
> for TomEE, but would kill it's use in any more lightweight approach.
> So probably introduce an own pluggable SPI for authentication and
> authorisation?
> Then it really could be done pretty much anywhere. Or do we have yet
> another 'interface area'?
>
> LieGrue,
> strub
>
>
> > Am 13.02.2018 um 16:52 schrieb Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com>:
> >
> > I was also thinking about a Johnzon extension (kinda)
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> >> I know JWT a bit and I wonder whether doing the signing part is just a
> bit
> >> of Json (JSON-P) + commons-crypto?
> >> After all JWT is especially designed to be lightweight and straight
> >> forward.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> >>> :
> >>>
> >>> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com
> >>> :
> >>>
> >>>> Thanks for the feedback Jon.
> >>>>
> >>>> I had a couple of exchanges with Rudy which is happy to contribute
> some
> >>>> code as well.
> >>>> From what I have understood and seen, most of the code is integration
> >> code
> >>>> and there is at least from my current knowledge a little bit of code
> to
> >> put
> >>>> together in a reusable manner in a reusable library (where ever it
> >> sits).
> >>>> I was planning to do a quick prototype and get it to work from end to
> >> end
> >>>> into a working branch so we can move the discussion forward and see
> >> exactly
> >>>> where we go.
> >>>>
> >>>> Regarding the signing library, I am kinda on the same page.
> >>>> I don't see myself rewriting Johnzon to parse JSON and then Jose or
> >> Nimbus
> >>>> to do signing. There is absolutely no point at least for the POC.
> Again,
> >>>> we'll see if I get something working what we can do.
> >>>>
> >>>>
> >>>>
> >>> Agreeing for a PoC but for a production ready software it is if it can
> >>> conflict or bring drawbacks to the users to import the solution. The
> json
> >>> lib should at least be pluggable - avoids to shade/rewrite anything but
> >> let
> >>> the integrator use what he already has. Side note for json: for the
> >> overall
> >>> consistency using JSON-P makes it easy to get a common API which
> doesn't
> >>> need any investment and solves that "plug your impl" smoothly. For the
> >>> signing part it is a bit different since it will easily bring a huge
> >> stack
> >>> - how many bring jackson, simple-json, ... by default and are not
> >>> pluggable. This is an issue and can even lead to not working
> >> installations.
> >>> If you doubt I have like 700 components to show you it is not a random
> or
> >>> theorical thought. Investment is also quite light so not sure it does
> >> worth
> >>> speaking about it days.
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <
> johndament@apache.org>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 2018/02/12 20:42:58, Jonathan Gallimore <
> >> jonathan.gallimore@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> No Andy, as mentionned in the discussion Geronimo hosts the
> >>>>> microprofile
> >>>>>>> @asf. This is why jwt should probably be done in geronimo which is
> >>>> the
> >>>>> asf
> >>>>>>> ee related project umbrella.
> >>>>>>>
> >>>>>>
> >>>>>> I don't recall that discussion. Where did it take place?
> >>>>>
> >>>>> I *think* he meant me.  The only time JWT came up on Geronimo was at
> >> [1].
> >>>>> I had mentioned bringing over an impl based on Jose4J, Romain felt
> very
> >>>>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why
> that
> >>>> is,
> >>>>> but it seemed based on the discussion we had two different aims so it
> >>>>> wasn't something I pushed forward on.  If there's interest within
> TomEE
> >>>> to
> >>>>> get a JWT impl up and running, I'd be happy to help (though I do feel
> >>>>> strongly relying on a 3rd party lib for the actual signature
> >> validation +
> >>>>> external sig support is important; to avoid that overhead).
> >>>>>
> >>>>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast
> rules
> >>>>> about what projects are allowed to host.  For example, there's
> interest
> >>>>> within Skywalking to host the CDI and JAX-RS extensions to support
> >>>> OpenApi;
> >>>>> but this spec doesn't represent something any server vendor would
> >> support
> >>>>> since its really about your APM solution.  CXF happily took on the MP
> >>>> Rest
> >>>>> Client when I proposed it; though I would hope TomEE relies on the
> CXF
> >>>>> library instead of crafting their own client (selfish desires).  The
> >> JWT
> >>>>> spec is weird, because it defined non MP runtime behavior in addition
> >> to
> >>>> MP
> >>>>> runtime behavior; so there may be more integration work in a fuller
> app
> >>>>> server like TomEE.
> >>>>>
> >>>>> </peanut-gallery>
> >>>>>
> >>>>> John
> >>>>>
> >>>>> [1]: https://lists.apache.org/thread.html/
> >> 4edc997cfe2e45aaf25bb118bc6216
> >>>>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I understand it is not the most convenient for tomitribe which
> >>>> probably
> >>>>>>> perfers to own the full project(s) but as a foundation member I d
> >>>>> really
> >>>>>>> like to not let company details pollute projects
> >>>>>>
> >>>>>>
> >>>>>>> Also the discussion made clear to not do it in current repo
> whatever
> >>>>>>> project is used as umbrella so we should revert that and finish the
> >>>>>>> discussion before any action to not kill tomee project by a hard
> >>>>> company
> >>>>>>> driven management making it no more in the OSS spirit.
> >>>>>>>
> >>>>>>
> >>>>>> I agree the discussion should happen first, and I note that the
> change
> >>>>> has
> >>>>>> been reverted. I recall that we agreed on this list that we'd create
> >>>> new
> >>>>>> git projects for Sheldon and Chatterbox under the TomEE umbrella.
> >>>> Should
> >>>>>> other components sit under TomEE, I imagine that they would follow
> the
> >>>>> same
> >>>>>> pattern - i.e. discuss first, agree location, create repo or move
> >>>> things
> >>>>>> around as appropriate.
> >>>>>>
> >>>>>> I don't know what your specific issues are here, but I think you are
> >>>>> making
> >>>>>> some assumptions that are simply not true.
> >>>>>>
> >>>>>> Jon
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <agumbrecht@tomitribe.com
> >
> >>>> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> "Parts of the components skeletons you just created"
> >>>>>>>>
> >>>>>>>> They're just logically named empty modules for pending work?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/02/18 20:42, Mark Struberg wrote:
> >>>>>>>>
> >>>>>>>>> And what's that for?
> >>>>>>>>>
> >>>>>>>>> Is there any behind the scene stuff going on at Tomitribe or can
> >>>> we
> >>>>>>>>> finally get back to discussing such things on the Apache lists?
> >>>>>>>>>
> >>>>>>>>> Before we go on I'd would first finish the discussion how we want
> >>>> to
> >>>>>>> turn
> >>>>>>>>> TomEE into an umbrella project or how the structure would be. And
> >>>>>>>>> whether/how we want to integrate the modular Geronimo parts into
> >>>> one
> >>>>>>>>> project or not.
> >>>>>>>>>
> >>>>>>>>> Parts of the components skeletons you just created do already
> >>>> exist
> >>>>> at
> >>>>>>>>> the ASF.
> >>>>>>>>>
> >>>>>>>>> LieGrue,
> >>>>>>>>> strub
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >>>>>>>>> agumbrecht@tomitribe.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Added project stubs:
> >>>>>>>>> https://github.com/apache/tomee/tree/master/microprofile
> >>>>>>>>>
> >>>>>>>>> Andy.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Ok thanks guys.
> >>>>>>>>>> @Rudy, you are most welcome :)
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >>>>>>>>> rdebusscher@gmail.com <ma...@gmail.com>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I think it is a very important spec, also for non-microprofile
> >>>>>>>>>>> implementations as it can enhance the interoperability of all
> >>>>>>> servers.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm also very interested in the implementation (and want to
> >>>> help
> >>>>> a
> >>>>>>> bit
> >>>>>>>>> with
> >>>>>>>>>>> it also :) )
> >>>>>>>>>>>
> >>>>>>>>>>> regards
> >>>>>>>>>>> Rudy
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
> >>>>> <struberg@yahoo.de.invalid
> >>>>>>>>> <ma...@yahoo.de.invalid>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> To clarify this even further:
> >>>>>>>>>>>> The Geronimo Server is now officially dead.
> >>>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a
> >>>> few
> >>>>>>>>> modular
> >>>>>>>>>>>> parts which are reused in many ASF projects and also outside.
> >>>>>>>>>>>> Examples is the geronimo-transaction-manager,
> >>>> geronimo-javamail,
> >>>>>>>>>>>> geronimo-config, xbean-finder, etc
> >>>>>>>>>>>>
> >>>>>>>>>>>> Of course it would probably make sense to fold those 2
> >>>> projects
> >>>>>>>>> together,
> >>>>>>>>>>>> as already discussed in the past.
> >>>>>>>>>>>> I'm still all open to it, but I have an important criterium to
> >>>>>>> fulfil:
> >>>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
> >>>>> that
> >>>>>>>>> TomEE
> >>>>>>>>>>>> would become an 'Umbrella project'.
> >>>>>>>>>>>> And further that we would need a new name for those portable
> >>>>> parts.
> >>>>>>>>>>>> They would effectively be mainatained by the TomEE community
> >>>>> (which
> >>>>>>>>> has a
> >>>>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly
> >>>>> be
> >>>>>>>>>>>> recognized separately from TomEE.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Otherwise people will assume that those parts only work within
> >>>>>>> TomEE -
> >>>>>>>>>>>> where in reality they would even work on WildFly or Liberty,
> >>>>> etc. or
> >>>>>>>>>>> even a
> >>>>>>>>>>>> naked Tomcat.
> >>>>>>>>>>>> Got me?
> >>>>>>>>>>>>
> >>>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> >>>>> Department'
> >>>>>>> :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>> strub
> >>>>>>>>>>>>
> >>>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name
> >>>>> to
> >>>>>>> ease
> >>>>>>>>>>>> backward compatibility.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>>>>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Guys, I have a question:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Why not a project to each implementation?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> This way I can use just a specific if I want also.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> long story short: we learnt from the past errors and since
> >>>>> always
> >>>>>>> the
> >>>>>>>>>>>> same
> >>>>>>>>>>>>> people work on these projects it is better to not split it
> >>>>> accross
> >>>>>>> N
> >>>>>>>>>>>>> communities since
> >>>>>>>>>>>>> it leads to a lot of efforts for these people. Having a
> >>>> single
> >>>>>>>>> umbrella
> >>>>>>>>>>>>> project with N subprojects reduces the administrative work
> >>>> etc
> >>>>> and
> >>>>>>>>>>>> enhance
> >>>>>>>>>>>>> the projects productivity.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi JL,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
> >>>>> already
> >>>>>>>>>>> spoke
> >>>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at
> >>>> the
> >>>>> same
> >>>>>>>>>>> place
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>> the foundation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>>> https://github.com/
> >>>>>>>>>>>>>>> rmannibucau> |
> >>>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>>>>>>>>>> ee-8-high-performance>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>>>>>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> >>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
> >>>>>>> implemented
> >>>>>>>>> in
> >>>>>>>>>>>>>>> TomEE.
> >>>>>>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jean-Louis
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Andy Gumbrecht
> >>>>>>>>> https://twitter.com/AndyGeeDe
> >>>>>>>>>
> >>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>
> >>>>>>>>> https://www.tomitribe.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Ubique
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>> Andy Gumbrecht
> >>>>>>>> https://twitter.com/AndyGeeDe
> >>>>>>>> http://www.tomitribe.com
> >>>>>>>> https://www.tomitribe.io
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ubique
> >>
> >>
>
>

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

We propagate to EJB the principal so we should have it working without a
lot - never said "no" - of effort for all synchronous cases. I'm pretty
sure it will be broken for the async - but natural user - flow (@Suspended
or plain AsyncContext, EE Concurrency utilities will not work for servlet
case - can need a fix - but would if called from an EJB IIRC) but this
seems out of the spec too, no?

You are right the Jacc integration can need a few more love to match the
spec but we own this code and have the principal at that moment so i'm sure
we can make it running, even without being jwt specific which can benefit
all the alternative solutions user base.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-14 22:43 GMT+01:00 David Blevins <da...@gmail.com>:

> > On Feb 14, 2018, at 11:34 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > If jsonp it can be @appscoped too technically
>
> I was definitely advocating for that and AppScoped was supported, but it
> got axed at the finish line the week before the 1.0 spec went final.  We
> decided to cut scope (pun intended) to get something out the door and come
> back and add this later.
>
> > > That part will be a bit tricky, but effectively we need a
> dependent-scoped
> > > producer that can find the JWT data in the active request.  Perhaps by
> > > looking in the ThreadContext.
> >
> > Cant jaspic work?
>
> Not sure to be honest.
>
> One place I suspect will be tough is the EJB isCallerInRole checks we do
> are effectively handled by our JACC code (or was).  That code expects we
> know all the users that exist and their permissions at startup time.
> During the Assembler phase the JaccPermissionsBuilder will build a
> permissions object for each role the user has.  The JACC provider then
> becomes effectively an in memory database of permissions objects.  This
> again, goes against the JWT concept as the user and the roles are in the
> token and there is no state in the server.
>
> Not sure how we'll need to handle that or if JASPIC helps.
>
>
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/java/org/apache/openejb/assembler/classic/
> JaccPermissionsBuilder.java
>
> > Also a jwt for an ejb without a request
> > means....something to define ;).
>
> That's all defined in chapter 12
>
>  ... the spec may or may not have only 10 chapters :)
>
>
> -David
>
>
>
>

Re: Implementing Microprofile JWT

[David Blevins <da...@gmail.com>]

> On Feb 14, 2018, at 11:34 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 
> If jsonp it can be @appscoped too technically

I was definitely advocating for that and AppScoped was supported, but it got axed at the finish line the week before the 1.0 spec went final.  We decided to cut scope (pun intended) to get something out the door and come back and add this later.

> > That part will be a bit tricky, but effectively we need a dependent-scoped
> > producer that can find the JWT data in the active request.  Perhaps by
> > looking in the ThreadContext.
> 
> Cant jaspic work?

Not sure to be honest.

One place I suspect will be tough is the EJB isCallerInRole checks we do are effectively handled by our JACC code (or was).  That code expects we know all the users that exist and their permissions at startup time.  During the Assembler phase the JaccPermissionsBuilder will build a permissions object for each role the user has.  The JACC provider then becomes effectively an in memory database of permissions objects.  This again, goes against the JWT concept as the user and the roles are in the token and there is no state in the server.

Not sure how we'll need to handle that or if JASPIC helps.


https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/assembler/classic/JaccPermissionsBuilder.java

> Also a jwt for an ejb without a request
> means....something to define ;).

That's all defined in chapter 12

 ... the spec may or may not have only 10 chapters :)


-David

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

Le 14 févr. 2018 19:47, "David Blevins" <da...@gmail.com> a écrit :

> On Feb 14, 2018, at 9:01 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> interesting thing is JsonWebToken principal will not work with CDI by
> design - due to proxies - so must use another unwrapped layer to get the
> principal like jaspic or servlet layers which will not require any change
> in any of our internals but more a better integration of existing techno,
> no?

There are effectively two ways to get the JsonWebToken:

 - Injectable via CDI into @RequestScoped beans
 - Anywhere a Principal can be obtained

There is also an @Claim qualifier which allows individual claims from the
JWT to be injected into @RequestScoped beans as JSON-P types or as
primatives.


If jsonp it can be @appscoped too technically


That part will be a bit tricky, but effectively we need a dependent-scoped
producer that can find the JWT data in the active request.  Perhaps by
looking in the ThreadContext.


Cant jaspic work? Also a jwt for an ejb without a request
means....something to define ;).



-David

Re: Implementing Microprofile JWT

[David Blevins <da...@gmail.com>]

> On Feb 14, 2018, at 9:01 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 
> interesting thing is JsonWebToken principal will not work with CDI by
> design - due to proxies - so must use another unwrapped layer to get the
> principal like jaspic or servlet layers which will not require any change
> in any of our internals but more a better integration of existing techno,
> no?

There are effectively two ways to get the JsonWebToken:

 - Injectable via CDI into @RequestScoped beans
 - Anywhere a Principal can be obtained

There is also an @Claim qualifier which allows individual claims from the JWT to be injected into @RequestScoped beans as JSON-P types or as primatives.

That part will be a bit tricky, but effectively we need a dependent-scoped producer that can find the JWT data in the active request.  Perhaps by looking in the ThreadContext.


-David

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

think we support jaspic at some point - at least javaee 7 tests were
supposed to cover it, even for EJB while there is a request - not for
@Timeout typically but this is out of scope for microprofile.

interesting thing is JsonWebToken principal will not work with CDI by
design - due to proxies - so must use another unwrapped layer to get the
principal like jaspic or servlet layers which will not require any change
in any of our internals but more a better integration of existing techno,
no?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-14 17:54 GMT+01:00 Jean-Louis Monteiro <jl...@tomitribe.com>:

> Thanks David,
>
> I've started to look into our SecurityService interface as well.
> It would need to evolve at some point. The couple username + password is
> not the best to support many authentication mechanisms.
>
> The realm interface in Tomcat is not the best either because it has like 5
> or 6 strongly typed signatures and you can't add more.
> Basically currently, I'll pass the token into the username parameter and
> leave the password empty.
>
> But would be great to think about a better abstraction to represent the
> credentials.
>
> On the prototype side, I'll definitely use Nimbus to start.
> Don't want to address all problems at once.
>
> Rudy has one implementation based on JASPIC, probably a good opportunity to
> look at it.
>
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Wed, Feb 14, 2018 at 5:30 PM, David Blevins <da...@gmail.com>
> wrote:
>
> >
> > > On Feb 13, 2018, at 3:43 AM, John D. Ament <jo...@apache.org>
> > wrote:
> > >
> > > The JWT spec is weird, because it defined non MP runtime behavior in
> > addition to MP runtime behavior; so there may be more integration work
> in a
> > fuller app server like TomEE.
> >
> > Agreed. I'd describe the MicorProfile JWT spec as almost all integration.
> >
> > There are also optional integration parts for EJB which I think we'd
> > definitely implement.
> >
> > > On Feb 13, 2018, at 6:53 AM, Mark Struberg <st...@yahoo.de.INVALID>
> > wrote:
> > >
> > > I know JWT a bit and I wonder whether doing the signing part is just a
> > bit of Json (JSON-P) + commons-crypto?
> > > After all JWT is especially designed to be lightweight and straight
> > forward.
> >
> > Agreed.  We could definitely get by with JSON-P and even the built-in JVM
> > crypto.  No need for commons-crypto.
> >
> > The MicroProfile JWT specification is intentionally "opinionated" about
> > the JWT format and only allows for compact JWTs and RSA signatures.  The
> > actual JOSE specifications allow for much greater flexibility and
> options,
> > which is why libraries like Nimbus exist.
> >
> > That said, I would still probably prototype with Nimbus and cut it out
> > only after everything works.  Just to make sure I was focusing on the
> right
> > part of the problem.
> >
> > > On Feb 13, 2018, at 7:58 AM, Mark Struberg <st...@yahoo.de.INVALID>
> > wrote:
> > >
> > > I'm more worried about the authorisation and authentication interface.
> > > Anything EE security seems way too heavyweight for me. This might work
> > out for TomEE, but would kill it's use in any more lightweight approach.
> >
> > > On Feb 13, 2018, at 11:27 AM, Rudy De Busscher <rd...@gmail.com>
> > wrote:
> > >
> > > I used JASPIC as it seemed to most natural way to feed the EE system
> > > with authorisation
> > > and authentication into the system.
> > >
> > > But probably need deep integration with server code because otherwise,
> > the
> > > JWT authentication mechanism is an all or nothing system, which is not
> > the
> > > best solution (maybe less a problem with MicroServices but if you want
> to
> > > use it in a more general way it is an obstacle)
> >
> > These last two are very related.  JASPIC would be great, but TomEE
> > (specifically the OpenEJB part) doesn't implement it.  All of the EJB
> calls
> > for isCallerInRole etc are wired in and fed through this interface.
> >
> > https://github.com/apache/tomee/blob/master/container/
> > openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java
> >
> > I think one of the things we'll find most puzzling about how to do the
> > integration is that the Tomcat flavor of this is written assuming the
> users
> > exist in a Tomcat Realm.  The whole point of JWT is that they do not and
> > the server has no such state.
> >
> > https://github.com/apache/tomee/blob/master/tomee/tomee-
> > catalina/src/main/java/org/apache/tomee/catalina/
> > TomcatSecurityService.java
> >
> > I think we'll grapple with questions like "should we support some local
> > override if the user happens to exist locally?"  Certainly, we could.  I
> > might suggest we don't for the first prototype and add that later.
> >
> >
> > -David
> >
> >
>

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Thanks David,

I've started to look into our SecurityService interface as well.
It would need to evolve at some point. The couple username + password is
not the best to support many authentication mechanisms.

The realm interface in Tomcat is not the best either because it has like 5
or 6 strongly typed signatures and you can't add more.
Basically currently, I'll pass the token into the username parameter and
leave the password empty.

But would be great to think about a better abstraction to represent the
credentials.

On the prototype side, I'll definitely use Nimbus to start.
Don't want to address all problems at once.

Rudy has one implementation based on JASPIC, probably a good opportunity to
look at it.








--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Wed, Feb 14, 2018 at 5:30 PM, David Blevins <da...@gmail.com>
wrote:

>
> > On Feb 13, 2018, at 3:43 AM, John D. Ament <jo...@apache.org>
> wrote:
> >
> > The JWT spec is weird, because it defined non MP runtime behavior in
> addition to MP runtime behavior; so there may be more integration work in a
> fuller app server like TomEE.
>
> Agreed. I'd describe the MicorProfile JWT spec as almost all integration.
>
> There are also optional integration parts for EJB which I think we'd
> definitely implement.
>
> > On Feb 13, 2018, at 6:53 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > I know JWT a bit and I wonder whether doing the signing part is just a
> bit of Json (JSON-P) + commons-crypto?
> > After all JWT is especially designed to be lightweight and straight
> forward.
>
> Agreed.  We could definitely get by with JSON-P and even the built-in JVM
> crypto.  No need for commons-crypto.
>
> The MicroProfile JWT specification is intentionally "opinionated" about
> the JWT format and only allows for compact JWTs and RSA signatures.  The
> actual JOSE specifications allow for much greater flexibility and options,
> which is why libraries like Nimbus exist.
>
> That said, I would still probably prototype with Nimbus and cut it out
> only after everything works.  Just to make sure I was focusing on the right
> part of the problem.
>
> > On Feb 13, 2018, at 7:58 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
> >
> > I'm more worried about the authorisation and authentication interface.
> > Anything EE security seems way too heavyweight for me. This might work
> out for TomEE, but would kill it's use in any more lightweight approach.
>
> > On Feb 13, 2018, at 11:27 AM, Rudy De Busscher <rd...@gmail.com>
> wrote:
> >
> > I used JASPIC as it seemed to most natural way to feed the EE system
> > with authorisation
> > and authentication into the system.
> >
> > But probably need deep integration with server code because otherwise,
> the
> > JWT authentication mechanism is an all or nothing system, which is not
> the
> > best solution (maybe less a problem with MicroServices but if you want to
> > use it in a more general way it is an obstacle)
>
> These last two are very related.  JASPIC would be great, but TomEE
> (specifically the OpenEJB part) doesn't implement it.  All of the EJB calls
> for isCallerInRole etc are wired in and fed through this interface.
>
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java
>
> I think one of the things we'll find most puzzling about how to do the
> integration is that the Tomcat flavor of this is written assuming the users
> exist in a Tomcat Realm.  The whole point of JWT is that they do not and
> the server has no such state.
>
> https://github.com/apache/tomee/blob/master/tomee/tomee-
> catalina/src/main/java/org/apache/tomee/catalina/
> TomcatSecurityService.java
>
> I think we'll grapple with questions like "should we support some local
> override if the user happens to exist locally?"  Certainly, we could.  I
> might suggest we don't for the first prototype and add that later.
>
>
> -David
>
>

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

No, CDI-2 doesn't add that much we would need.

The problem is really that IF we package this, then TomEE could _not_ run in Java7 anymore.
Which is still the official pre-requisit for EE7 servers (Java8 is just optional).

LieGrue,
strub


> Am 15.02.2018 um 14:05 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> 2018-02-15 13:30 GMT+01:00 Rudy De Busscher <rd...@gmail.com>:
> 
>>> 
>>> Can we assume Java8 for this attempt?
>>> Oh and more important: Will the integration work based on TomEE7 (would
>>> require Java7) or the upcoming TomEE8?
>>> I'd say we should focus on TomEE8 and Java8
>> 
>> 
>> MicroProfile specs are defined in Java 8, so TomEE8 seems the only option.
>> 
> 
> CDI 2 is the constraint more than java 8 which works on TomEE 7 ;). That
> said converters should still be scannable so java 8 or not is maybe not the
> main challenge - not even sure there is a challenge to be honest, just a
> clean definition without any redefinition of what is a "context" works :).
> 
> 
>> 
>> regards
>> Rudy
>> 
>> 
>> On 15 February 2018 at 09:37, Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>> 
>>> 
>>> 
>>>> Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>> :
>>>> 
>>>> Le 15 févr. 2018 01:35, "David Blevins" <da...@gmail.com> a
>>> écrit :
>>>> 
>>>> I understand there's kind of a meta conversation going on that all
>> roads
>>>> and discussions need to end at there being something to put a
>>>> microprofile-jwt git repo.  I wave a white flag and gently request a
>>>> respite from that as I don't want everything I write to be read as if
>> I'm
>>>> attempting to steer for or against.
>>>> 
>>>> I'm 100% supportive of reuse.  And there could be something of value to
>>>> reuse in the end.  But at this moment if there was a microprofile-jwt
>>> git,
>>>> even if that repo was in TomEE, I'm not sold at this point there would
>> be
>>>> enough code there to justify it.
>>> 
>>> 
>>> No, there is no meta discussion. This is about reusability in other
>>> projects. As clearly stated as that.
>>> I think we can easily get this done by splitting it in a core part and
>>> then a second part which exposes the JsonWebToken as Principal in various
>>> EE apis. The overall structure will become way cleaner imo as it would be
>>> highly modular without adding too much overhead.
>>> 
>>>> 
>>>> I'd probably lean towards getting a prototype done with the mutual
>>>> understanding this part of the discussion is still open.
>>> 
>>> +1
>>> 
>>>> Once we have code
>>>> in hand, we can have a more informed discussion and circle back to
>> reuse.
>>> 
>>> -1 You have to design with reuse in mind.
>>> I'm not talking about making it overcomplicated and unecessarily modular,
>>> but just address the things we know already.
>>> 
>>>> 
>>>>> On Feb 14, 2018, at 11:57 AM, Mark Struberg <struberg@yahoo.de.INVALID
>>> 
>>>> wrote:
>>>>> 
>>>>> If you want to have JWT working for ALL EE things then it's not
>>>> MicroProfile-JWT anymore, isn't?
>>>>> It would be much more. Not bad of course, but still way beyond of what
>>>> MicroProfile-JWT defines.
>>>> 
>>>> Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines
>> about
>>>> 11 different integration points across JAX-RS, EJB, Servlets, JACC etc.
>>> As
>>>> only JAX-RS is a required part of a MicroProfile server and the other
>>> parts
>>>> are optional, at least 7 out of the 11 integration points are also
>>> optional.
>>> 
>>> Thanks for pointing me to this.
>>> 'integration points'. Even the spec indicates that the EE part is merely
>>> integration work.
>>> That might be a lot of work of course. But it would be cool if getting
>> the
>>> JsonWebToken would merely be one line of code which is in the mp-jwt-core
>>> package.
>>> 
>>>> 
>>>> There are tests for much of them in the MicroProfile JWT TCK. The tests
>>> are
>>>> also optional, but we'd definitely want to run and pass them as well as
>>>> contribute to them if they are incomplete.
>>>> 
>>>> If the spec is incomplete and we did miss an EE integration point,
>>>> definitely want to update the spec to cover it.  Scott and I and the
>>> other
>>>> folks who worked on the spec did our best to try and enumerate the ones
>>> we
>>>> could think of, but we may have missed some.
>>>> 
>>>>> Oh and I assume it does also include a way to _create_ JsonWebTokens,
>>>> right?
>>>> 
>>>> The token creation would be done by an OAuth provider, which is outside
>>> the
>>>> MP JWT specification.
>>> 
>>> Oki, I will start a discussion over at MicroProfile.
>>> Thinking about a JsonWebTokenBuilder or something.
>>> 
>>>> 
>>>> The specification does have requirements that define what the token
>>> should
>>>> look like, but they're all very minimal so that we could be as
>> compatible
>>>> as possible with as many existing OAuth provider implementations as
>>>> possible.
>>>> 
>>>> Effectively it says the JWT must be signed with an RSA private key the
>>>> OAuth Provider owns and assumes the MicroProfile server has been given
>>> the
>>>> public key.  How that public key is passed is also outside the
>>>> specification, but generally, it'll be on disk or sitting in the docker
>>>> image somewhere.
>>> 
>>> JWT doesn't even require oauth2, isn't?
>>> Of course oauth2 _could_ be the payload. But that's no necessity for
>>> everyone.
>>> Most users will not need that actually. But they might be more interested
>>> in having a radius like single sign on via JWT.
>>> At least that's what I hear from my customers.
>>> 
>>>> 
>>>> 
>>>>> * JSON-P on the json side.
>>>> 
>>>> Agree.  This is definitely mandatory to implement the MP JWT spec as
>>> claims
>>>> can be injected as JsonObject, etc.
>>>> 
>>>>> * crypto: Whether to use the JCE built-in crypto or an external lib
>>>> should be pluggable. We just need to add a smallish SPI with a few
>>> methods.
>>>> 
>>>> Agree to disagree on this one :)  JCE is an abstraction with two well
>>> known
>>>> impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature,
>>> so
>>>> not much complexity to abstract.
>>> 
>>> Fine for me. This can easily be extendd afterwards IF we need it.
>>> 
>>> 
>>>> 
>>>>> * JsonWebToken and a way to get 'the' JWT for a single Request. That
>>>> might be a provider interface or a @RequestScoped CDI bean.
>>>> 
>>>> MP JWT spec requires there to be a dependent scoped producer for
>>>> JsonWebToken.  The bean getting JsonWebToken injected must be
>>>> RequestScoped.  Currently section 7.1.3 forbids injection into beans
>> that
>>>> are not @RequestScoped.
>>>> 
>>>> 
>>>> Any waynto have a fixed spec saying it is not portable to not do so?
>>> Having
>>>> a deployment exception for a so common case is very rude and not
>>> justified
>>>> technically. Also using provider as a woraround is not mainstream and
>>>> generally way too slow.
>>>> 
>>>> Not that supporting CharSequence can be a smooth workaround for app
>> scope
>>>> ;).
>>> 
>>> What do you mean here? I totally don't get that. Derailing?
>>> 
>>>> 
>>>> 
>>>> With that in mind, I would probably implement JsonWebToken as an
>>> immutable
>>>> class -- i.e. get the token, then create the JsonWebToken and track
>> that
>>> in
>>>> the request.  So ultimately the producer of JsonWebToken needs to get
>> the
>>>> token from the request rather than the JsonWebToken implementation
>>> itself.
>>>> 
>>> 
>>> +1 for JsonWebTokan as immutable. Snce we do not create it but only make
>>> it accessible.
>>> 
>>>> 
>>>> It is backed by jsonp so immutable by definition no?
>>>> 
>>>> 
>>>> Not yet discussed, but part of the spec is Claims can be injected as
>> any
>>>> java type using the same conversion rules as MP Config.
>>>> 
>>>> Xbean-reflect has a large set of code for java-to-string conversion.  I
>>>> suspect geronimo-config as it's own implementation of java-to-string
>>>> conversion.  There's probably some opportunity for reuse consolidation
>>>> there.
>>> 
>>> hmm, java-to-string would not be possible. The config API only has
>>> String->Java.
>>> Because the least common denominator (or 'storage') for the config is
>>> always String.
>>> And from there you convert it to a target Java type.
>>> 
>>> But why do we need java-to-string? We do not WRITE JsonWebTokens, do we?
>>> We only read them. Which is string-to-java then, right?
>>> And by using JSON-P and JSON-B we could probably defer this as well.
>>> 
>>> 
>>>> 
>>>> Potentially even an option for a "Conversion" spec.  Andres was talking
>>>> about it at the last JCP EC event in London.  His JSR-377 (Desktop
>>>> Application Framework) apparently has similar needs.
>>> 
>>> Yes, I had a talk wiht Andres about this as well.
>>> It's a bit more complicated.
>>> For example Andres needs this for the UI.
>>> So while in theory both (Config and UI) needs a conversion from
>>> string->java it might still work totally different.
>>> In the config area you want your string representation to be as portable
>>> as possible. Means you betterl _always_ use ISO or any other _fixed_
>> format.
>>> Whereas in the UI area it's exactly the other way around. You almost
>>> always want the string representation to be for the users Locale and
>>> desired language. So even for the same server this might differ even for
>>> each request.
>>> 
>>> Back to JsonWebToken. This is really more like config. The string
>>> representation is better off being a fixed format.
>>> 
>>>> Makes sense (and without any "context" please, this pollutes config
>> spec
>>>> and makes it sadly not that portable :().
>>> 
>>> Well as explained there is a kind of 'context'. I agree it's not that
>>> obvious, but there are reasons why even Stephen Coleburn failed to come
>> up
>>> with a good Converter API for many years now.
>>> 
>>> Btw, with Lambdas any conversion A->B is just a Function anyway.
>>> Can we assume Java8 for this attempt?
>>> 
>>> Oh and more important: Will the integration work based on TomEE7 (would
>>> require Java7) or the upcoming TomEE8?
>>> I'd say we should focus on TomEE8 and Java8
>>> 
>>>> 
>>>> -David
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>> 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

2018-02-15 13:30 GMT+01:00 Rudy De Busscher <rd...@gmail.com>:

> >
> > Can we assume Java8 for this attempt?
> > Oh and more important: Will the integration work based on TomEE7 (would
> > require Java7) or the upcoming TomEE8?
> > I'd say we should focus on TomEE8 and Java8
>
>
> MicroProfile specs are defined in Java 8, so TomEE8 seems the only option.
>

CDI 2 is the constraint more than java 8 which works on TomEE 7 ;). That
said converters should still be scannable so java 8 or not is maybe not the
main challenge - not even sure there is a challenge to be honest, just a
clean definition without any redefinition of what is a "context" works :).


>
> regards
> Rudy
>
>
> On 15 February 2018 at 09:37, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
> >
> >
> > > Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > >
> > > Le 15 févr. 2018 01:35, "David Blevins" <da...@gmail.com> a
> > écrit :
> > >
> > > I understand there's kind of a meta conversation going on that all
> roads
> > > and discussions need to end at there being something to put a
> > > microprofile-jwt git repo.  I wave a white flag and gently request a
> > > respite from that as I don't want everything I write to be read as if
> I'm
> > > attempting to steer for or against.
> > >
> > > I'm 100% supportive of reuse.  And there could be something of value to
> > > reuse in the end.  But at this moment if there was a microprofile-jwt
> > git,
> > > even if that repo was in TomEE, I'm not sold at this point there would
> be
> > > enough code there to justify it.
> >
> >
> > No, there is no meta discussion. This is about reusability in other
> > projects. As clearly stated as that.
> > I think we can easily get this done by splitting it in a core part and
> > then a second part which exposes the JsonWebToken as Principal in various
> > EE apis. The overall structure will become way cleaner imo as it would be
> > highly modular without adding too much overhead.
> >
> > >
> > > I'd probably lean towards getting a prototype done with the mutual
> > > understanding this part of the discussion is still open.
> >
> > +1
> >
> > > Once we have code
> > > in hand, we can have a more informed discussion and circle back to
> reuse.
> >
> > -1 You have to design with reuse in mind.
> > I'm not talking about making it overcomplicated and unecessarily modular,
> > but just address the things we know already.
> >
> > >
> > >> On Feb 14, 2018, at 11:57 AM, Mark Struberg <struberg@yahoo.de.INVALID
> >
> > > wrote:
> > >>
> > >> If you want to have JWT working for ALL EE things then it's not
> > > MicroProfile-JWT anymore, isn't?
> > >> It would be much more. Not bad of course, but still way beyond of what
> > > MicroProfile-JWT defines.
> > >
> > > Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines
> about
> > > 11 different integration points across JAX-RS, EJB, Servlets, JACC etc.
> > As
> > > only JAX-RS is a required part of a MicroProfile server and the other
> > parts
> > > are optional, at least 7 out of the 11 integration points are also
> > optional.
> >
> > Thanks for pointing me to this.
> > 'integration points'. Even the spec indicates that the EE part is merely
> > integration work.
> > That might be a lot of work of course. But it would be cool if getting
> the
> > JsonWebToken would merely be one line of code which is in the mp-jwt-core
> > package.
> >
> > >
> > > There are tests for much of them in the MicroProfile JWT TCK. The tests
> > are
> > > also optional, but we'd definitely want to run and pass them as well as
> > > contribute to them if they are incomplete.
> > >
> > > If the spec is incomplete and we did miss an EE integration point,
> > > definitely want to update the spec to cover it.  Scott and I and the
> > other
> > > folks who worked on the spec did our best to try and enumerate the ones
> > we
> > > could think of, but we may have missed some.
> > >
> > >> Oh and I assume it does also include a way to _create_ JsonWebTokens,
> > > right?
> > >
> > > The token creation would be done by an OAuth provider, which is outside
> > the
> > > MP JWT specification.
> >
> > Oki, I will start a discussion over at MicroProfile.
> > Thinking about a JsonWebTokenBuilder or something.
> >
> > >
> > > The specification does have requirements that define what the token
> > should
> > > look like, but they're all very minimal so that we could be as
> compatible
> > > as possible with as many existing OAuth provider implementations as
> > > possible.
> > >
> > > Effectively it says the JWT must be signed with an RSA private key the
> > > OAuth Provider owns and assumes the MicroProfile server has been given
> > the
> > > public key.  How that public key is passed is also outside the
> > > specification, but generally, it'll be on disk or sitting in the docker
> > > image somewhere.
> >
> > JWT doesn't even require oauth2, isn't?
> > Of course oauth2 _could_ be the payload. But that's no necessity for
> > everyone.
> > Most users will not need that actually. But they might be more interested
> > in having a radius like single sign on via JWT.
> > At least that's what I hear from my customers.
> >
> > >
> > >
> > >> * JSON-P on the json side.
> > >
> > > Agree.  This is definitely mandatory to implement the MP JWT spec as
> > claims
> > > can be injected as JsonObject, etc.
> > >
> > >> * crypto: Whether to use the JCE built-in crypto or an external lib
> > > should be pluggable. We just need to add a smallish SPI with a few
> > methods.
> > >
> > > Agree to disagree on this one :)  JCE is an abstraction with two well
> > known
> > > impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature,
> > so
> > > not much complexity to abstract.
> >
> > Fine for me. This can easily be extendd afterwards IF we need it.
> >
> >
> > >
> > >> * JsonWebToken and a way to get 'the' JWT for a single Request. That
> > > might be a provider interface or a @RequestScoped CDI bean.
> > >
> > > MP JWT spec requires there to be a dependent scoped producer for
> > > JsonWebToken.  The bean getting JsonWebToken injected must be
> > > RequestScoped.  Currently section 7.1.3 forbids injection into beans
> that
> > > are not @RequestScoped.
> > >
> > >
> > > Any waynto have a fixed spec saying it is not portable to not do so?
> > Having
> > > a deployment exception for a so common case is very rude and not
> > justified
> > > technically. Also using provider as a woraround is not mainstream and
> > > generally way too slow.
> > >
> > > Not that supporting CharSequence can be a smooth workaround for app
> scope
> > > ;).
> >
> > What do you mean here? I totally don't get that. Derailing?
> >
> > >
> > >
> > > With that in mind, I would probably implement JsonWebToken as an
> > immutable
> > > class -- i.e. get the token, then create the JsonWebToken and track
> that
> > in
> > > the request.  So ultimately the producer of JsonWebToken needs to get
> the
> > > token from the request rather than the JsonWebToken implementation
> > itself.
> > >
> >
> > +1 for JsonWebTokan as immutable. Snce we do not create it but only make
> > it accessible.
> >
> > >
> > > It is backed by jsonp so immutable by definition no?
> > >
> > >
> > > Not yet discussed, but part of the spec is Claims can be injected as
> any
> > > java type using the same conversion rules as MP Config.
> > >
> > > Xbean-reflect has a large set of code for java-to-string conversion.  I
> > > suspect geronimo-config as it's own implementation of java-to-string
> > > conversion.  There's probably some opportunity for reuse consolidation
> > > there.
> >
> > hmm, java-to-string would not be possible. The config API only has
> > String->Java.
> > Because the least common denominator (or 'storage') for the config is
> > always String.
> > And from there you convert it to a target Java type.
> >
> > But why do we need java-to-string? We do not WRITE JsonWebTokens, do we?
> > We only read them. Which is string-to-java then, right?
> > And by using JSON-P and JSON-B we could probably defer this as well.
> >
> >
> > >
> > > Potentially even an option for a "Conversion" spec.  Andres was talking
> > > about it at the last JCP EC event in London.  His JSR-377 (Desktop
> > > Application Framework) apparently has similar needs.
> >
> > Yes, I had a talk wiht Andres about this as well.
> > It's a bit more complicated.
> > For example Andres needs this for the UI.
> > So while in theory both (Config and UI) needs a conversion from
> > string->java it might still work totally different.
> > In the config area you want your string representation to be as portable
> > as possible. Means you betterl _always_ use ISO or any other _fixed_
> format.
> > Whereas in the UI area it's exactly the other way around. You almost
> > always want the string representation to be for the users Locale and
> > desired language. So even for the same server this might differ even for
> > each request.
> >
> > Back to JsonWebToken. This is really more like config. The string
> > representation is better off being a fixed format.
> >
> > > Makes sense (and without any "context" please, this pollutes config
> spec
> > > and makes it sadly not that portable :().
> >
> > Well as explained there is a kind of 'context'. I agree it's not that
> > obvious, but there are reasons why even Stephen Coleburn failed to come
> up
> > with a good Converter API for many years now.
> >
> > Btw, with Lambdas any conversion A->B is just a Function anyway.
> > Can we assume Java8 for this attempt?
> >
> > Oh and more important: Will the integration work based on TomEE7 (would
> > require Java7) or the upcoming TomEE8?
> > I'd say we should focus on TomEE8 and Java8
> >
> > >
> > > -David
> >
> > LieGrue,
> > strub
> >
> >
>

Re: Implementing Microprofile JWT

[Rudy De Busscher <rd...@gmail.com>]

>
> Can we assume Java8 for this attempt?
> Oh and more important: Will the integration work based on TomEE7 (would
> require Java7) or the upcoming TomEE8?
> I'd say we should focus on TomEE8 and Java8


MicroProfile specs are defined in Java 8, so TomEE8 seems the only option.

regards
Rudy


On 15 February 2018 at 09:37, Mark Struberg <st...@yahoo.de.invalid>
wrote:

>
>
> > Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Le 15 févr. 2018 01:35, "David Blevins" <da...@gmail.com> a
> écrit :
> >
> > I understand there's kind of a meta conversation going on that all roads
> > and discussions need to end at there being something to put a
> > microprofile-jwt git repo.  I wave a white flag and gently request a
> > respite from that as I don't want everything I write to be read as if I'm
> > attempting to steer for or against.
> >
> > I'm 100% supportive of reuse.  And there could be something of value to
> > reuse in the end.  But at this moment if there was a microprofile-jwt
> git,
> > even if that repo was in TomEE, I'm not sold at this point there would be
> > enough code there to justify it.
>
>
> No, there is no meta discussion. This is about reusability in other
> projects. As clearly stated as that.
> I think we can easily get this done by splitting it in a core part and
> then a second part which exposes the JsonWebToken as Principal in various
> EE apis. The overall structure will become way cleaner imo as it would be
> highly modular without adding too much overhead.
>
> >
> > I'd probably lean towards getting a prototype done with the mutual
> > understanding this part of the discussion is still open.
>
> +1
>
> > Once we have code
> > in hand, we can have a more informed discussion and circle back to reuse.
>
> -1 You have to design with reuse in mind.
> I'm not talking about making it overcomplicated and unecessarily modular,
> but just address the things we know already.
>
> >
> >> On Feb 14, 2018, at 11:57 AM, Mark Struberg <st...@yahoo.de.INVALID>
> > wrote:
> >>
> >> If you want to have JWT working for ALL EE things then it's not
> > MicroProfile-JWT anymore, isn't?
> >> It would be much more. Not bad of course, but still way beyond of what
> > MicroProfile-JWT defines.
> >
> > Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about
> > 11 different integration points across JAX-RS, EJB, Servlets, JACC etc.
> As
> > only JAX-RS is a required part of a MicroProfile server and the other
> parts
> > are optional, at least 7 out of the 11 integration points are also
> optional.
>
> Thanks for pointing me to this.
> 'integration points'. Even the spec indicates that the EE part is merely
> integration work.
> That might be a lot of work of course. But it would be cool if getting the
> JsonWebToken would merely be one line of code which is in the mp-jwt-core
> package.
>
> >
> > There are tests for much of them in the MicroProfile JWT TCK. The tests
> are
> > also optional, but we'd definitely want to run and pass them as well as
> > contribute to them if they are incomplete.
> >
> > If the spec is incomplete and we did miss an EE integration point,
> > definitely want to update the spec to cover it.  Scott and I and the
> other
> > folks who worked on the spec did our best to try and enumerate the ones
> we
> > could think of, but we may have missed some.
> >
> >> Oh and I assume it does also include a way to _create_ JsonWebTokens,
> > right?
> >
> > The token creation would be done by an OAuth provider, which is outside
> the
> > MP JWT specification.
>
> Oki, I will start a discussion over at MicroProfile.
> Thinking about a JsonWebTokenBuilder or something.
>
> >
> > The specification does have requirements that define what the token
> should
> > look like, but they're all very minimal so that we could be as compatible
> > as possible with as many existing OAuth provider implementations as
> > possible.
> >
> > Effectively it says the JWT must be signed with an RSA private key the
> > OAuth Provider owns and assumes the MicroProfile server has been given
> the
> > public key.  How that public key is passed is also outside the
> > specification, but generally, it'll be on disk or sitting in the docker
> > image somewhere.
>
> JWT doesn't even require oauth2, isn't?
> Of course oauth2 _could_ be the payload. But that's no necessity for
> everyone.
> Most users will not need that actually. But they might be more interested
> in having a radius like single sign on via JWT.
> At least that's what I hear from my customers.
>
> >
> >
> >> * JSON-P on the json side.
> >
> > Agree.  This is definitely mandatory to implement the MP JWT spec as
> claims
> > can be injected as JsonObject, etc.
> >
> >> * crypto: Whether to use the JCE built-in crypto or an external lib
> > should be pluggable. We just need to add a smallish SPI with a few
> methods.
> >
> > Agree to disagree on this one :)  JCE is an abstraction with two well
> known
> > impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature,
> so
> > not much complexity to abstract.
>
> Fine for me. This can easily be extendd afterwards IF we need it.
>
>
> >
> >> * JsonWebToken and a way to get 'the' JWT for a single Request. That
> > might be a provider interface or a @RequestScoped CDI bean.
> >
> > MP JWT spec requires there to be a dependent scoped producer for
> > JsonWebToken.  The bean getting JsonWebToken injected must be
> > RequestScoped.  Currently section 7.1.3 forbids injection into beans that
> > are not @RequestScoped.
> >
> >
> > Any waynto have a fixed spec saying it is not portable to not do so?
> Having
> > a deployment exception for a so common case is very rude and not
> justified
> > technically. Also using provider as a woraround is not mainstream and
> > generally way too slow.
> >
> > Not that supporting CharSequence can be a smooth workaround for app scope
> > ;).
>
> What do you mean here? I totally don't get that. Derailing?
>
> >
> >
> > With that in mind, I would probably implement JsonWebToken as an
> immutable
> > class -- i.e. get the token, then create the JsonWebToken and track that
> in
> > the request.  So ultimately the producer of JsonWebToken needs to get the
> > token from the request rather than the JsonWebToken implementation
> itself.
> >
>
> +1 for JsonWebTokan as immutable. Snce we do not create it but only make
> it accessible.
>
> >
> > It is backed by jsonp so immutable by definition no?
> >
> >
> > Not yet discussed, but part of the spec is Claims can be injected as any
> > java type using the same conversion rules as MP Config.
> >
> > Xbean-reflect has a large set of code for java-to-string conversion.  I
> > suspect geronimo-config as it's own implementation of java-to-string
> > conversion.  There's probably some opportunity for reuse consolidation
> > there.
>
> hmm, java-to-string would not be possible. The config API only has
> String->Java.
> Because the least common denominator (or 'storage') for the config is
> always String.
> And from there you convert it to a target Java type.
>
> But why do we need java-to-string? We do not WRITE JsonWebTokens, do we?
> We only read them. Which is string-to-java then, right?
> And by using JSON-P and JSON-B we could probably defer this as well.
>
>
> >
> > Potentially even an option for a "Conversion" spec.  Andres was talking
> > about it at the last JCP EC event in London.  His JSR-377 (Desktop
> > Application Framework) apparently has similar needs.
>
> Yes, I had a talk wiht Andres about this as well.
> It's a bit more complicated.
> For example Andres needs this for the UI.
> So while in theory both (Config and UI) needs a conversion from
> string->java it might still work totally different.
> In the config area you want your string representation to be as portable
> as possible. Means you betterl _always_ use ISO or any other _fixed_ format.
> Whereas in the UI area it's exactly the other way around. You almost
> always want the string representation to be for the users Locale and
> desired language. So even for the same server this might differ even for
> each request.
>
> Back to JsonWebToken. This is really more like config. The string
> representation is better off being a fixed format.
>
> > Makes sense (and without any "context" please, this pollutes config spec
> > and makes it sadly not that portable :().
>
> Well as explained there is a kind of 'context'. I agree it's not that
> obvious, but there are reasons why even Stephen Coleburn failed to come up
> with a good Converter API for many years now.
>
> Btw, with Lambdas any conversion A->B is just a Function anyway.
> Can we assume Java8 for this attempt?
>
> Oh and more important: Will the integration work based on TomEE7 (would
> require Java7) or the upcoming TomEE8?
> I'd say we should focus on TomEE8 and Java8
>
> >
> > -David
>
> LieGrue,
> strub
>
>

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

> Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> Le 15 févr. 2018 01:35, "David Blevins" <da...@gmail.com> a écrit :
> 
> I understand there's kind of a meta conversation going on that all roads
> and discussions need to end at there being something to put a
> microprofile-jwt git repo.  I wave a white flag and gently request a
> respite from that as I don't want everything I write to be read as if I'm
> attempting to steer for or against.
> 
> I'm 100% supportive of reuse.  And there could be something of value to
> reuse in the end.  But at this moment if there was a microprofile-jwt git,
> even if that repo was in TomEE, I'm not sold at this point there would be
> enough code there to justify it.


No, there is no meta discussion. This is about reusability in other projects. As clearly stated as that.
I think we can easily get this done by splitting it in a core part and then a second part which exposes the JsonWebToken as Principal in various EE apis. The overall structure will become way cleaner imo as it would be highly modular without adding too much overhead. 

> 
> I'd probably lean towards getting a prototype done with the mutual
> understanding this part of the discussion is still open.  

+1

> Once we have code
> in hand, we can have a more informed discussion and circle back to reuse.

-1 You have to design with reuse in mind. 
I'm not talking about making it overcomplicated and unecessarily modular, but just address the things we know already.

> 
>> On Feb 14, 2018, at 11:57 AM, Mark Struberg <st...@yahoo.de.INVALID>
> wrote:
>> 
>> If you want to have JWT working for ALL EE things then it's not
> MicroProfile-JWT anymore, isn't?
>> It would be much more. Not bad of course, but still way beyond of what
> MicroProfile-JWT defines.
> 
> Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about
> 11 different integration points across JAX-RS, EJB, Servlets, JACC etc. As
> only JAX-RS is a required part of a MicroProfile server and the other parts
> are optional, at least 7 out of the 11 integration points are also optional.

Thanks for pointing me to this.
'integration points'. Even the spec indicates that the EE part is merely integration work.
That might be a lot of work of course. But it would be cool if getting the JsonWebToken would merely be one line of code which is in the mp-jwt-core package.

> 
> There are tests for much of them in the MicroProfile JWT TCK. The tests are
> also optional, but we'd definitely want to run and pass them as well as
> contribute to them if they are incomplete.
> 
> If the spec is incomplete and we did miss an EE integration point,
> definitely want to update the spec to cover it.  Scott and I and the other
> folks who worked on the spec did our best to try and enumerate the ones we
> could think of, but we may have missed some.
> 
>> Oh and I assume it does also include a way to _create_ JsonWebTokens,
> right?
> 
> The token creation would be done by an OAuth provider, which is outside the
> MP JWT specification.

Oki, I will start a discussion over at MicroProfile.
Thinking about a JsonWebTokenBuilder or something.

> 
> The specification does have requirements that define what the token should
> look like, but they're all very minimal so that we could be as compatible
> as possible with as many existing OAuth provider implementations as
> possible.
> 
> Effectively it says the JWT must be signed with an RSA private key the
> OAuth Provider owns and assumes the MicroProfile server has been given the
> public key.  How that public key is passed is also outside the
> specification, but generally, it'll be on disk or sitting in the docker
> image somewhere.

JWT doesn't even require oauth2, isn't?
Of course oauth2 _could_ be the payload. But that's no necessity for everyone.
Most users will not need that actually. But they might be more interested in having a radius like single sign on via JWT.
At least that's what I hear from my customers.

> 
> 
>> * JSON-P on the json side.
> 
> Agree.  This is definitely mandatory to implement the MP JWT spec as claims
> can be injected as JsonObject, etc.
> 
>> * crypto: Whether to use the JCE built-in crypto or an external lib
> should be pluggable. We just need to add a smallish SPI with a few methods.
> 
> Agree to disagree on this one :)  JCE is an abstraction with two well known
> impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature, so
> not much complexity to abstract.

Fine for me. This can easily be extendd afterwards IF we need it.


> 
>> * JsonWebToken and a way to get 'the' JWT for a single Request. That
> might be a provider interface or a @RequestScoped CDI bean.
> 
> MP JWT spec requires there to be a dependent scoped producer for
> JsonWebToken.  The bean getting JsonWebToken injected must be
> RequestScoped.  Currently section 7.1.3 forbids injection into beans that
> are not @RequestScoped.
> 
> 
> Any waynto have a fixed spec saying it is not portable to not do so? Having
> a deployment exception for a so common case is very rude and not justified
> technically. Also using provider as a woraround is not mainstream and
> generally way too slow.
> 
> Not that supporting CharSequence can be a smooth workaround for app scope
> ;).

What do you mean here? I totally don't get that. Derailing?

> 
> 
> With that in mind, I would probably implement JsonWebToken as an immutable
> class -- i.e. get the token, then create the JsonWebToken and track that in
> the request.  So ultimately the producer of JsonWebToken needs to get the
> token from the request rather than the JsonWebToken implementation itself.
> 

+1 for JsonWebTokan as immutable. Snce we do not create it but only make it accessible.

> 
> It is backed by jsonp so immutable by definition no?
> 
> 
> Not yet discussed, but part of the spec is Claims can be injected as any
> java type using the same conversion rules as MP Config.
> 
> Xbean-reflect has a large set of code for java-to-string conversion.  I
> suspect geronimo-config as it's own implementation of java-to-string
> conversion.  There's probably some opportunity for reuse consolidation
> there.

hmm, java-to-string would not be possible. The config API only has String->Java.
Because the least common denominator (or 'storage') for the config is always String. 
And from there you convert it to a target Java type.

But why do we need java-to-string? We do not WRITE JsonWebTokens, do we?
We only read them. Which is string-to-java then, right? 
And by using JSON-P and JSON-B we could probably defer this as well.


> 
> Potentially even an option for a "Conversion" spec.  Andres was talking
> about it at the last JCP EC event in London.  His JSR-377 (Desktop
> Application Framework) apparently has similar needs.

Yes, I had a talk wiht Andres about this as well. 
It's a bit more complicated. 
For example Andres needs this for the UI.
So while in theory both (Config and UI) needs a conversion from string->java it might still work totally different.
In the config area you want your string representation to be as portable as possible. Means you betterl _always_ use ISO or any other _fixed_ format.
Whereas in the UI area it's exactly the other way around. You almost always want the string representation to be for the users Locale and desired language. So even for the same server this might differ even for each request. 

Back to JsonWebToken. This is really more like config. The string representation is better off being a fixed format.

> Makes sense (and without any "context" please, this pollutes config spec
> and makes it sadly not that portable :().

Well as explained there is a kind of 'context'. I agree it's not that obvious, but there are reasons why even Stephen Coleburn failed to come up with a good Converter API for many years now.

Btw, with Lambdas any conversion A->B is just a Function anyway.
Can we assume Java8 for this attempt?

Oh and more important: Will the integration work based on TomEE7 (would require Java7) or the upcoming TomEE8?
I'd say we should focus on TomEE8 and Java8

> 
> -David

LieGrue,
strub

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

Le 15 févr. 2018 01:35, "David Blevins" <da...@gmail.com> a écrit :

I understand there's kind of a meta conversation going on that all roads
and discussions need to end at there being something to put a
microprofile-jwt git repo.  I wave a white flag and gently request a
respite from that as I don't want everything I write to be read as if I'm
attempting to steer for or against.

I'm 100% supportive of reuse.  And there could be something of value to
reuse in the end.  But at this moment if there was a microprofile-jwt git,
even if that repo was in TomEE, I'm not sold at this point there would be
enough code there to justify it.

I'd probably lean towards getting a prototype done with the mutual
understanding this part of the discussion is still open.  Once we have code
in hand, we can have a more informed discussion and circle back to reuse.

> On Feb 14, 2018, at 11:57 AM, Mark Struberg <st...@yahoo.de.INVALID>
wrote:
>
> If you want to have JWT working for ALL EE things then it's not
MicroProfile-JWT anymore, isn't?
> It would be much more. Not bad of course, but still way beyond of what
MicroProfile-JWT defines.

Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about
11 different integration points across JAX-RS, EJB, Servlets, JACC etc. As
only JAX-RS is a required part of a MicroProfile server and the other parts
are optional, at least 7 out of the 11 integration points are also optional.

There are tests for much of them in the MicroProfile JWT TCK. The tests are
also optional, but we'd definitely want to run and pass them as well as
contribute to them if they are incomplete.

If the spec is incomplete and we did miss an EE integration point,
definitely want to update the spec to cover it.  Scott and I and the other
folks who worked on the spec did our best to try and enumerate the ones we
could think of, but we may have missed some.

> Oh and I assume it does also include a way to _create_ JsonWebTokens,
right?

The token creation would be done by an OAuth provider, which is outside the
MP JWT specification.

The specification does have requirements that define what the token should
look like, but they're all very minimal so that we could be as compatible
as possible with as many existing OAuth provider implementations as
possible.

Effectively it says the JWT must be signed with an RSA private key the
OAuth Provider owns and assumes the MicroProfile server has been given the
public key.  How that public key is passed is also outside the
specification, but generally, it'll be on disk or sitting in the docker
image somewhere.


> * JSON-P on the json side.

Agree.  This is definitely mandatory to implement the MP JWT spec as claims
can be injected as JsonObject, etc.

> * crypto: Whether to use the JCE built-in crypto or an external lib
should be pluggable. We just need to add a smallish SPI with a few methods.

Agree to disagree on this one :)  JCE is an abstraction with two well known
impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature, so
not much complexity to abstract.

> * JsonWebToken and a way to get 'the' JWT for a single Request. That
might be a provider interface or a @RequestScoped CDI bean.

MP JWT spec requires there to be a dependent scoped producer for
JsonWebToken.  The bean getting JsonWebToken injected must be
RequestScoped.  Currently section 7.1.3 forbids injection into beans that
are not @RequestScoped.


Any waynto have a fixed spec saying it is not portable to not do so? Having
a deployment exception for a so common case is very rude and not justified
technically. Also using provider as a woraround is not mainstream and
generally way too slow.

Not that supporting CharSequence can be a smooth workaround for app scope
;).


With that in mind, I would probably implement JsonWebToken as an immutable
class -- i.e. get the token, then create the JsonWebToken and track that in
the request.  So ultimately the producer of JsonWebToken needs to get the
token from the request rather than the JsonWebToken implementation itself.


It is backed by jsonp so immutable by definition no?


Not yet discussed, but part of the spec is Claims can be injected as any
java type using the same conversion rules as MP Config.

Xbean-reflect has a large set of code for java-to-string conversion.  I
suspect geronimo-config as it's own implementation of java-to-string
conversion.  There's probably some opportunity for reuse consolidation
there.

Potentially even an option for a "Conversion" spec.  Andres was talking
about it at the last JCP EC event in London.  His JSR-377 (Desktop
Application Framework) apparently has similar needs.


Makes sense (and without any "context" please, this pollutes config spec
and makes it sadly not that portable :().



-David

Re: Implementing Microprofile JWT

[David Blevins <da...@gmail.com>]

I understand there's kind of a meta conversation going on that all roads and discussions need to end at there being something to put a microprofile-jwt git repo.  I wave a white flag and gently request a respite from that as I don't want everything I write to be read as if I'm attempting to steer for or against.

I'm 100% supportive of reuse.  And there could be something of value to reuse in the end.  But at this moment if there was a microprofile-jwt git, even if that repo was in TomEE, I'm not sold at this point there would be enough code there to justify it.

I'd probably lean towards getting a prototype done with the mutual understanding this part of the discussion is still open.  Once we have code in hand, we can have a more informed discussion and circle back to reuse.

> On Feb 14, 2018, at 11:57 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
> 
> If you want to have JWT working for ALL EE things then it's not MicroProfile-JWT anymore, isn't? 
> It would be much more. Not bad of course, but still way beyond of what MicroProfile-JWT defines.

Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about 11 different integration points across JAX-RS, EJB, Servlets, JACC etc. As only JAX-RS is a required part of a MicroProfile server and the other parts are optional, at least 7 out of the 11 integration points are also optional.

There are tests for much of them in the MicroProfile JWT TCK. The tests are also optional, but we'd definitely want to run and pass them as well as contribute to them if they are incomplete.

If the spec is incomplete and we did miss an EE integration point, definitely want to update the spec to cover it.  Scott and I and the other folks who worked on the spec did our best to try and enumerate the ones we could think of, but we may have missed some.

> Oh and I assume it does also include a way to _create_ JsonWebTokens, right?

The token creation would be done by an OAuth provider, which is outside the MP JWT specification.

The specification does have requirements that define what the token should look like, but they're all very minimal so that we could be as compatible as possible with as many existing OAuth provider implementations as possible.

Effectively it says the JWT must be signed with an RSA private key the OAuth Provider owns and assumes the MicroProfile server has been given the public key.  How that public key is passed is also outside the specification, but generally, it'll be on disk or sitting in the docker image somewhere.


> * JSON-P on the json side.

Agree.  This is definitely mandatory to implement the MP JWT spec as claims can be injected as JsonObject, etc.

> * crypto: Whether to use the JCE built-in crypto or an external lib should be pluggable. We just need to add a smallish SPI with a few methods.

Agree to disagree on this one :)  JCE is an abstraction with two well known impls (OpenJDK and BouncyCastle).  It's 3-4 lines to check a signature, so not much complexity to abstract.

> * JsonWebToken and a way to get 'the' JWT for a single Request. That might be a provider interface or a @RequestScoped CDI bean. 

MP JWT spec requires there to be a dependent scoped producer for JsonWebToken.  The bean getting JsonWebToken injected must be RequestScoped.  Currently section 7.1.3 forbids injection into beans that are not @RequestScoped.

With that in mind, I would probably implement JsonWebToken as an immutable class -- i.e. get the token, then create the JsonWebToken and track that in the request.  So ultimately the producer of JsonWebToken needs to get the token from the request rather than the JsonWebToken implementation itself.

Not yet discussed, but part of the spec is Claims can be injected as any java type using the same conversion rules as MP Config.

Xbean-reflect has a large set of code for java-to-string conversion.  I suspect geronimo-config as it's own implementation of java-to-string conversion.  There's probably some opportunity for reuse consolidation there.

Potentially even an option for a "Conversion" spec.  Andres was talking about it at the last JCP EC event in London.  His JSR-377 (Desktop Application Framework) apparently has similar needs.


-David

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

If you want to have JWT working for ALL EE things then it's not MicroProfile-JWT anymore, isn't? 
It would be much more. Not bad of course, but still way beyond of what MicroProfile-JWT defines.

Anyway, I asked myself how to 'slice' this the right way.
And imo the natural interfaces would be somthing like

* JSON-P on the json side. 
* crypto: Whether to use the JCE built-in crypto or an external lib should be pluggable. We just need to add a smallish SPI with a few methods.
* JsonWebToken and a way to get 'the' JWT for a single Request. That might be a provider interface or a @RequestScoped CDI bean. 

Oh and I assume it does also include a way to _create_ JsonWebTokens, right?
Could not find this part in the microprofile-jwt discussion/source. Anyone?

But apart from that that's it!

Everything else - including HttpServletRequest Principal, EJB isUserInRole, etc is an integration aspect in other parts!
The microprofil-jwt impl is perfectly agnostic to TomEE nor anything else. The integration and propagation to all the other EE parts is an integration task into TomEE. 

If we cut it that way we have a rather cleanish API which we can easily maintain in the future. 
If we start to bake in TomEE features into the mp-jwt core then welcome to monolith scariness I'd say.


> to be injected into @RequestScoped beans
not injected INTO, but the information itself is provided as @RequestScoped bean.
Of course you can inject it into anything actually. 


> That part will be a bit tricky, but effectively we need a dependent-scoped
> producer that can find the JWT data in the active request.  Perhaps by
> looking in the ThreadContext.
Yes, of course the JWT is request scoped. Taken from a HTTP header in a ServletFilter usually.

wdyt?

LieGrue,
strub



> Am 14.02.2018 um 19:19 schrieb David Blevins <da...@gmail.com>:
> 
>> On Feb 14, 2018, at 8:49 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>> 
>>> 
>>> I think one of the things we'll find most puzzling about how to do the integration is that the Tomcat flavor of this is written assuming the users exist in a Tomcat Realm.  The whole point of JWT is that they do not and the server has no such state.
>>> 
>>> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
>>> 
>>> I think we'll grapple with questions like "should we support some local override if the user happens to exist locally?"  Certainly, we could.  I might suggest we don't for the first prototype and add that later.
>> 
>> Didn't think about this yet, but I assume that's because their contract is to keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, even for JWT?
> 
> Correct.
> 
>> Don't know from the back of my mind about the MicroProfile-JWT contract. But MicroProfile NOT being based on Servlets I assume they have just an @Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1].
>> 
>> While this extends Principal I still think it will be hard to tweak HttpServletRequest to work with it.
>> But do we? 
> 
> We do, yes.
> 
> You're correct in that MicroProfile itself doesn't include Servlets, EJB, etc. but making sure JWTs worked for those things is definitely what we were trying to do in defining the spec.  The goal is that 100% of the security concepts in Java EE would work against a JWT; EJB isCallerInRole, EJB @RolesAllowed, Servlet getCallerPrincipal, exposing a JWT as a Principal, a few new Java EE Security calls, etc.
> 
> The fact that MicroProfile itself doesn't require the specs for all the touch points we needed/wanted was handled by effectively making all those things optional.  Despite them being optional, we tried to phrase it like "if you do implement it, it should work like this" and there are TCK tests to go along with a good chunk of it.
> 
> We were very much trying to define EE security as it pertains to JWT, while doing our best to navigate the Java EE and MicroProfile relationship.
> 
> Now that EE is moving to Eclipse, EE Security and MicroProfile JWT security are highly likely to meld in some way.
> 
> 
> -David

Re: Implementing Microprofile JWT

[David Blevins <da...@gmail.com>]

> On Feb 14, 2018, at 8:49 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
> 
>> 
>> I think one of the things we'll find most puzzling about how to do the integration is that the Tomcat flavor of this is written assuming the users exist in a Tomcat Realm.  The whole point of JWT is that they do not and the server has no such state.
>> 
>> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
>> 
>> I think we'll grapple with questions like "should we support some local override if the user happens to exist locally?"  Certainly, we could.  I might suggest we don't for the first prototype and add that later.
> 
> Didn't think about this yet, but I assume that's because their contract is to keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, even for JWT?

Correct.

> Don't know from the back of my mind about the MicroProfile-JWT contract. But MicroProfile NOT being based on Servlets I assume they have just an @Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1].
> 
> While this extends Principal I still think it will be hard to tweak HttpServletRequest to work with it.
> But do we? 

We do, yes.

You're correct in that MicroProfile itself doesn't include Servlets, EJB, etc. but making sure JWTs worked for those things is definitely what we were trying to do in defining the spec.  The goal is that 100% of the security concepts in Java EE would work against a JWT; EJB isCallerInRole, EJB @RolesAllowed, Servlet getCallerPrincipal, exposing a JWT as a Principal, a few new Java EE Security calls, etc.

The fact that MicroProfile itself doesn't require the specs for all the touch points we needed/wanted was handled by effectively making all those things optional.  Despite them being optional, we tried to phrase it like "if you do implement it, it should work like this" and there are TCK tests to go along with a good chunk of it.

We were very much trying to define EE security as it pertains to JWT, while doing our best to navigate the Java EE and MicroProfile relationship.

Now that EE is moving to Eclipse, EE Security and MicroProfile JWT security are highly likely to meld in some way.


-David

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

> 
> I think one of the things we'll find most puzzling about how to do the integration is that the Tomcat flavor of this is written assuming the users exist in a Tomcat Realm.  The whole point of JWT is that they do not and the server has no such state.
> 
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
> 
> I think we'll grapple with questions like "should we support some local override if the user happens to exist locally?"  Certainly, we could.  I might suggest we don't for the first prototype and add that later.

Didn't think about this yet, but I assume that's because their contract is to keep HttpServletRequest#getUserPrincipal() and #isUserInRole working, even for JWT?
Don't know from the back of my mind about the MicroProfile-JWT contract. But MicroProfile NOT being based on Servlets I assume they have just an @Inject-able org.eclipse.microprofile.jwt.JsonWebToken [1].

While this extends Principal I still think it will be hard to tweak HttpServletRequest to work with it.
But do we? 

LieGrue,
strub

[1] https://github.com/eclipse/microprofile-jwt-auth/blob/master/api/src/main/java/org/eclipse/microprofile/jwt/JsonWebToken.java


> Am 14.02.2018 um 17:30 schrieb David Blevins <da...@gmail.com>:
> 
> 
>> On Feb 13, 2018, at 3:43 AM, John D. Ament <jo...@apache.org> wrote:
>> 
>> The JWT spec is weird, because it defined non MP runtime behavior in addition to MP runtime behavior; so there may be more integration work in a fuller app server like TomEE.
> 
> Agreed. I'd describe the MicorProfile JWT spec as almost all integration.
> 
> There are also optional integration parts for EJB which I think we'd definitely implement.
> 
>> On Feb 13, 2018, at 6:53 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>> 
>> I know JWT a bit and I wonder whether doing the signing part is just a bit of Json (JSON-P) + commons-crypto?
>> After all JWT is especially designed to be lightweight and straight forward.
> 
> Agreed.  We could definitely get by with JSON-P and even the built-in JVM crypto.  No need for commons-crypto.
> 
> The MicroProfile JWT specification is intentionally "opinionated" about the JWT format and only allows for compact JWTs and RSA signatures.  The actual JOSE specifications allow for much greater flexibility and options, which is why libraries like Nimbus exist.
> 
> That said, I would still probably prototype with Nimbus and cut it out only after everything works.  Just to make sure I was focusing on the right part of the problem.
> 
>> On Feb 13, 2018, at 7:58 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
>> 
>> I'm more worried about the authorisation and authentication interface. 
>> Anything EE security seems way too heavyweight for me. This might work out for TomEE, but would kill it's use in any more lightweight approach.
> 
>> On Feb 13, 2018, at 11:27 AM, Rudy De Busscher <rd...@gmail.com> wrote:
>> 
>> I used JASPIC as it seemed to most natural way to feed the EE system
>> with authorisation
>> and authentication into the system.
>> 
>> But probably need deep integration with server code because otherwise, the
>> JWT authentication mechanism is an all or nothing system, which is not the
>> best solution (maybe less a problem with MicroServices but if you want to
>> use it in a more general way it is an obstacle)
> 
> These last two are very related.  JASPIC would be great, but TomEE (specifically the OpenEJB part) doesn't implement it.  All of the EJB calls for isCallerInRole etc are wired in and fed through this interface.
> 
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java
> 
> I think one of the things we'll find most puzzling about how to do the integration is that the Tomcat flavor of this is written assuming the users exist in a Tomcat Realm.  The whole point of JWT is that they do not and the server has no such state.
> 
> https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java
> 
> I think we'll grapple with questions like "should we support some local override if the user happens to exist locally?"  Certainly, we could.  I might suggest we don't for the first prototype and add that later.
> 
> 
> -David
> 

Re: Implementing Microprofile JWT

[David Blevins <da...@gmail.com>]

> On Feb 13, 2018, at 3:43 AM, John D. Ament <jo...@apache.org> wrote:
> 
> The JWT spec is weird, because it defined non MP runtime behavior in addition to MP runtime behavior; so there may be more integration work in a fuller app server like TomEE.

Agreed. I'd describe the MicorProfile JWT spec as almost all integration.

There are also optional integration parts for EJB which I think we'd definitely implement.

> On Feb 13, 2018, at 6:53 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
> 
> I know JWT a bit and I wonder whether doing the signing part is just a bit of Json (JSON-P) + commons-crypto?
> After all JWT is especially designed to be lightweight and straight forward.

Agreed.  We could definitely get by with JSON-P and even the built-in JVM crypto.  No need for commons-crypto.

The MicroProfile JWT specification is intentionally "opinionated" about the JWT format and only allows for compact JWTs and RSA signatures.  The actual JOSE specifications allow for much greater flexibility and options, which is why libraries like Nimbus exist.

That said, I would still probably prototype with Nimbus and cut it out only after everything works.  Just to make sure I was focusing on the right part of the problem.

> On Feb 13, 2018, at 7:58 AM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
> 
> I'm more worried about the authorisation and authentication interface. 
> Anything EE security seems way too heavyweight for me. This might work out for TomEE, but would kill it's use in any more lightweight approach.

> On Feb 13, 2018, at 11:27 AM, Rudy De Busscher <rd...@gmail.com> wrote:
> 
> I used JASPIC as it seemed to most natural way to feed the EE system
> with authorisation
> and authentication into the system.
> 
> But probably need deep integration with server code because otherwise, the
> JWT authentication mechanism is an all or nothing system, which is not the
> best solution (maybe less a problem with MicroServices but if you want to
> use it in a more general way it is an obstacle)

These last two are very related.  JASPIC would be great, but TomEE (specifically the OpenEJB part) doesn't implement it.  All of the EJB calls for isCallerInRole etc are wired in and fed through this interface.

https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/spi/SecurityService.java

I think one of the things we'll find most puzzling about how to do the integration is that the Tomcat flavor of this is written assuming the users exist in a Tomcat Realm.  The whole point of JWT is that they do not and the server has no such state.

https://github.com/apache/tomee/blob/master/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/TomcatSecurityService.java

I think we'll grapple with questions like "should we support some local override if the user happens to exist locally?"  Certainly, we could.  I might suggest we don't for the first prototype and add that later.


-David

Re: Implementing Microprofile JWT

[Rudy De Busscher <rd...@gmail.com>]

>
> I'm more worried about the authorisation and authentication interface.


I used JASPIC as it seemed to most natural way to feed the EE system
with authorisation
and authentication into the system.

But probably need deep integration with server code because otherwise, the
JWT authentication mechanism is an all or nothing system, which is not the
best solution (maybe less a problem with MicroServices but if you want to
use it in a more general way it is an obstacle)

Regards
Rudy


On 13 February 2018 at 16:58, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> Might do as well.
> But the JSON-P part is really well abstracted. So this is easy to plug-in.
>
> I'm more worried about the authorisation and authentication interface.
> Anything EE security seems way too heavyweight for me. This might work out
> for TomEE, but would kill it's use in any more lightweight approach.
> So probably introduce an own pluggable SPI for authentication and
> authorisation?
> Then it really could be done pretty much anywhere. Or do we have yet
> another 'interface area'?
>
> LieGrue,
> strub
>
>
> > Am 13.02.2018 um 16:52 schrieb Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com>:
> >
> > I was also thinking about a Johnzon extension (kinda)
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> >> I know JWT a bit and I wonder whether doing the signing part is just a
> bit
> >> of Json (JSON-P) + commons-crypto?
> >> After all JWT is especially designed to be lightweight and straight
> >> forward.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> >>> :
> >>>
> >>> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com
> >>> :
> >>>
> >>>> Thanks for the feedback Jon.
> >>>>
> >>>> I had a couple of exchanges with Rudy which is happy to contribute
> some
> >>>> code as well.
> >>>> From what I have understood and seen, most of the code is integration
> >> code
> >>>> and there is at least from my current knowledge a little bit of code
> to
> >> put
> >>>> together in a reusable manner in a reusable library (where ever it
> >> sits).
> >>>> I was planning to do a quick prototype and get it to work from end to
> >> end
> >>>> into a working branch so we can move the discussion forward and see
> >> exactly
> >>>> where we go.
> >>>>
> >>>> Regarding the signing library, I am kinda on the same page.
> >>>> I don't see myself rewriting Johnzon to parse JSON and then Jose or
> >> Nimbus
> >>>> to do signing. There is absolutely no point at least for the POC.
> Again,
> >>>> we'll see if I get something working what we can do.
> >>>>
> >>>>
> >>>>
> >>> Agreeing for a PoC but for a production ready software it is if it can
> >>> conflict or bring drawbacks to the users to import the solution. The
> json
> >>> lib should at least be pluggable - avoids to shade/rewrite anything but
> >> let
> >>> the integrator use what he already has. Side note for json: for the
> >> overall
> >>> consistency using JSON-P makes it easy to get a common API which
> doesn't
> >>> need any investment and solves that "plug your impl" smoothly. For the
> >>> signing part it is a bit different since it will easily bring a huge
> >> stack
> >>> - how many bring jackson, simple-json, ... by default and are not
> >>> pluggable. This is an issue and can even lead to not working
> >> installations.
> >>> If you doubt I have like 700 components to show you it is not a random
> or
> >>> theorical thought. Investment is also quite light so not sure it does
> >> worth
> >>> speaking about it days.
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <
> johndament@apache.org>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 2018/02/12 20:42:58, Jonathan Gallimore <
> >> jonathan.gallimore@gmail.com
> >>>>>
> >>>>> wrote:
> >>>>>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> No Andy, as mentionned in the discussion Geronimo hosts the
> >>>>> microprofile
> >>>>>>> @asf. This is why jwt should probably be done in geronimo which is
> >>>> the
> >>>>> asf
> >>>>>>> ee related project umbrella.
> >>>>>>>
> >>>>>>
> >>>>>> I don't recall that discussion. Where did it take place?
> >>>>>
> >>>>> I *think* he meant me.  The only time JWT came up on Geronimo was at
> >> [1].
> >>>>> I had mentioned bringing over an impl based on Jose4J, Romain felt
> very
> >>>>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why
> that
> >>>> is,
> >>>>> but it seemed based on the discussion we had two different aims so it
> >>>>> wasn't something I pushed forward on.  If there's interest within
> TomEE
> >>>> to
> >>>>> get a JWT impl up and running, I'd be happy to help (though I do feel
> >>>>> strongly relying on a 3rd party lib for the actual signature
> >> validation +
> >>>>> external sig support is important; to avoid that overhead).
> >>>>>
> >>>>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast
> rules
> >>>>> about what projects are allowed to host.  For example, there's
> interest
> >>>>> within Skywalking to host the CDI and JAX-RS extensions to support
> >>>> OpenApi;
> >>>>> but this spec doesn't represent something any server vendor would
> >> support
> >>>>> since its really about your APM solution.  CXF happily took on the MP
> >>>> Rest
> >>>>> Client when I proposed it; though I would hope TomEE relies on the
> CXF
> >>>>> library instead of crafting their own client (selfish desires).  The
> >> JWT
> >>>>> spec is weird, because it defined non MP runtime behavior in addition
> >> to
> >>>> MP
> >>>>> runtime behavior; so there may be more integration work in a fuller
> app
> >>>>> server like TomEE.
> >>>>>
> >>>>> </peanut-gallery>
> >>>>>
> >>>>> John
> >>>>>
> >>>>> [1]: https://lists.apache.org/thread.html/
> >> 4edc997cfe2e45aaf25bb118bc6216
> >>>>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I understand it is not the most convenient for tomitribe which
> >>>> probably
> >>>>>>> perfers to own the full project(s) but as a foundation member I d
> >>>>> really
> >>>>>>> like to not let company details pollute projects
> >>>>>>
> >>>>>>
> >>>>>>> Also the discussion made clear to not do it in current repo
> whatever
> >>>>>>> project is used as umbrella so we should revert that and finish the
> >>>>>>> discussion before any action to not kill tomee project by a hard
> >>>>> company
> >>>>>>> driven management making it no more in the OSS spirit.
> >>>>>>>
> >>>>>>
> >>>>>> I agree the discussion should happen first, and I note that the
> change
> >>>>> has
> >>>>>> been reverted. I recall that we agreed on this list that we'd create
> >>>> new
> >>>>>> git projects for Sheldon and Chatterbox under the TomEE umbrella.
> >>>> Should
> >>>>>> other components sit under TomEE, I imagine that they would follow
> the
> >>>>> same
> >>>>>> pattern - i.e. discuss first, agree location, create repo or move
> >>>> things
> >>>>>> around as appropriate.
> >>>>>>
> >>>>>> I don't know what your specific issues are here, but I think you are
> >>>>> making
> >>>>>> some assumptions that are simply not true.
> >>>>>>
> >>>>>> Jon
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <agumbrecht@tomitribe.com
> >
> >>>> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> "Parts of the components skeletons you just created"
> >>>>>>>>
> >>>>>>>> They're just logically named empty modules for pending work?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/02/18 20:42, Mark Struberg wrote:
> >>>>>>>>
> >>>>>>>>> And what's that for?
> >>>>>>>>>
> >>>>>>>>> Is there any behind the scene stuff going on at Tomitribe or can
> >>>> we
> >>>>>>>>> finally get back to discussing such things on the Apache lists?
> >>>>>>>>>
> >>>>>>>>> Before we go on I'd would first finish the discussion how we want
> >>>> to
> >>>>>>> turn
> >>>>>>>>> TomEE into an umbrella project or how the structure would be. And
> >>>>>>>>> whether/how we want to integrate the modular Geronimo parts into
> >>>> one
> >>>>>>>>> project or not.
> >>>>>>>>>
> >>>>>>>>> Parts of the components skeletons you just created do already
> >>>> exist
> >>>>> at
> >>>>>>>>> the ASF.
> >>>>>>>>>
> >>>>>>>>> LieGrue,
> >>>>>>>>> strub
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >>>>>>>>> agumbrecht@tomitribe.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Added project stubs:
> >>>>>>>>> https://github.com/apache/tomee/tree/master/microprofile
> >>>>>>>>>
> >>>>>>>>> Andy.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Ok thanks guys.
> >>>>>>>>>> @Rudy, you are most welcome :)
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >>>>>>>>> rdebusscher@gmail.com <ma...@gmail.com>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I think it is a very important spec, also for non-microprofile
> >>>>>>>>>>> implementations as it can enhance the interoperability of all
> >>>>>>> servers.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm also very interested in the implementation (and want to
> >>>> help
> >>>>> a
> >>>>>>> bit
> >>>>>>>>> with
> >>>>>>>>>>> it also :) )
> >>>>>>>>>>>
> >>>>>>>>>>> regards
> >>>>>>>>>>> Rudy
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
> >>>>> <struberg@yahoo.de.invalid
> >>>>>>>>> <ma...@yahoo.de.invalid>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> To clarify this even further:
> >>>>>>>>>>>> The Geronimo Server is now officially dead.
> >>>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a
> >>>> few
> >>>>>>>>> modular
> >>>>>>>>>>>> parts which are reused in many ASF projects and also outside.
> >>>>>>>>>>>> Examples is the geronimo-transaction-manager,
> >>>> geronimo-javamail,
> >>>>>>>>>>>> geronimo-config, xbean-finder, etc
> >>>>>>>>>>>>
> >>>>>>>>>>>> Of course it would probably make sense to fold those 2
> >>>> projects
> >>>>>>>>> together,
> >>>>>>>>>>>> as already discussed in the past.
> >>>>>>>>>>>> I'm still all open to it, but I have an important criterium to
> >>>>>>> fulfil:
> >>>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
> >>>>> that
> >>>>>>>>> TomEE
> >>>>>>>>>>>> would become an 'Umbrella project'.
> >>>>>>>>>>>> And further that we would need a new name for those portable
> >>>>> parts.
> >>>>>>>>>>>> They would effectively be mainatained by the TomEE community
> >>>>> (which
> >>>>>>>>> has a
> >>>>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly
> >>>>> be
> >>>>>>>>>>>> recognized separately from TomEE.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Otherwise people will assume that those parts only work within
> >>>>>>> TomEE -
> >>>>>>>>>>>> where in reality they would even work on WildFly or Liberty,
> >>>>> etc. or
> >>>>>>>>>>> even a
> >>>>>>>>>>>> naked Tomcat.
> >>>>>>>>>>>> Got me?
> >>>>>>>>>>>>
> >>>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> >>>>> Department'
> >>>>>>> :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> LieGrue,
> >>>>>>>>>>>> strub
> >>>>>>>>>>>>
> >>>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name
> >>>>> to
> >>>>>>> ease
> >>>>>>>>>>>> backward compatibility.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>>>>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Guys, I have a question:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Why not a project to each implementation?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> This way I can use just a specific if I want also.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> long story short: we learnt from the past errors and since
> >>>>> always
> >>>>>>> the
> >>>>>>>>>>>> same
> >>>>>>>>>>>>> people work on these projects it is better to not split it
> >>>>> accross
> >>>>>>> N
> >>>>>>>>>>>>> communities since
> >>>>>>>>>>>>> it leads to a lot of efforts for these people. Having a
> >>>> single
> >>>>>>>>> umbrella
> >>>>>>>>>>>>> project with N subprojects reduces the administrative work
> >>>> etc
> >>>>> and
> >>>>>>>>>>>> enhance
> >>>>>>>>>>>>> the projects productivity.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi JL,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
> >>>>> already
> >>>>>>>>>>> spoke
> >>>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at
> >>>> the
> >>>>> same
> >>>>>>>>>>> place
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>> the foundation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>>> https://github.com/
> >>>>>>>>>>>>>>> rmannibucau> |
> >>>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>>>>>>>>>> ee-8-high-performance>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>>>>>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> >>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
> >>>>>>> implemented
> >>>>>>>>> in
> >>>>>>>>>>>>>>> TomEE.
> >>>>>>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Jean-Louis
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Andy Gumbrecht
> >>>>>>>>> https://twitter.com/AndyGeeDe
> >>>>>>>>>
> >>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>
> >>>>>>>>> https://www.tomitribe.io
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Ubique
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>> Andy Gumbrecht
> >>>>>>>> https://twitter.com/AndyGeeDe
> >>>>>>>> http://www.tomitribe.com
> >>>>>>>> https://www.tomitribe.io
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ubique
> >>
> >>
>
>

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

Might do as well. 
But the JSON-P part is really well abstracted. So this is easy to plug-in.

I'm more worried about the authorisation and authentication interface. 
Anything EE security seems way too heavyweight for me. This might work out for TomEE, but would kill it's use in any more lightweight approach.
So probably introduce an own pluggable SPI for authentication and authorisation?
Then it really could be done pretty much anywhere. Or do we have yet another 'interface area'?

LieGrue,
strub


> Am 13.02.2018 um 16:52 schrieb Jean-Louis Monteiro <jl...@tomitribe.com>:
> 
> I was also thinking about a Johnzon extension (kinda)
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
> 
>> I know JWT a bit and I wonder whether doing the signing part is just a bit
>> of Json (JSON-P) + commons-crypto?
>> After all JWT is especially designed to be lightweight and straight
>> forward.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>>> :
>>> 
>>> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com
>>> :
>>> 
>>>> Thanks for the feedback Jon.
>>>> 
>>>> I had a couple of exchanges with Rudy which is happy to contribute some
>>>> code as well.
>>>> From what I have understood and seen, most of the code is integration
>> code
>>>> and there is at least from my current knowledge a little bit of code to
>> put
>>>> together in a reusable manner in a reusable library (where ever it
>> sits).
>>>> I was planning to do a quick prototype and get it to work from end to
>> end
>>>> into a working branch so we can move the discussion forward and see
>> exactly
>>>> where we go.
>>>> 
>>>> Regarding the signing library, I am kinda on the same page.
>>>> I don't see myself rewriting Johnzon to parse JSON and then Jose or
>> Nimbus
>>>> to do signing. There is absolutely no point at least for the POC. Again,
>>>> we'll see if I get something working what we can do.
>>>> 
>>>> 
>>>> 
>>> Agreeing for a PoC but for a production ready software it is if it can
>>> conflict or bring drawbacks to the users to import the solution. The json
>>> lib should at least be pluggable - avoids to shade/rewrite anything but
>> let
>>> the integrator use what he already has. Side note for json: for the
>> overall
>>> consistency using JSON-P makes it easy to get a common API which doesn't
>>> need any investment and solves that "plug your impl" smoothly. For the
>>> signing part it is a bit different since it will easily bring a huge
>> stack
>>> - how many bring jackson, simple-json, ... by default and are not
>>> pluggable. This is an issue and can even lead to not working
>> installations.
>>> If you doubt I have like 700 components to show you it is not a random or
>>> theorical thought. Investment is also quite light so not sure it does
>> worth
>>> speaking about it days.
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>> 
>>>> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <jo...@apache.org>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 2018/02/12 20:42:58, Jonathan Gallimore <
>> jonathan.gallimore@gmail.com
>>>>> 
>>>>> wrote:
>>>>>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> No Andy, as mentionned in the discussion Geronimo hosts the
>>>>> microprofile
>>>>>>> @asf. This is why jwt should probably be done in geronimo which is
>>>> the
>>>>> asf
>>>>>>> ee related project umbrella.
>>>>>>> 
>>>>>> 
>>>>>> I don't recall that discussion. Where did it take place?
>>>>> 
>>>>> I *think* he meant me.  The only time JWT came up on Geronimo was at
>> [1].
>>>>> I had mentioned bringing over an impl based on Jose4J, Romain felt very
>>>>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
>>>> is,
>>>>> but it seemed based on the discussion we had two different aims so it
>>>>> wasn't something I pushed forward on.  If there's interest within TomEE
>>>> to
>>>>> get a JWT impl up and running, I'd be happy to help (though I do feel
>>>>> strongly relying on a 3rd party lib for the actual signature
>> validation +
>>>>> external sig support is important; to avoid that overhead).
>>>>> 
>>>>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
>>>>> about what projects are allowed to host.  For example, there's interest
>>>>> within Skywalking to host the CDI and JAX-RS extensions to support
>>>> OpenApi;
>>>>> but this spec doesn't represent something any server vendor would
>> support
>>>>> since its really about your APM solution.  CXF happily took on the MP
>>>> Rest
>>>>> Client when I proposed it; though I would hope TomEE relies on the CXF
>>>>> library instead of crafting their own client (selfish desires).  The
>> JWT
>>>>> spec is weird, because it defined non MP runtime behavior in addition
>> to
>>>> MP
>>>>> runtime behavior; so there may be more integration work in a fuller app
>>>>> server like TomEE.
>>>>> 
>>>>> </peanut-gallery>
>>>>> 
>>>>> John
>>>>> 
>>>>> [1]: https://lists.apache.org/thread.html/
>> 4edc997cfe2e45aaf25bb118bc6216
>>>>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> I understand it is not the most convenient for tomitribe which
>>>> probably
>>>>>>> perfers to own the full project(s) but as a foundation member I d
>>>>> really
>>>>>>> like to not let company details pollute projects
>>>>>> 
>>>>>> 
>>>>>>> Also the discussion made clear to not do it in current repo whatever
>>>>>>> project is used as umbrella so we should revert that and finish the
>>>>>>> discussion before any action to not kill tomee project by a hard
>>>>> company
>>>>>>> driven management making it no more in the OSS spirit.
>>>>>>> 
>>>>>> 
>>>>>> I agree the discussion should happen first, and I note that the change
>>>>> has
>>>>>> been reverted. I recall that we agreed on this list that we'd create
>>>> new
>>>>>> git projects for Sheldon and Chatterbox under the TomEE umbrella.
>>>> Should
>>>>>> other components sit under TomEE, I imagine that they would follow the
>>>>> same
>>>>>> pattern - i.e. discuss first, agree location, create repo or move
>>>> things
>>>>>> around as appropriate.
>>>>>> 
>>>>>> I don't know what your specific issues are here, but I think you are
>>>>> making
>>>>>> some assumptions that are simply not true.
>>>>>> 
>>>>>> Jon
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com>
>>>> a
>>>>>>> écrit :
>>>>>>> 
>>>>>>>> "Parts of the components skeletons you just created"
>>>>>>>> 
>>>>>>>> They're just logically named empty modules for pending work?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 12/02/18 20:42, Mark Struberg wrote:
>>>>>>>> 
>>>>>>>>> And what's that for?
>>>>>>>>> 
>>>>>>>>> Is there any behind the scene stuff going on at Tomitribe or can
>>>> we
>>>>>>>>> finally get back to discussing such things on the Apache lists?
>>>>>>>>> 
>>>>>>>>> Before we go on I'd would first finish the discussion how we want
>>>> to
>>>>>>> turn
>>>>>>>>> TomEE into an umbrella project or how the structure would be. And
>>>>>>>>> whether/how we want to integrate the modular Geronimo parts into
>>>> one
>>>>>>>>> project or not.
>>>>>>>>> 
>>>>>>>>> Parts of the components skeletons you just created do already
>>>> exist
>>>>> at
>>>>>>>>> the ASF.
>>>>>>>>> 
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>>>>>>>>> agumbrecht@tomitribe.com> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Added project stubs:
>>>>>>>>> https://github.com/apache/tomee/tree/master/microprofile
>>>>>>>>> 
>>>>>>>>> Andy.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Ok thanks guys.
>>>>>>>>>> @Rudy, you are most welcome :)
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>>>>>>>> rdebusscher@gmail.com <ma...@gmail.com>>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I think it is a very important spec, also for non-microprofile
>>>>>>>>>>> implementations as it can enhance the interoperability of all
>>>>>>> servers.
>>>>>>>>>>> 
>>>>>>>>>>> I'm also very interested in the implementation (and want to
>>>> help
>>>>> a
>>>>>>> bit
>>>>>>>>> with
>>>>>>>>>>> it also :) )
>>>>>>>>>>> 
>>>>>>>>>>> regards
>>>>>>>>>>> Rudy
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
>>>>> <struberg@yahoo.de.invalid
>>>>>>>>> <ma...@yahoo.de.invalid>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> To clarify this even further:
>>>>>>>>>>>> The Geronimo Server is now officially dead.
>>>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a
>>>> few
>>>>>>>>> modular
>>>>>>>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>>>>>>>> Examples is the geronimo-transaction-manager,
>>>> geronimo-javamail,
>>>>>>>>>>>> geronimo-config, xbean-finder, etc
>>>>>>>>>>>> 
>>>>>>>>>>>> Of course it would probably make sense to fold those 2
>>>> projects
>>>>>>>>> together,
>>>>>>>>>>>> as already discussed in the past.
>>>>>>>>>>>> I'm still all open to it, but I have an important criterium to
>>>>>>> fulfil:
>>>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
>>>>> that
>>>>>>>>> TomEE
>>>>>>>>>>>> would become an 'Umbrella project'.
>>>>>>>>>>>> And further that we would need a new name for those portable
>>>>> parts.
>>>>>>>>>>>> They would effectively be mainatained by the TomEE community
>>>>> (which
>>>>>>>>> has a
>>>>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly
>>>>> be
>>>>>>>>>>>> recognized separately from TomEE.
>>>>>>>>>>>> 
>>>>>>>>>>>> Otherwise people will assume that those parts only work within
>>>>>>> TomEE -
>>>>>>>>>>>> where in reality they would even work on WildFly or Liberty,
>>>>> etc. or
>>>>>>>>>>> even a
>>>>>>>>>>>> naked Tomcat.
>>>>>>>>>>>> Got me?
>>>>>>>>>>>> 
>>>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
>>>>> Department'
>>>>>>> :)
>>>>>>>>>>>> 
>>>>>>>>>>>> LieGrue,
>>>>>>>>>>>> strub
>>>>>>>>>>>> 
>>>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name
>>>>> to
>>>>>>> ease
>>>>>>>>>>>> backward compatibility.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>>>>>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Guys, I have a question:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Why not a project to each implementation?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> long story short: we learnt from the past errors and since
>>>>> always
>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>>> people work on these projects it is better to not split it
>>>>> accross
>>>>>>> N
>>>>>>>>>>>>> communities since
>>>>>>>>>>>>> it leads to a lot of efforts for these people. Having a
>>>> single
>>>>>>>>> umbrella
>>>>>>>>>>>>> project with N subprojects reduces the administrative work
>>>> etc
>>>>> and
>>>>>>>>>>>> enhance
>>>>>>>>>>>>> the projects productivity.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi JL,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
>>>>> already
>>>>>>>>>>> spoke
>>>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at
>>>> the
>>>>> same
>>>>>>>>>>> place
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the foundation.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/
>>>>>>>>>>>>>>> rmannibucau> |
>>>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>>>>>>>> ee-8-high-performance>
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>>>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
>>>>>>> implemented
>>>>>>>>> in
>>>>>>>>>>>>>>> TomEE.
>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Jean-Louis
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Andy Gumbrecht
>>>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>>>> 
>>>>>>>>> http://www.tomitribe.com
>>>>>>>>> 
>>>>>>>>> https://www.tomitribe.io
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Ubique
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> --
>>>>>>>> Andy Gumbrecht
>>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>>> http://www.tomitribe.com
>>>>>>>> https://www.tomitribe.io
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ubique
>> 
>> 

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro <jl...@tomitribe.com>]

I was also thinking about a Johnzon extension (kinda)

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> I know JWT a bit and I wonder whether doing the signing part is just a bit
> of Json (JSON-P) + commons-crypto?
> After all JWT is especially designed to be lightweight and straight
> forward.
>
> LieGrue,
> strub
>
>
>
> > Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com
> >:
> >
> >> Thanks for the feedback Jon.
> >>
> >> I had a couple of exchanges with Rudy which is happy to contribute some
> >> code as well.
> >> From what I have understood and seen, most of the code is integration
> code
> >> and there is at least from my current knowledge a little bit of code to
> put
> >> together in a reusable manner in a reusable library (where ever it
> sits).
> >> I was planning to do a quick prototype and get it to work from end to
> end
> >> into a working branch so we can move the discussion forward and see
> exactly
> >> where we go.
> >>
> >> Regarding the signing library, I am kinda on the same page.
> >> I don't see myself rewriting Johnzon to parse JSON and then Jose or
> Nimbus
> >> to do signing. There is absolutely no point at least for the POC. Again,
> >> we'll see if I get something working what we can do.
> >>
> >>
> >>
> > Agreeing for a PoC but for a production ready software it is if it can
> > conflict or bring drawbacks to the users to import the solution. The json
> > lib should at least be pluggable - avoids to shade/rewrite anything but
> let
> > the integrator use what he already has. Side note for json: for the
> overall
> > consistency using JSON-P makes it easy to get a common API which doesn't
> > need any investment and solves that "plug your impl" smoothly. For the
> > signing part it is a bit different since it will easily bring a huge
> stack
> > - how many bring jackson, simple-json, ... by default and are not
> > pluggable. This is an issue and can even lead to not working
> installations.
> > If you doubt I have like 700 components to show you it is not a random or
> > theorical thought. Investment is also quite light so not sure it does
> worth
> > speaking about it days.
> >
> >
> >>
> >>
> >>
> >> --
> >> Jean-Louis Monteiro
> >> http://twitter.com/jlouismonteiro
> >> http://www.tomitribe.com
> >>
> >> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <jo...@apache.org>
> >> wrote:
> >>
> >>>
> >>>
> >>> On 2018/02/12 20:42:58, Jonathan Gallimore <
> jonathan.gallimore@gmail.com
> >>>
> >>> wrote:
> >>>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> No Andy, as mentionned in the discussion Geronimo hosts the
> >>> microprofile
> >>>>> @asf. This is why jwt should probably be done in geronimo which is
> >> the
> >>> asf
> >>>>> ee related project umbrella.
> >>>>>
> >>>>
> >>>> I don't recall that discussion. Where did it take place?
> >>>
> >>> I *think* he meant me.  The only time JWT came up on Geronimo was at
> [1].
> >>> I had mentioned bringing over an impl based on Jose4J, Romain felt very
> >>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
> >> is,
> >>> but it seemed based on the discussion we had two different aims so it
> >>> wasn't something I pushed forward on.  If there's interest within TomEE
> >> to
> >>> get a JWT impl up and running, I'd be happy to help (though I do feel
> >>> strongly relying on a 3rd party lib for the actual signature
> validation +
> >>> external sig support is important; to avoid that overhead).
> >>>
> >>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> >>> about what projects are allowed to host.  For example, there's interest
> >>> within Skywalking to host the CDI and JAX-RS extensions to support
> >> OpenApi;
> >>> but this spec doesn't represent something any server vendor would
> support
> >>> since its really about your APM solution.  CXF happily took on the MP
> >> Rest
> >>> Client when I proposed it; though I would hope TomEE relies on the CXF
> >>> library instead of crafting their own client (selfish desires).  The
> JWT
> >>> spec is weird, because it defined non MP runtime behavior in addition
> to
> >> MP
> >>> runtime behavior; so there may be more integration work in a fuller app
> >>> server like TomEE.
> >>>
> >>> </peanut-gallery>
> >>>
> >>> John
> >>>
> >>> [1]: https://lists.apache.org/thread.html/
> 4edc997cfe2e45aaf25bb118bc6216
> >>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>> I understand it is not the most convenient for tomitribe which
> >> probably
> >>>>> perfers to own the full project(s) but as a foundation member I d
> >>> really
> >>>>> like to not let company details pollute projects
> >>>>
> >>>>
> >>>>> Also the discussion made clear to not do it in current repo whatever
> >>>>> project is used as umbrella so we should revert that and finish the
> >>>>> discussion before any action to not kill tomee project by a hard
> >>> company
> >>>>> driven management making it no more in the OSS spirit.
> >>>>>
> >>>>
> >>>> I agree the discussion should happen first, and I note that the change
> >>> has
> >>>> been reverted. I recall that we agreed on this list that we'd create
> >> new
> >>>> git projects for Sheldon and Chatterbox under the TomEE umbrella.
> >> Should
> >>>> other components sit under TomEE, I imagine that they would follow the
> >>> same
> >>>> pattern - i.e. discuss first, agree location, create repo or move
> >> things
> >>>> around as appropriate.
> >>>>
> >>>> I don't know what your specific issues are here, but I think you are
> >>> making
> >>>> some assumptions that are simply not true.
> >>>>
> >>>> Jon
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com>
> >> a
> >>>>> écrit :
> >>>>>
> >>>>>> "Parts of the components skeletons you just created"
> >>>>>>
> >>>>>> They're just logically named empty modules for pending work?
> >>>>>>
> >>>>>>
> >>>>>> On 12/02/18 20:42, Mark Struberg wrote:
> >>>>>>
> >>>>>>> And what's that for?
> >>>>>>>
> >>>>>>> Is there any behind the scene stuff going on at Tomitribe or can
> >> we
> >>>>>>> finally get back to discussing such things on the Apache lists?
> >>>>>>>
> >>>>>>> Before we go on I'd would first finish the discussion how we want
> >> to
> >>>>> turn
> >>>>>>> TomEE into an umbrella project or how the structure would be. And
> >>>>>>> whether/how we want to integrate the modular Geronimo parts into
> >> one
> >>>>>>> project or not.
> >>>>>>>
> >>>>>>> Parts of the components skeletons you just created do already
> >> exist
> >>> at
> >>>>>>> the ASF.
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >>>>>>> agumbrecht@tomitribe.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Added project stubs:
> >>>>>>> https://github.com/apache/tomee/tree/master/microprofile
> >>>>>>>
> >>>>>>> Andy.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Ok thanks guys.
> >>>>>>>> @Rudy, you are most welcome :)
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Louis Monteiro
> >>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>> http://www.tomitribe.com
> >>>>>>>>
> >>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >>>>>>> rdebusscher@gmail.com <ma...@gmail.com>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I think it is a very important spec, also for non-microprofile
> >>>>>>>>> implementations as it can enhance the interoperability of all
> >>>>> servers.
> >>>>>>>>>
> >>>>>>>>> I'm also very interested in the implementation (and want to
> >> help
> >>> a
> >>>>> bit
> >>>>>>> with
> >>>>>>>>> it also :) )
> >>>>>>>>>
> >>>>>>>>> regards
> >>>>>>>>> Rudy
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
> >>> <struberg@yahoo.de.invalid
> >>>>>>> <ma...@yahoo.de.invalid>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> To clarify this even further:
> >>>>>>>>>> The Geronimo Server is now officially dead.
> >>>>>>>>>> But the Geronimo project is not. It alredy contains quite a
> >> few
> >>>>>>> modular
> >>>>>>>>>> parts which are reused in many ASF projects and also outside.
> >>>>>>>>>> Examples is the geronimo-transaction-manager,
> >> geronimo-javamail,
> >>>>>>>>>> geronimo-config, xbean-finder, etc
> >>>>>>>>>>
> >>>>>>>>>> Of course it would probably make sense to fold those 2
> >> projects
> >>>>>>> together,
> >>>>>>>>>> as already discussed in the past.
> >>>>>>>>>> I'm still all open to it, but I have an important criterium to
> >>>>> fulfil:
> >>>>>>>>>> If we move those portable parts to TomEE, then this would mean
> >>> that
> >>>>>>> TomEE
> >>>>>>>>>> would become an 'Umbrella project'.
> >>>>>>>>>> And further that we would need a new name for those portable
> >>> parts.
> >>>>>>>>>> They would effectively be mainatained by the TomEE community
> >>> (which
> >>>>>>> has a
> >>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly
> >>> be
> >>>>>>>>>> recognized separately from TomEE.
> >>>>>>>>>>
> >>>>>>>>>> Otherwise people will assume that those parts only work within
> >>>>> TomEE -
> >>>>>>>>>> where in reality they would even work on WildFly or Liberty,
> >>> etc. or
> >>>>>>>>> even a
> >>>>>>>>>> naked Tomcat.
> >>>>>>>>>> Got me?
> >>>>>>>>>>
> >>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> >>> Department'
> >>>>> :)
> >>>>>>>>>>
> >>>>>>>>>> LieGrue,
> >>>>>>>>>> strub
> >>>>>>>>>>
> >>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name
> >>> to
> >>>>> ease
> >>>>>>>>>> backward compatibility.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>>>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> >>>>>>>>>>>
> >>>>>>>>>>>> Guys, I have a question:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why not a project to each implementation?
> >>>>>>>>>>>>
> >>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> This way I can use just a specific if I want also.
> >>>>>>>>>>>>
> >>>>>>>>>>> exactly the goal and user usage AFAIK ;)
> >>>>>>>>>>>
> >>>>>>>>>>> long story short: we learnt from the past errors and since
> >>> always
> >>>>> the
> >>>>>>>>>> same
> >>>>>>>>>>> people work on these projects it is better to not split it
> >>> accross
> >>>>> N
> >>>>>>>>>>> communities since
> >>>>>>>>>>> it leads to a lot of efforts for these people. Having a
> >> single
> >>>>>>> umbrella
> >>>>>>>>>>> project with N subprojects reduces the administrative work
> >> etc
> >>> and
> >>>>>>>>>> enhance
> >>>>>>>>>>> the projects productivity.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi JL,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
> >>> already
> >>>>>>>>> spoke
> >>>>>>>>>>>>> about it I think. Would probably saner to keep it all at
> >> the
> >>> same
> >>>>>>>>> place
> >>>>>>>>>>>> for
> >>>>>>>>>>>>> the foundation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>> https://github.com/
> >>>>>>>>>>>>> rmannibucau> |
> >>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>>>>>>>>> ee-8-high-performance>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>>>>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> >>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
> >>>>> implemented
> >>>>>>> in
> >>>>>>>>>>>>> TomEE.
> >>>>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jean-Louis
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Jean-Louis Monteiro
> >>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>>>>>>>>> http://www.tomitribe.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Andy Gumbrecht
> >>>>>>> https://twitter.com/AndyGeeDe
> >>>>>>>
> >>>>>>> http://www.tomitribe.com
> >>>>>>>
> >>>>>>> https://www.tomitribe.io
> >>>>>>>
> >>>>>>>
> >>>>>>> Ubique
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Andy Gumbrecht
> >>>>>> https://twitter.com/AndyGeeDe
> >>>>>> http://www.tomitribe.com
> >>>>>> https://www.tomitribe.io
> >>>>>>
> >>>>>>
> >>>>>> Ubique
>
>

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

I know JWT a bit and I wonder whether doing the signing part is just a bit of Json (JSON-P) + commons-crypto?
After all JWT is especially designed to be lightweight and straight forward.

LieGrue,
strub



> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
> 
>> Thanks for the feedback Jon.
>> 
>> I had a couple of exchanges with Rudy which is happy to contribute some
>> code as well.
>> From what I have understood and seen, most of the code is integration code
>> and there is at least from my current knowledge a little bit of code to put
>> together in a reusable manner in a reusable library (where ever it sits).
>> I was planning to do a quick prototype and get it to work from end to end
>> into a working branch so we can move the discussion forward and see exactly
>> where we go.
>> 
>> Regarding the signing library, I am kinda on the same page.
>> I don't see myself rewriting Johnzon to parse JSON and then Jose or Nimbus
>> to do signing. There is absolutely no point at least for the POC. Again,
>> we'll see if I get something working what we can do.
>> 
>> 
>> 
> Agreeing for a PoC but for a production ready software it is if it can
> conflict or bring drawbacks to the users to import the solution. The json
> lib should at least be pluggable - avoids to shade/rewrite anything but let
> the integrator use what he already has. Side note for json: for the overall
> consistency using JSON-P makes it easy to get a common API which doesn't
> need any investment and solves that "plug your impl" smoothly. For the
> signing part it is a bit different since it will easily bring a huge stack
> - how many bring jackson, simple-json, ... by default and are not
> pluggable. This is an issue and can even lead to not working installations.
> If you doubt I have like 700 components to show you it is not a random or
> theorical thought. Investment is also quite light so not sure it does worth
> speaking about it days.
> 
> 
>> 
>> 
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 
>> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <jo...@apache.org>
>> wrote:
>> 
>>> 
>>> 
>>> On 2018/02/12 20:42:58, Jonathan Gallimore <jonathan.gallimore@gmail.com
>>> 
>>> wrote:
>>>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>> wrote:
>>>> 
>>>>> No Andy, as mentionned in the discussion Geronimo hosts the
>>> microprofile
>>>>> @asf. This is why jwt should probably be done in geronimo which is
>> the
>>> asf
>>>>> ee related project umbrella.
>>>>> 
>>>> 
>>>> I don't recall that discussion. Where did it take place?
>>> 
>>> I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
>>> I had mentioned bringing over an impl based on Jose4J, Romain felt very
>>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
>> is,
>>> but it seemed based on the discussion we had two different aims so it
>>> wasn't something I pushed forward on.  If there's interest within TomEE
>> to
>>> get a JWT impl up and running, I'd be happy to help (though I do feel
>>> strongly relying on a 3rd party lib for the actual signature validation +
>>> external sig support is important; to avoid that overhead).
>>> 
>>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
>>> about what projects are allowed to host.  For example, there's interest
>>> within Skywalking to host the CDI and JAX-RS extensions to support
>> OpenApi;
>>> but this spec doesn't represent something any server vendor would support
>>> since its really about your APM solution.  CXF happily took on the MP
>> Rest
>>> Client when I proposed it; though I would hope TomEE relies on the CXF
>>> library instead of crafting their own client (selfish desires).  The JWT
>>> spec is weird, because it defined non MP runtime behavior in addition to
>> MP
>>> runtime behavior; so there may be more integration work in a fuller app
>>> server like TomEE.
>>> 
>>> </peanut-gallery>
>>> 
>>> John
>>> 
>>> [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
>>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>>> 
>>>> 
>>>> 
>>>>> 
>>>>> I understand it is not the most convenient for tomitribe which
>> probably
>>>>> perfers to own the full project(s) but as a foundation member I d
>>> really
>>>>> like to not let company details pollute projects
>>>> 
>>>> 
>>>>> Also the discussion made clear to not do it in current repo whatever
>>>>> project is used as umbrella so we should revert that and finish the
>>>>> discussion before any action to not kill tomee project by a hard
>>> company
>>>>> driven management making it no more in the OSS spirit.
>>>>> 
>>>> 
>>>> I agree the discussion should happen first, and I note that the change
>>> has
>>>> been reverted. I recall that we agreed on this list that we'd create
>> new
>>>> git projects for Sheldon and Chatterbox under the TomEE umbrella.
>> Should
>>>> other components sit under TomEE, I imagine that they would follow the
>>> same
>>>> pattern - i.e. discuss first, agree location, create repo or move
>> things
>>>> around as appropriate.
>>>> 
>>>> I don't know what your specific issues are here, but I think you are
>>> making
>>>> some assumptions that are simply not true.
>>>> 
>>>> Jon
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com>
>> a
>>>>> écrit :
>>>>> 
>>>>>> "Parts of the components skeletons you just created"
>>>>>> 
>>>>>> They're just logically named empty modules for pending work?
>>>>>> 
>>>>>> 
>>>>>> On 12/02/18 20:42, Mark Struberg wrote:
>>>>>> 
>>>>>>> And what's that for?
>>>>>>> 
>>>>>>> Is there any behind the scene stuff going on at Tomitribe or can
>> we
>>>>>>> finally get back to discussing such things on the Apache lists?
>>>>>>> 
>>>>>>> Before we go on I'd would first finish the discussion how we want
>> to
>>>>> turn
>>>>>>> TomEE into an umbrella project or how the structure would be. And
>>>>>>> whether/how we want to integrate the modular Geronimo parts into
>> one
>>>>>>> project or not.
>>>>>>> 
>>>>>>> Parts of the components skeletons you just created do already
>> exist
>>> at
>>>>>>> the ASF.
>>>>>>> 
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>>>>>>> agumbrecht@tomitribe.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Added project stubs:
>>>>>>> https://github.com/apache/tomee/tree/master/microprofile
>>>>>>> 
>>>>>>> Andy.
>>>>>>> 
>>>>>>> 
>>>>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Ok thanks guys.
>>>>>>>> @Rudy, you are most welcome :)
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Jean-Louis Monteiro
>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>> http://www.tomitribe.com
>>>>>>>> 
>>>>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>>>>>> rdebusscher@gmail.com <ma...@gmail.com>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I think it is a very important spec, also for non-microprofile
>>>>>>>>> implementations as it can enhance the interoperability of all
>>>>> servers.
>>>>>>>>> 
>>>>>>>>> I'm also very interested in the implementation (and want to
>> help
>>> a
>>>>> bit
>>>>>>> with
>>>>>>>>> it also :) )
>>>>>>>>> 
>>>>>>>>> regards
>>>>>>>>> Rudy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2 February 2018 at 11:23, Mark Struberg
>>> <struberg@yahoo.de.invalid
>>>>>>> <ma...@yahoo.de.invalid>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> To clarify this even further:
>>>>>>>>>> The Geronimo Server is now officially dead.
>>>>>>>>>> But the Geronimo project is not. It alredy contains quite a
>> few
>>>>>>> modular
>>>>>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>>>>>> Examples is the geronimo-transaction-manager,
>> geronimo-javamail,
>>>>>>>>>> geronimo-config, xbean-finder, etc
>>>>>>>>>> 
>>>>>>>>>> Of course it would probably make sense to fold those 2
>> projects
>>>>>>> together,
>>>>>>>>>> as already discussed in the past.
>>>>>>>>>> I'm still all open to it, but I have an important criterium to
>>>>> fulfil:
>>>>>>>>>> If we move those portable parts to TomEE, then this would mean
>>> that
>>>>>>> TomEE
>>>>>>>>>> would become an 'Umbrella project'.
>>>>>>>>>> And further that we would need a new name for those portable
>>> parts.
>>>>>>>>>> They would effectively be mainatained by the TomEE community
>>> (which
>>>>>>> has a
>>>>>>>>>> big overlap with Geronimo anyway) but those parts must clearly
>>> be
>>>>>>>>>> recognized separately from TomEE.
>>>>>>>>>> 
>>>>>>>>>> Otherwise people will assume that those parts only work within
>>>>> TomEE -
>>>>>>>>>> where in reality they would even work on WildFly or Liberty,
>>> etc. or
>>>>>>>>> even a
>>>>>>>>>> naked Tomcat.
>>>>>>>>>> Got me?
>>>>>>>>>> 
>>>>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
>>> Department'
>>>>> :)
>>>>>>>>>> 
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>> 
>>>>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name
>>> to
>>>>> ease
>>>>>>>>>> backward compatibility.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>>>>>> :
>>>>>>>>>>> 
>>>>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>>>>>>>>>>> 
>>>>>>>>>>>> Guys, I have a question:
>>>>>>>>>>>> 
>>>>>>>>>>>> Why not a project to each implementation?
>>>>>>>>>>>> 
>>>>>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>>>>> 
>>>>>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>>>>> 
>>>>>>>>>>> long story short: we learnt from the past errors and since
>>> always
>>>>> the
>>>>>>>>>> same
>>>>>>>>>>> people work on these projects it is better to not split it
>>> accross
>>>>> N
>>>>>>>>>>> communities since
>>>>>>>>>>> it leads to a lot of efforts for these people. Having a
>> single
>>>>>>> umbrella
>>>>>>>>>>> project with N subprojects reduces the administrative work
>> etc
>>> and
>>>>>>>>>> enhance
>>>>>>>>>>> the projects productivity.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi JL,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John
>>> already
>>>>>>>>> spoke
>>>>>>>>>>>>> about it I think. Would probably saner to keep it all at
>> the
>>> same
>>>>>>>>> place
>>>>>>>>>>>> for
>>>>>>>>>>>>> the foundation.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/
>>>>>>>>>>>>> rmannibucau> |
>>>>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>>>>>> ee-8-high-performance>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>>>>>>>>>>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I was wondering if we could have the Microprofile JWT
>>>>> implemented
>>>>>>> in
>>>>>>>>>>>>> TomEE.
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Jean-Louis
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Andy Gumbrecht
>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>> 
>>>>>>> http://www.tomitribe.com
>>>>>>> 
>>>>>>> https://www.tomitribe.io
>>>>>>> 
>>>>>>> 
>>>>>>> Ubique
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> --
>>>>>> Andy Gumbrecht
>>>>>> https://twitter.com/AndyGeeDe
>>>>>> http://www.tomitribe.com
>>>>>> https://www.tomitribe.io
>>>>>> 
>>>>>> 
>>>>>> Ubique

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <jl...@tomitribe.com>:

> Thanks for the feedback Jon.
>
> I had a couple of exchanges with Rudy which is happy to contribute some
> code as well.
> From what I have understood and seen, most of the code is integration code
> and there is at least from my current knowledge a little bit of code to put
> together in a reusable manner in a reusable library (where ever it sits).
> I was planning to do a quick prototype and get it to work from end to end
> into a working branch so we can move the discussion forward and see exactly
> where we go.
>
> Regarding the signing library, I am kinda on the same page.
> I don't see myself rewriting Johnzon to parse JSON and then Jose or Nimbus
> to do signing. There is absolutely no point at least for the POC. Again,
> we'll see if I get something working what we can do.
>
>
>
Agreeing for a PoC but for a production ready software it is if it can
conflict or bring drawbacks to the users to import the solution. The json
lib should at least be pluggable - avoids to shade/rewrite anything but let
the integrator use what he already has. Side note for json: for the overall
consistency using JSON-P makes it easy to get a common API which doesn't
need any investment and solves that "plug your impl" smoothly. For the
signing part it is a bit different since it will easily bring a huge stack
- how many bring jackson, simple-json, ... by default and are not
pluggable. This is an issue and can even lead to not working installations.
If you doubt I have like 700 components to show you it is not a random or
theorical thought. Investment is also quite light so not sure it does worth
speaking about it days.


>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <jo...@apache.org>
> wrote:
>
> >
> >
> > On 2018/02/12 20:42:58, Jonathan Gallimore <jonathan.gallimore@gmail.com
> >
> > wrote:
> > > On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > No Andy, as mentionned in the discussion Geronimo hosts the
> > microprofile
> > > > @asf. This is why jwt should probably be done in geronimo which is
> the
> > asf
> > > > ee related project umbrella.
> > > >
> > >
> > > I don't recall that discussion. Where did it take place?
> >
> > I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
> > I had mentioned bringing over an impl based on Jose4J, Romain felt very
> > strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
> is,
> > but it seemed based on the discussion we had two different aims so it
> > wasn't something I pushed forward on.  If there's interest within TomEE
> to
> > get a JWT impl up and running, I'd be happy to help (though I do feel
> > strongly relying on a 3rd party lib for the actual signature validation +
> > external sig support is important; to avoid that overhead).
> >
> > RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> > about what projects are allowed to host.  For example, there's interest
> > within Skywalking to host the CDI and JAX-RS extensions to support
> OpenApi;
> > but this spec doesn't represent something any server vendor would support
> > since its really about your APM solution.  CXF happily took on the MP
> Rest
> > Client when I proposed it; though I would hope TomEE relies on the CXF
> > library instead of crafting their own client (selfish desires).  The JWT
> > spec is weird, because it defined non MP runtime behavior in addition to
> MP
> > runtime behavior; so there may be more integration work in a fuller app
> > server like TomEE.
> >
> > </peanut-gallery>
> >
> > John
> >
> > [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
> > 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >
> > >
> > >
> > > >
> > > > I understand it is not the most convenient for tomitribe which
> probably
> > > > perfers to own the full project(s) but as a foundation member I d
> > really
> > > > like to not let company details pollute projects
> > >
> > >
> > > > Also the discussion made clear to not do it in current repo whatever
> > > > project is used as umbrella so we should revert that and finish the
> > > > discussion before any action to not kill tomee project by a hard
> > company
> > > > driven management making it no more in the OSS spirit.
> > > >
> > >
> > > I agree the discussion should happen first, and I note that the change
> > has
> > > been reverted. I recall that we agreed on this list that we'd create
> new
> > > git projects for Sheldon and Chatterbox under the TomEE umbrella.
> Should
> > > other components sit under TomEE, I imagine that they would follow the
> > same
> > > pattern - i.e. discuss first, agree location, create repo or move
> things
> > > around as appropriate.
> > >
> > > I don't know what your specific issues are here, but I think you are
> > making
> > > some assumptions that are simply not true.
> > >
> > > Jon
> > >
> > >
> > >
> > > >
> > > > Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com>
> a
> > > > écrit :
> > > >
> > > > > "Parts of the components skeletons you just created"
> > > > >
> > > > > They're just logically named empty modules for pending work?
> > > > >
> > > > >
> > > > > On 12/02/18 20:42, Mark Struberg wrote:
> > > > >
> > > > >> And what's that for?
> > > > >>
> > > > >> Is there any behind the scene stuff going on at Tomitribe or can
> we
> > > > >> finally get back to discussing such things on the Apache lists?
> > > > >>
> > > > >> Before we go on I'd would first finish the discussion how we want
> to
> > > > turn
> > > > >> TomEE into an umbrella project or how the structure would be. And
> > > > >> whether/how we want to integrate the modular Geronimo parts into
> one
> > > > >> project or not.
> > > > >>
> > > > >> Parts of the components skeletons you just created do already
> exist
> > at
> > > > >> the ASF.
> > > > >>
> > > > >> LieGrue,
> > > > >> strub
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > > > >> agumbrecht@tomitribe.com> wrote:
> > > > >>
> > > > >>
> > > > >> Added project stubs:
> > > > >> https://github.com/apache/tomee/tree/master/microprofile
> > > > >>
> > > > >> Andy.
> > > > >>
> > > > >>
> > > > >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> > > > >> > Hi,
> > > > >> >
> > > > >> > Ok thanks guys.
> > > > >> > @Rudy, you are most welcome :)
> > > > >> >
> > > > >> > --
> > > > >> > Jean-Louis Monteiro
> > > > >> > http://twitter.com/jlouismonteiro
> > > > >> > http://www.tomitribe.com
> > > > >> >
> > > > >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> > > > >> rdebusscher@gmail.com <ma...@gmail.com>>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> I think it is a very important spec, also for non-microprofile
> > > > >> >> implementations as it can enhance the interoperability of all
> > > > servers.
> > > > >> >>
> > > > >> >> I'm also very interested in the implementation (and want to
> help
> > a
> > > > bit
> > > > >> with
> > > > >> >> it also :) )
> > > > >> >>
> > > > >> >> regards
> > > > >> >> Rudy
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On 2 February 2018 at 11:23, Mark Struberg
> > <struberg@yahoo.de.invalid
> > > > >> <ma...@yahoo.de.invalid>>
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >>> To clarify this even further:
> > > > >> >>> The Geronimo Server is now officially dead.
> > > > >> >>> But the Geronimo project is not. It alredy contains quite a
> few
> > > > >> modular
> > > > >> >>> parts which are reused in many ASF projects and also outside.
> > > > >> >>> Examples is the geronimo-transaction-manager,
> geronimo-javamail,
> > > > >> >>> geronimo-config, xbean-finder, etc
> > > > >> >>>
> > > > >> >>> Of course it would probably make sense to fold those 2
> projects
> > > > >> together,
> > > > >> >>> as already discussed in the past.
> > > > >> >>> I'm still all open to it, but I have an important criterium to
> > > > fulfil:
> > > > >> >>> If we move those portable parts to TomEE, then this would mean
> > that
> > > > >> TomEE
> > > > >> >>> would become an 'Umbrella project'.
> > > > >> >>> And further that we would need a new name for those portable
> > parts.
> > > > >> >>> They would effectively be mainatained by the TomEE community
> > (which
> > > > >> has a
> > > > >> >>> big overlap with Geronimo anyway) but those parts must clearly
> > be
> > > > >> >>> recognized separately from TomEE.
> > > > >> >>>
> > > > >> >>> Otherwise people will assume that those parts only work within
> > > > TomEE -
> > > > >> >>> where in reality they would even work on WildFly or Liberty,
> > etc. or
> > > > >> >> even a
> > > > >> >>> naked Tomcat.
> > > > >> >>> Got me?
> > > > >> >>>
> > > > >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> > Department'
> > > > :)
> > > > >> >>>
> > > > >> >>> LieGrue,
> > > > >> >>> strub
> > > > >> >>>
> > > > >> >>> PS: I'd also love to keep the org.apache.geronimo package name
> > to
> > > > ease
> > > > >> >>> backward compatibility.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> > > > >> >> rmannibucau@gmail.com <ma...@gmail.com>
> > > > >> >>>> :
> > > > >> >>>>
> > > > >> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > > > >> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> > > > >> >>>>
> > > > >> >>>>> Guys, I have a question:
> > > > >> >>>>>
> > > > >> >>>>> Why not a project to each implementation?
> > > > >> >>>>>
> > > > >> >>>> this is the case but geronimo is used as an umbrella project.
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>> This way I can use just a specific if I want also.
> > > > >> >>>>>
> > > > >> >>>> exactly the goal and user usage AFAIK ;)
> > > > >> >>>>
> > > > >> >>>> long story short: we learnt from the past errors and since
> > always
> > > > the
> > > > >> >>> same
> > > > >> >>>> people work on these projects it is better to not split it
> > accross
> > > > N
> > > > >> >>>> communities since
> > > > >> >>>> it leads to a lot of efforts for these people. Having a
> single
> > > > >> umbrella
> > > > >> >>>> project with N subprojects reduces the administrative work
> etc
> > and
> > > > >> >>> enhance
> > > > >> >>>> the projects productivity.
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> > > > >> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> > > > >> >>>>> wrote:
> > > > >> >>>>>
> > > > >> >>>>>> Hi JL,
> > > > >> >>>>>>
> > > > >> >>>>>> Microprofile apache effort is hosted in geronimo and John
> > already
> > > > >> >> spoke
> > > > >> >>>>>> about it I think. Would probably saner to keep it all at
> the
> > same
> > > > >> >> place
> > > > >> >>>>> for
> > > > >> >>>>>> the foundation.
> > > > >> >>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>> Romain Manni-Bucau
> > > > >> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > >> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > > >> >>>>>> <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/
> > > > >> >>>>>> rmannibucau> |
> > > > >> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > >> >>>>>> <https://www.packtpub.com/application-development/java-
> > > > >> >>>>>> ee-8-high-performance>
> > > > >> >>>>>>
> > > > >> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> > > > >> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> > > > >> >>>>>> :
> > > > >> >>>>>>
> > > > >> >>>>>>> Hi all,
> > > > >> >>>>>>>
> > > > >> >>>>>>> I was wondering if we could have the Microprofile JWT
> > > > implemented
> > > > >> in
> > > > >> >>>>>> TomEE.
> > > > >> >>>>>>> What do you think?
> > > > >> >>>>>>>
> > > > >> >>>>>>> I was reading the spec and I'd like to contribute that in.
> > > > >> >>>>>>>
> > > > >> >>>>>>> Jean-Louis
> > > > >> >>>>>>>
> > > > >> >>>>>>> --
> > > > >> >>>>>>> Jean-Louis Monteiro
> > > > >> >>>>>>> http://twitter.com/jlouismonteiro
> > > > >> >>>>>>> http://www.tomitribe.com
> > > > >> >>>>>>>
> > > > >> >>>
> > > > >>
> > > > >> --
> > > > >> Andy Gumbrecht
> > > > >> https://twitter.com/AndyGeeDe
> > > > >>
> > > > >> http://www.tomitribe.com
> > > > >>
> > > > >> https://www.tomitribe.io
> > > > >>
> > > > >>
> > > > >> Ubique
> > > > >>
> > > > >>
> > > > >>
> > > > > --
> > > > > Andy Gumbrecht
> > > > > https://twitter.com/AndyGeeDe
> > > > > http://www.tomitribe.com
> > > > > https://www.tomitribe.io
> > > > >
> > > > >
> > > > > Ubique
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Thanks for the feedback Jon.

I had a couple of exchanges with Rudy which is happy to contribute some
code as well.
From what I have understood and seen, most of the code is integration code
and there is at least from my current knowledge a little bit of code to put
together in a reusable manner in a reusable library (where ever it sits).
I was planning to do a quick prototype and get it to work from end to end
into a working branch so we can move the discussion forward and see exactly
where we go.

Regarding the signing library, I am kinda on the same page.
I don't see myself rewriting Johnzon to parse JSON and then Jose or Nimbus
to do signing. There is absolutely no point at least for the POC. Again,
we'll see if I get something working what we can do.





--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <jo...@apache.org>
wrote:

>
>
> On 2018/02/12 20:42:58, Jonathan Gallimore <jo...@gmail.com>
> wrote:
> > On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > No Andy, as mentionned in the discussion Geronimo hosts the
> microprofile
> > > @asf. This is why jwt should probably be done in geronimo which is the
> asf
> > > ee related project umbrella.
> > >
> >
> > I don't recall that discussion. Where did it take place?
>
> I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
> I had mentioned bringing over an impl based on Jose4J, Romain felt very
> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that is,
> but it seemed based on the discussion we had two different aims so it
> wasn't something I pushed forward on.  If there's interest within TomEE to
> get a JWT impl up and running, I'd be happy to help (though I do feel
> strongly relying on a 3rd party lib for the actual signature validation +
> external sig support is important; to avoid that overhead).
>
> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> about what projects are allowed to host.  For example, there's interest
> within Skywalking to host the CDI and JAX-RS extensions to support OpenApi;
> but this spec doesn't represent something any server vendor would support
> since its really about your APM solution.  CXF happily took on the MP Rest
> Client when I proposed it; though I would hope TomEE relies on the CXF
> library instead of crafting their own client (selfish desires).  The JWT
> spec is weird, because it defined non MP runtime behavior in addition to MP
> runtime behavior; so there may be more integration work in a fuller app
> server like TomEE.
>
> </peanut-gallery>
>
> John
>
> [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>
> >
> >
> > >
> > > I understand it is not the most convenient for tomitribe which probably
> > > perfers to own the full project(s) but as a foundation member I d
> really
> > > like to not let company details pollute projects
> >
> >
> > > Also the discussion made clear to not do it in current repo whatever
> > > project is used as umbrella so we should revert that and finish the
> > > discussion before any action to not kill tomee project by a hard
> company
> > > driven management making it no more in the OSS spirit.
> > >
> >
> > I agree the discussion should happen first, and I note that the change
> has
> > been reverted. I recall that we agreed on this list that we'd create new
> > git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> > other components sit under TomEE, I imagine that they would follow the
> same
> > pattern - i.e. discuss first, agree location, create repo or move things
> > around as appropriate.
> >
> > I don't know what your specific issues are here, but I think you are
> making
> > some assumptions that are simply not true.
> >
> > Jon
> >
> >
> >
> > >
> > > Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> > > écrit :
> > >
> > > > "Parts of the components skeletons you just created"
> > > >
> > > > They're just logically named empty modules for pending work?
> > > >
> > > >
> > > > On 12/02/18 20:42, Mark Struberg wrote:
> > > >
> > > >> And what's that for?
> > > >>
> > > >> Is there any behind the scene stuff going on at Tomitribe or can we
> > > >> finally get back to discussing such things on the Apache lists?
> > > >>
> > > >> Before we go on I'd would first finish the discussion how we want to
> > > turn
> > > >> TomEE into an umbrella project or how the structure would be. And
> > > >> whether/how we want to integrate the modular Geronimo parts into one
> > > >> project or not.
> > > >>
> > > >> Parts of the components skeletons you just created do already exist
> at
> > > >> the ASF.
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > > >> agumbrecht@tomitribe.com> wrote:
> > > >>
> > > >>
> > > >> Added project stubs:
> > > >> https://github.com/apache/tomee/tree/master/microprofile
> > > >>
> > > >> Andy.
> > > >>
> > > >>
> > > >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> > > >> > Hi,
> > > >> >
> > > >> > Ok thanks guys.
> > > >> > @Rudy, you are most welcome :)
> > > >> >
> > > >> > --
> > > >> > Jean-Louis Monteiro
> > > >> > http://twitter.com/jlouismonteiro
> > > >> > http://www.tomitribe.com
> > > >> >
> > > >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> > > >> rdebusscher@gmail.com <ma...@gmail.com>>
> > > >> > wrote:
> > > >> >
> > > >> >> I think it is a very important spec, also for non-microprofile
> > > >> >> implementations as it can enhance the interoperability of all
> > > servers.
> > > >> >>
> > > >> >> I'm also very interested in the implementation (and want to help
> a
> > > bit
> > > >> with
> > > >> >> it also :) )
> > > >> >>
> > > >> >> regards
> > > >> >> Rudy
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> On 2 February 2018 at 11:23, Mark Struberg
> <struberg@yahoo.de.invalid
> > > >> <ma...@yahoo.de.invalid>>
> > > >> >> wrote:
> > > >> >>
> > > >> >>> To clarify this even further:
> > > >> >>> The Geronimo Server is now officially dead.
> > > >> >>> But the Geronimo project is not. It alredy contains quite a few
> > > >> modular
> > > >> >>> parts which are reused in many ASF projects and also outside.
> > > >> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> > > >> >>> geronimo-config, xbean-finder, etc
> > > >> >>>
> > > >> >>> Of course it would probably make sense to fold those 2 projects
> > > >> together,
> > > >> >>> as already discussed in the past.
> > > >> >>> I'm still all open to it, but I have an important criterium to
> > > fulfil:
> > > >> >>> If we move those portable parts to TomEE, then this would mean
> that
> > > >> TomEE
> > > >> >>> would become an 'Umbrella project'.
> > > >> >>> And further that we would need a new name for those portable
> parts.
> > > >> >>> They would effectively be mainatained by the TomEE community
> (which
> > > >> has a
> > > >> >>> big overlap with Geronimo anyway) but those parts must clearly
> be
> > > >> >>> recognized separately from TomEE.
> > > >> >>>
> > > >> >>> Otherwise people will assume that those parts only work within
> > > TomEE -
> > > >> >>> where in reality they would even work on WildFly or Liberty,
> etc. or
> > > >> >> even a
> > > >> >>> naked Tomcat.
> > > >> >>> Got me?
> > > >> >>>
> > > >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts
> Department'
> > > :)
> > > >> >>>
> > > >> >>> LieGrue,
> > > >> >>> strub
> > > >> >>>
> > > >> >>> PS: I'd also love to keep the org.apache.geronimo package name
> to
> > > ease
> > > >> >>> backward compatibility.
> > > >> >>>
> > > >> >>>
> > > >> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> > > >> >> rmannibucau@gmail.com <ma...@gmail.com>
> > > >> >>>> :
> > > >> >>>>
> > > >> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > > >> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> > > >> >>>>
> > > >> >>>>> Guys, I have a question:
> > > >> >>>>>
> > > >> >>>>> Why not a project to each implementation?
> > > >> >>>>>
> > > >> >>>> this is the case but geronimo is used as an umbrella project.
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>> This way I can use just a specific if I want also.
> > > >> >>>>>
> > > >> >>>> exactly the goal and user usage AFAIK ;)
> > > >> >>>>
> > > >> >>>> long story short: we learnt from the past errors and since
> always
> > > the
> > > >> >>> same
> > > >> >>>> people work on these projects it is better to not split it
> accross
> > > N
> > > >> >>>> communities since
> > > >> >>>> it leads to a lot of efforts for these people. Having a single
> > > >> umbrella
> > > >> >>>> project with N subprojects reduces the administrative work etc
> and
> > > >> >>> enhance
> > > >> >>>> the projects productivity.
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> > > >> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> > > >> >>>>> wrote:
> > > >> >>>>>
> > > >> >>>>>> Hi JL,
> > > >> >>>>>>
> > > >> >>>>>> Microprofile apache effort is hosted in geronimo and John
> already
> > > >> >> spoke
> > > >> >>>>>> about it I think. Would probably saner to keep it all at the
> same
> > > >> >> place
> > > >> >>>>> for
> > > >> >>>>>> the foundation.
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>> Romain Manni-Bucau
> > > >> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > > >> >>>>>> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/
> > > >> >>>>>> rmannibucau> |
> > > >> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > >> >>>>>> <https://www.packtpub.com/application-development/java-
> > > >> >>>>>> ee-8-high-performance>
> > > >> >>>>>>
> > > >> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> > > >> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> > > >> >>>>>> :
> > > >> >>>>>>
> > > >> >>>>>>> Hi all,
> > > >> >>>>>>>
> > > >> >>>>>>> I was wondering if we could have the Microprofile JWT
> > > implemented
> > > >> in
> > > >> >>>>>> TomEE.
> > > >> >>>>>>> What do you think?
> > > >> >>>>>>>
> > > >> >>>>>>> I was reading the spec and I'd like to contribute that in.
> > > >> >>>>>>>
> > > >> >>>>>>> Jean-Louis
> > > >> >>>>>>>
> > > >> >>>>>>> --
> > > >> >>>>>>> Jean-Louis Monteiro
> > > >> >>>>>>> http://twitter.com/jlouismonteiro
> > > >> >>>>>>> http://www.tomitribe.com
> > > >> >>>>>>>
> > > >> >>>
> > > >>
> > > >> --
> > > >> Andy Gumbrecht
> > > >> https://twitter.com/AndyGeeDe
> > > >>
> > > >> http://www.tomitribe.com
> > > >>
> > > >> https://www.tomitribe.io
> > > >>
> > > >>
> > > >> Ubique
> > > >>
> > > >>
> > > >>
> > > > --
> > > > Andy Gumbrecht
> > > > https://twitter.com/AndyGeeDe
> > > > http://www.tomitribe.com
> > > > https://www.tomitribe.io
> > > >
> > > >
> > > > Ubique
> > > >
> > > >
> > >
> >
>

Re: Implementing Microprofile JWT

["John D. Ament" <jo...@apache.org>]

On 2018/02/12 20:42:58, Jonathan Gallimore <jo...@gmail.com> wrote: 
> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> 
> > No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> > @asf. This is why jwt should probably be done in geronimo which is the asf
> > ee related project umbrella.
> >
> 
> I don't recall that discussion. Where did it take place?

I *think* he meant me.  The only time JWT came up on Geronimo was at [1].  I had mentioned bringing over an impl based on Jose4J, Romain felt very strongly we mustn't rely on 3rd party libraries.  I'm not sure why that is, but it seemed based on the discussion we had two different aims so it wasn't something I pushed forward on.  If there's interest within TomEE to get a JWT impl up and running, I'd be happy to help (though I do feel strongly relying on a 3rd party lib for the actual signature validation + external sig support is important; to avoid that overhead).

RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules about what projects are allowed to host.  For example, there's interest within Skywalking to host the CDI and JAX-RS extensions to support OpenApi; but this spec doesn't represent something any server vendor would support since its really about your APM solution.  CXF happily took on the MP Rest Client when I proposed it; though I would hope TomEE relies on the CXF library instead of crafting their own client (selfish desires).  The JWT spec is weird, because it defined non MP runtime behavior in addition to MP runtime behavior; so there may be more integration work in a fuller app server like TomEE.

</peanut-gallery>

John

[1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc621634c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E

> 
> 
> >
> > I understand it is not the most convenient for tomitribe which probably
> > perfers to own the full project(s) but as a foundation member I d really
> > like to not let company details pollute projects
> 
> 
> > Also the discussion made clear to not do it in current repo whatever
> > project is used as umbrella so we should revert that and finish the
> > discussion before any action to not kill tomee project by a hard company
> > driven management making it no more in the OSS spirit.
> >
> 
> I agree the discussion should happen first, and I note that the change has
> been reverted. I recall that we agreed on this list that we'd create new
> git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> other components sit under TomEE, I imagine that they would follow the same
> pattern - i.e. discuss first, agree location, create repo or move things
> around as appropriate.
> 
> I don't know what your specific issues are here, but I think you are making
> some assumptions that are simply not true.
> 
> Jon
> 
> 
> 
> >
> > Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> > écrit :
> >
> > > "Parts of the components skeletons you just created"
> > >
> > > They're just logically named empty modules for pending work?
> > >
> > >
> > > On 12/02/18 20:42, Mark Struberg wrote:
> > >
> > >> And what's that for?
> > >>
> > >> Is there any behind the scene stuff going on at Tomitribe or can we
> > >> finally get back to discussing such things on the Apache lists?
> > >>
> > >> Before we go on I'd would first finish the discussion how we want to
> > turn
> > >> TomEE into an umbrella project or how the structure would be. And
> > >> whether/how we want to integrate the modular Geronimo parts into one
> > >> project or not.
> > >>
> > >> Parts of the components skeletons you just created do already exist at
> > >> the ASF.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > >> agumbrecht@tomitribe.com> wrote:
> > >>
> > >>
> > >> Added project stubs:
> > >> https://github.com/apache/tomee/tree/master/microprofile
> > >>
> > >> Andy.
> > >>
> > >>
> > >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> > >> > Hi,
> > >> >
> > >> > Ok thanks guys.
> > >> > @Rudy, you are most welcome :)
> > >> >
> > >> > --
> > >> > Jean-Louis Monteiro
> > >> > http://twitter.com/jlouismonteiro
> > >> > http://www.tomitribe.com
> > >> >
> > >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> > >> rdebusscher@gmail.com <ma...@gmail.com>>
> > >> > wrote:
> > >> >
> > >> >> I think it is a very important spec, also for non-microprofile
> > >> >> implementations as it can enhance the interoperability of all
> > servers.
> > >> >>
> > >> >> I'm also very interested in the implementation (and want to help a
> > bit
> > >> with
> > >> >> it also :) )
> > >> >>
> > >> >> regards
> > >> >> Rudy
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
> > >> <ma...@yahoo.de.invalid>>
> > >> >> wrote:
> > >> >>
> > >> >>> To clarify this even further:
> > >> >>> The Geronimo Server is now officially dead.
> > >> >>> But the Geronimo project is not. It alredy contains quite a few
> > >> modular
> > >> >>> parts which are reused in many ASF projects and also outside.
> > >> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> > >> >>> geronimo-config, xbean-finder, etc
> > >> >>>
> > >> >>> Of course it would probably make sense to fold those 2 projects
> > >> together,
> > >> >>> as already discussed in the past.
> > >> >>> I'm still all open to it, but I have an important criterium to
> > fulfil:
> > >> >>> If we move those portable parts to TomEE, then this would mean that
> > >> TomEE
> > >> >>> would become an 'Umbrella project'.
> > >> >>> And further that we would need a new name for those portable parts.
> > >> >>> They would effectively be mainatained by the TomEE community (which
> > >> has a
> > >> >>> big overlap with Geronimo anyway) but those parts must clearly be
> > >> >>> recognized separately from TomEE.
> > >> >>>
> > >> >>> Otherwise people will assume that those parts only work within
> > TomEE -
> > >> >>> where in reality they would even work on WildFly or Liberty, etc. or
> > >> >> even a
> > >> >>> naked Tomcat.
> > >> >>> Got me?
> > >> >>>
> > >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department'
> > :)
> > >> >>>
> > >> >>> LieGrue,
> > >> >>> strub
> > >> >>>
> > >> >>> PS: I'd also love to keep the org.apache.geronimo package name to
> > ease
> > >> >>> backward compatibility.
> > >> >>>
> > >> >>>
> > >> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> > >> >> rmannibucau@gmail.com <ma...@gmail.com>
> > >> >>>> :
> > >> >>>>
> > >> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > >> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> > >> >>>>
> > >> >>>>> Guys, I have a question:
> > >> >>>>>
> > >> >>>>> Why not a project to each implementation?
> > >> >>>>>
> > >> >>>> this is the case but geronimo is used as an umbrella project.
> > >> >>>>
> > >> >>>>
> > >> >>>>> This way I can use just a specific if I want also.
> > >> >>>>>
> > >> >>>> exactly the goal and user usage AFAIK ;)
> > >> >>>>
> > >> >>>> long story short: we learnt from the past errors and since always
> > the
> > >> >>> same
> > >> >>>> people work on these projects it is better to not split it accross
> > N
> > >> >>>> communities since
> > >> >>>> it leads to a lot of efforts for these people. Having a single
> > >> umbrella
> > >> >>>> project with N subprojects reduces the administrative work etc and
> > >> >>> enhance
> > >> >>>> the projects productivity.
> > >> >>>>
> > >> >>>>
> > >> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> > >> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>>> Hi JL,
> > >> >>>>>>
> > >> >>>>>> Microprofile apache effort is hosted in geronimo and John already
> > >> >> spoke
> > >> >>>>>> about it I think. Would probably saner to keep it all at the same
> > >> >> place
> > >> >>>>> for
> > >> >>>>>> the foundation.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> Romain Manni-Bucau
> > >> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > >> >>>>>> rmannibucau> |
> > >> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >> >>>>>> <https://www.packtpub.com/application-development/java-
> > >> >>>>>> ee-8-high-performance>
> > >> >>>>>>
> > >> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> > >> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> > >> >>>>>> :
> > >> >>>>>>
> > >> >>>>>>> Hi all,
> > >> >>>>>>>
> > >> >>>>>>> I was wondering if we could have the Microprofile JWT
> > implemented
> > >> in
> > >> >>>>>> TomEE.
> > >> >>>>>>> What do you think?
> > >> >>>>>>>
> > >> >>>>>>> I was reading the spec and I'd like to contribute that in.
> > >> >>>>>>>
> > >> >>>>>>> Jean-Louis
> > >> >>>>>>>
> > >> >>>>>>> --
> > >> >>>>>>> Jean-Louis Monteiro
> > >> >>>>>>> http://twitter.com/jlouismonteiro
> > >> >>>>>>> http://www.tomitribe.com
> > >> >>>>>>>
> > >> >>>
> > >>
> > >> --
> > >> Andy Gumbrecht
> > >> https://twitter.com/AndyGeeDe
> > >>
> > >> http://www.tomitribe.com
> > >>
> > >> https://www.tomitribe.io
> > >>
> > >>
> > >> Ubique
> > >>
> > >>
> > >>
> > > --
> > > Andy Gumbrecht
> > > https://twitter.com/AndyGeeDe
> > > http://www.tomitribe.com
> > > https://www.tomitribe.io
> > >
> > >
> > > Ubique
> > >
> > >
> >
> 

Re: Implementing Microprofile JWT

[David Blevins <da...@gmail.com>]

> On Feb 12, 2018, at 1:45 PM, Mark Struberg <st...@yahoo.de.INVALID> wrote:
> 
> It seems we all got hit on the wrong foot in some ways. 
> Why not take the chance to learn something and make it better.
> For me: I should have asked what this is about instead of assuming something which looked clear from my pov. Seems I was wrong.
> @Andy what about creating a ticket on the issue tracker which explains what you are about to do? Just 2 sentences should be enough. Then everything will be much more clear.

Thank you, Mark, for the patient response.


-David

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

It seems we all got hit on the wrong foot in some ways. 
Why not take the chance to learn something and make it better.
For me: I should have asked what this is about instead of assuming something which looked clear from my pov. Seems I was wrong.
@Andy what about creating a ticket on the issue tracker which explains what you are about to do? Just 2 sentences should be enough. Then everything will be much more clear.


 LieGrue,strub

    On Monday, 12 February 2018, 22:22:25 CET, Andy Gumbrecht <ag...@tomitribe.com> wrote:  
 
 I find the discussions and working on TomEE have become tedious, 
contentious, unrewarding and fruitless in order to continue working on 
the project in my free time. That'd be why I've not contributed 
recently, but not speaking for others of course. I wasn't actually 
trying to start any implementations there, rather integration modules 
(I'd started to test geronimo config for example). And yes, I guess I 
avoided the conversation at my own fault. It'll not happen again, I'm 
done with it. So please feel free to carry on. Me personally, I only get 
annoyed when something gets trashed. Nothing was done in any Tomitribe 
capacity this evening, but those accusations are pretty commonplace now. 
I would point the 'killing' and 'ownership' finger in another direction. 
I see efforts have obviously been directed away from TomEE to the 
benefit of other projects and detriment of TomEE, and you know I'm not 
talking about geronimo. Anyways, no problem. Not going to get stressed 
about it. Have fun.

Andy.


On 12/02/18 21:44, Mark Struberg wrote:
> Well, let's be a bit more specific.
> a.)
> No, Geronimo of course does not have have a monopoly on creating microprofile implementations at the ASF. Nor does TomEE.
> Geronimo a good place for reusable JavaEE parts though. And G started to implement Microprofile specifications 2 years ago already. There is already quite a lot in existence over there. You really should take a look over the fence.
>
> Instead of duplicating the work which is already done I would prefer if some folks would help with more important tasks. E.g. finally finishing TomEE8. Romain and I have so far been the ONLY ones working on that effort for the whole last year.
> b.) > I understand it is not the most convenient for tomitribe which probably
>> perfers to own the full project(s) Tomitribe itself does not own TomEE nor created it, etc.The actual core part of TomEE (OpenEJB) is acually only a fraction of what the whole project is.It's an excellent aggregator project. But if you count in all the other parts which were needed to create TomEE7 and 8, then the whole sum is about 20 times the size of openejb: tomcat, openwebbeans, bval, johnzon, geronimo-tx, geronimo-javamail, geronimo-specs, cxf, activemq, openjpa, MyFaces, etc etc Each of those projects has at
>
> c.) There have been a lot of talks about moving the reusable parts of Geronimo under the umbrella of the TomEE project. That would be perfectly fine. But I iterate it once again. There are 2 tasks to do before we can go on:
> 1.) TomEE needs to become an umbrella project2.) the name of the reusable components must be clearly separated from the TomEE Application Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces had - that people would not identify those components as being totally independent of the TomEE application server and separately usable.
>
>
> LieGrue,strub
>  
>
>
>      On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau <rm...@gmail.com> wrote:
>  
>  No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> @asf. This is why jwt should probably be done in geronimo which is the asf
> ee related project umbrella.
>
> I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) but as a foundation member I d really
> like to not let company details pollute projects.
>
> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard company
> driven management making it no more in the OSS spirit.
>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> écrit :
>
>> "Parts of the components skeletons you just created"
>>
>> They're just logically named empty modules for pending work?
>>
>>
>> On 12/02/18 20:42, Mark Struberg wrote:
>>
>>> And what's that for?
>>>
>>> Is there any behind the scene stuff going on at Tomitribe or can we
>>> finally get back to discussing such things on the Apache lists?
>>>
>>> Before we go on I'd would first finish the discussion how we want to turn
>>> TomEE into an umbrella project or how the structure would be. And
>>> whether/how we want to integrate the modular Geronimo parts into one
>>> project or not.
>>>
>>> Parts of the components skeletons you just created do already exist at
>>> the ASF.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>>> agumbrecht@tomitribe.com> wrote:
>>>
>>>
>>> Added project stubs:
>>> https://github.com/apache/tomee/tree/master/microprofile
>>>
>>> Andy.
>>>
>>>
>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>> Hi,
>>>>
>>>> Ok thanks guys.
>>>> @Rudy, you are most welcome :)
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>> rdebusscher@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>
>>>>> I think it is a very important spec, also for non-microprofile
>>>>> implementations as it can enhance the interoperability of all servers.
>>>>>
>>>>> I'm also very interested in the implementation (and want to help a bit
>>> with
>>>>> it also :) )
>>>>>
>>>>> regards
>>>>> Rudy
>>>>>
>>>>>
>>>>>
>>>>> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
>>> <ma...@yahoo.de.invalid>>
>>>>> wrote:
>>>>>
>>>>>> To clarify this even further:
>>>>>> The Geronimo Server is now officially dead.
>>>>>> But the Geronimo project is not. It alredy contains quite a few
>>> modular
>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>>>> geronimo-config, xbean-finder, etc
>>>>>>
>>>>>> Of course it would probably make sense to fold those 2 projects
>>> together,
>>>>>> as already discussed in the past.
>>>>>> I'm still all open to it, but I have an important criterium to fulfil:
>>>>>> If we move those portable parts to TomEE, then this would mean that
>>> TomEE
>>>>>> would become an 'Umbrella project'.
>>>>>> And further that we would need a new name for those portable parts.
>>>>>> They would effectively be mainatained by the TomEE community (which
>>> has a
>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>>>> recognized separately from TomEE.
>>>>>>
>>>>>> Otherwise people will assume that those parts only work within TomEE -
>>>>>> where in reality they would even work on WildFly or Liberty, etc. or
>>>>> even a
>>>>>> naked Tomcat.
>>>>>> Got me?
>>>>>>
>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>>>>> backward compatibility.
>>>>>>
>>>>>>
>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>> :
>>>>>>>
>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>>>>>>>
>>>>>>>> Guys, I have a question:
>>>>>>>>
>>>>>>>> Why not a project to each implementation?
>>>>>>>>
>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>
>>>>>>>
>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>
>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>
>>>>>>> long story short: we learnt from the past errors and since always the
>>>>>> same
>>>>>>> people work on these projects it is better to not split it accross N
>>>>>>> communities since
>>>>>>> it leads to a lot of efforts for these people. Having a single
>>> umbrella
>>>>>>> project with N subprojects reduces the administrative work etc and
>>>>>> enhance
>>>>>>> the projects productivity.
>>>>>>>
>>>>>>>
>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi JL,
>>>>>>>>>
>>>>>>>>> Microprofile apache effort is hosted in geronimo and John already
>>>>> spoke
>>>>>>>>> about it I think. Would probably saner to keep it all at the same
>>>>> place
>>>>>>>> for
>>>>>>>>> the foundation.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>>>>> rmannibucau> |
>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>> ee-8-high-performance>
>>>>>>>>>
>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I was wondering if we could have the Microprofile JWT implemented
>>> in
>>>>>>>>> TomEE.
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>
>>>>>>>>>> Jean-Louis
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>
>>> --
>>> Andy Gumbrecht
>>> https://twitter.com/AndyGeeDe
>>>
>>> http://www.tomitribe.com
>>>
>>> https://www.tomitribe.io
>>>
>>>
>>> Ubique
>>>
>>>
>>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>> https://www.tomitribe.io
>>
>>
>> Ubique
>>
>>  

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

  

Re: Implementing Microprofile JWT

[Andy Gumbrecht <ag...@tomitribe.com>]

I find the discussions and working on TomEE have become tedious, 
contentious, unrewarding and fruitless in order to continue working on 
the project in my free time. That'd be why I've not contributed 
recently, but not speaking for others of course. I wasn't actually 
trying to start any implementations there, rather integration modules 
(I'd started to test geronimo config for example). And yes, I guess I 
avoided the conversation at my own fault. It'll not happen again, I'm 
done with it. So please feel free to carry on. Me personally, I only get 
annoyed when something gets trashed. Nothing was done in any Tomitribe 
capacity this evening, but those accusations are pretty commonplace now. 
I would point the 'killing' and 'ownership' finger in another direction. 
I see efforts have obviously been directed away from TomEE to the 
benefit of other projects and detriment of TomEE, and you know I'm not 
talking about geronimo. Anyways, no problem. Not going to get stressed 
about it. Have fun.

Andy.


On 12/02/18 21:44, Mark Struberg wrote:
> Well, let's be a bit more specific.
> a.)
> No, Geronimo of course does not have have a monopoly on creating microprofile implementations at the ASF. Nor does TomEE.
> Geronimo a good place for reusable JavaEE parts though. And G started to implement Microprofile specifications 2 years ago already. There is already quite a lot in existence over there. You really should take a look over the fence.
>
> Instead of duplicating the work which is already done I would prefer if some folks would help with more important tasks. E.g. finally finishing TomEE8. Romain and I have so far been the ONLY ones working on that effort for the whole last year.
> b.) > I understand it is not the most convenient for tomitribe which probably
>> perfers to own the full project(s) Tomitribe itself does not own TomEE nor created it, etc.The actual core part of TomEE (OpenEJB) is acually only a fraction of what the whole project is.It's an excellent aggregator project. But if you count in all the other parts which were needed to create TomEE7 and 8, then the whole sum is about 20 times the size of openejb: tomcat, openwebbeans, bval, johnzon, geronimo-tx, geronimo-javamail, geronimo-specs, cxf, activemq, openjpa, MyFaces, etc etc Each of those projects has at
>
> c.) There have been a lot of talks about moving the reusable parts of Geronimo under the umbrella of the TomEE project. That would be perfectly fine. But I iterate it once again. There are 2 tasks to do before we can go on:
> 1.) TomEE needs to become an umbrella project2.) the name of the reusable components must be clearly separated from the TomEE Application Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces had - that people would not identify those components as being totally independent of the TomEE application server and separately usable.
>
>
> LieGrue,strub
>   
>
>
>      On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau <rm...@gmail.com> wrote:
>   
>   No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> @asf. This is why jwt should probably be done in geronimo which is the asf
> ee related project umbrella.
>
> I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) but as a foundation member I d really
> like to not let company details pollute projects.
>
> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard company
> driven management making it no more in the OSS spirit.
>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> écrit :
>
>> "Parts of the components skeletons you just created"
>>
>> They're just logically named empty modules for pending work?
>>
>>
>> On 12/02/18 20:42, Mark Struberg wrote:
>>
>>> And what's that for?
>>>
>>> Is there any behind the scene stuff going on at Tomitribe or can we
>>> finally get back to discussing such things on the Apache lists?
>>>
>>> Before we go on I'd would first finish the discussion how we want to turn
>>> TomEE into an umbrella project or how the structure would be. And
>>> whether/how we want to integrate the modular Geronimo parts into one
>>> project or not.
>>>
>>> Parts of the components skeletons you just created do already exist at
>>> the ASF.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>>> agumbrecht@tomitribe.com> wrote:
>>>
>>>
>>> Added project stubs:
>>> https://github.com/apache/tomee/tree/master/microprofile
>>>
>>> Andy.
>>>
>>>
>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>>>> Hi,
>>>>
>>>> Ok thanks guys.
>>>> @Rudy, you are most welcome :)
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>>> rdebusscher@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>
>>>>> I think it is a very important spec, also for non-microprofile
>>>>> implementations as it can enhance the interoperability of all servers.
>>>>>
>>>>> I'm also very interested in the implementation (and want to help a bit
>>> with
>>>>> it also :) )
>>>>>
>>>>> regards
>>>>> Rudy
>>>>>
>>>>>
>>>>>
>>>>> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
>>> <ma...@yahoo.de.invalid>>
>>>>> wrote:
>>>>>
>>>>>> To clarify this even further:
>>>>>> The Geronimo Server is now officially dead.
>>>>>> But the Geronimo project is not. It alredy contains quite a few
>>> modular
>>>>>> parts which are reused in many ASF projects and also outside.
>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>>>>> geronimo-config, xbean-finder, etc
>>>>>>
>>>>>> Of course it would probably make sense to fold those 2 projects
>>> together,
>>>>>> as already discussed in the past.
>>>>>> I'm still all open to it, but I have an important criterium to fulfil:
>>>>>> If we move those portable parts to TomEE, then this would mean that
>>> TomEE
>>>>>> would become an 'Umbrella project'.
>>>>>> And further that we would need a new name for those portable parts.
>>>>>> They would effectively be mainatained by the TomEE community (which
>>> has a
>>>>>> big overlap with Geronimo anyway) but those parts must clearly be
>>>>>> recognized separately from TomEE.
>>>>>>
>>>>>> Otherwise people will assume that those parts only work within TomEE -
>>>>>> where in reality they would even work on WildFly or Liberty, etc. or
>>>>> even a
>>>>>> naked Tomcat.
>>>>>> Got me?
>>>>>>
>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>>>>> backward compatibility.
>>>>>>
>>>>>>
>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>> :
>>>>>>>
>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>>>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>>>>>>>
>>>>>>>> Guys, I have a question:
>>>>>>>>
>>>>>>>> Why not a project to each implementation?
>>>>>>>>
>>>>>>> this is the case but geronimo is used as an umbrella project.
>>>>>>>
>>>>>>>
>>>>>>>> This way I can use just a specific if I want also.
>>>>>>>>
>>>>>>> exactly the goal and user usage AFAIK ;)
>>>>>>>
>>>>>>> long story short: we learnt from the past errors and since always the
>>>>>> same
>>>>>>> people work on these projects it is better to not split it accross N
>>>>>>> communities since
>>>>>>> it leads to a lot of efforts for these people. Having a single
>>> umbrella
>>>>>>> project with N subprojects reduces the administrative work etc and
>>>>>> enhance
>>>>>>> the projects productivity.
>>>>>>>
>>>>>>>
>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com <ma...@gmail.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi JL,
>>>>>>>>>
>>>>>>>>> Microprofile apache effort is hosted in geronimo and John already
>>>>> spoke
>>>>>>>>> about it I think. Would probably saner to keep it all at the same
>>>>> place
>>>>>>>> for
>>>>>>>>> the foundation.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>>>>> rmannibucau> |
>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>>>>> ee-8-high-performance>
>>>>>>>>>
>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>>>>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I was wondering if we could have the Microprofile JWT implemented
>>> in
>>>>>>>>> TomEE.
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>>>>
>>>>>>>>>> Jean-Louis
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jean-Louis Monteiro
>>>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>>>> http://www.tomitribe.com
>>>>>>>>>>
>>> --
>>> Andy Gumbrecht
>>> https://twitter.com/AndyGeeDe
>>>
>>> http://www.tomitribe.com
>>>
>>> https://www.tomitribe.io
>>>
>>>
>>> Ubique
>>>
>>>
>>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>> https://www.tomitribe.io
>>
>>
>> Ubique
>>
>>   

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Implementing Microprofile JWT

[Jonathan Gallimore <jo...@gmail.com>]

I'll apologize for not doing more on TomEE 8. But that is simply a time
thing, and not a Tomitribe thing. I still owe a fixed build on master
(which I am working on tonight) and forward porting the latest master
patches to the EE8 branch. That work is not forgotten, just has to be
fitted in with everything else.

I'm not sure where your Tomitribe-related assumptions are coming from, and
they do not seem accurate or fair. My opinion, is my opinion, and it should
still count, irrespective of who employs me. I think the commit was simply
an error, and not a deliberate attempt to circumvent conversation.

Jon

On Mon, Feb 12, 2018 at 8:44 PM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> Well, let's be a bit more specific.
> a.)
> No, Geronimo of course does not have have a monopoly on creating
> microprofile implementations at the ASF. Nor does TomEE.
> Geronimo a good place for reusable JavaEE parts though. And G started to
> implement Microprofile specifications 2 years ago already. There is already
> quite a lot in existence over there. You really should take a look over the
> fence.
>
> Instead of duplicating the work which is already done I would prefer if
> some folks would help with more important tasks. E.g. finally finishing
> TomEE8. Romain and I have so far been the ONLY ones working on that effort
> for the whole last year.
> b.) > I understand it is not the most convenient for tomitribe which
> probably
> > perfers to own the full project(s) Tomitribe itself does not own TomEE
> nor created it, etc.The actual core part of TomEE (OpenEJB) is acually only
> a fraction of what the whole project is.It's an excellent aggregator
> project. But if you count in all the other parts which were needed to
> create TomEE7 and 8, then the whole sum is about 20 times the size of
> openejb: tomcat, openwebbeans, bval, johnzon, geronimo-tx,
> geronimo-javamail, geronimo-specs, cxf, activemq, openjpa, MyFaces, etc etc
> Each of those projects has at


>
> c.) There have been a lot of talks about moving the reusable parts of
> Geronimo under the umbrella of the TomEE project. That would be perfectly
> fine. But I iterate it once again. There are 2 tasks to do before we can go
> on:
> 1.) TomEE needs to become an umbrella project2.) the name of the reusable
> components must be clearly separated from the TomEE Application
> Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces
> had - that people would not identify those components as being totally
> independent of the TomEE application server and separately usable.
>
>
> LieGrue,strub
>
>
>
>     On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>  No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> @asf. This is why jwt should probably be done in geronimo which is the asf
> ee related project umbrella.
>
> I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) but as a foundation member I d really
> like to not let company details pollute projects.
>
> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard company
> driven management making it no more in the OSS spirit.
>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> écrit :
>
> > "Parts of the components skeletons you just created"
> >
> > They're just logically named empty modules for pending work?
> >
> >
> > On 12/02/18 20:42, Mark Struberg wrote:
> >
> >> And what's that for?
> >>
> >> Is there any behind the scene stuff going on at Tomitribe or can we
> >> finally get back to discussing such things on the Apache lists?
> >>
> >> Before we go on I'd would first finish the discussion how we want to
> turn
> >> TomEE into an umbrella project or how the structure would be. And
> >> whether/how we want to integrate the modular Geronimo parts into one
> >> project or not.
> >>
> >> Parts of the components skeletons you just created do already exist at
> >> the ASF.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >> agumbrecht@tomitribe.com> wrote:
> >>
> >>
> >> Added project stubs:
> >> https://github.com/apache/tomee/tree/master/microprofile
> >>
> >> Andy.
> >>
> >>
> >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >> > Hi,
> >> >
> >> > Ok thanks guys.
> >> > @Rudy, you are most welcome :)
> >> >
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >> rdebusscher@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> >
> >> >> I think it is a very important spec, also for non-microprofile
> >> >> implementations as it can enhance the interoperability of all
> servers.
> >> >>
> >> >> I'm also very interested in the implementation (and want to help a
> bit
> >> with
> >> >> it also :) )
> >> >>
> >> >> regards
> >> >> Rudy
> >> >>
> >> >>
> >> >>
> >> >> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
> >> <ma...@yahoo.de.invalid>>
> >> >> wrote:
> >> >>
> >> >>> To clarify this even further:
> >> >>> The Geronimo Server is now officially dead.
> >> >>> But the Geronimo project is not. It alredy contains quite a few
> >> modular
> >> >>> parts which are reused in many ASF projects and also outside.
> >> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >> >>> geronimo-config, xbean-finder, etc
> >> >>>
> >> >>> Of course it would probably make sense to fold those 2 projects
> >> together,
> >> >>> as already discussed in the past.
> >> >>> I'm still all open to it, but I have an important criterium to
> fulfil:
> >> >>> If we move those portable parts to TomEE, then this would mean that
> >> TomEE
> >> >>> would become an 'Umbrella project'.
> >> >>> And further that we would need a new name for those portable parts.
> >> >>> They would effectively be mainatained by the TomEE community (which
> >> has a
> >> >>> big overlap with Geronimo anyway) but those parts must clearly be
> >> >>> recognized separately from TomEE.
> >> >>>
> >> >>> Otherwise people will assume that those parts only work within
> TomEE -
> >> >>> where in reality they would even work on WildFly or Liberty, etc. or
> >> >> even a
> >> >>> naked Tomcat.
> >> >>> Got me?
> >> >>>
> >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department'
> :)
> >> >>>
> >> >>> LieGrue,
> >> >>> strub
> >> >>>
> >> >>> PS: I'd also love to keep the org.apache.geronimo package name to
> ease
> >> >>> backward compatibility.
> >> >>>
> >> >>>
> >> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >> >> rmannibucau@gmail.com <ma...@gmail.com>
> >> >>>> :
> >> >>>>
> >> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> >> >>>>
> >> >>>>> Guys, I have a question:
> >> >>>>>
> >> >>>>> Why not a project to each implementation?
> >> >>>>>
> >> >>>> this is the case but geronimo is used as an umbrella project.
> >> >>>>
> >> >>>>
> >> >>>>> This way I can use just a specific if I want also.
> >> >>>>>
> >> >>>> exactly the goal and user usage AFAIK ;)
> >> >>>>
> >> >>>> long story short: we learnt from the past errors and since always
> the
> >> >>> same
> >> >>>> people work on these projects it is better to not split it accross
> N
> >> >>>> communities since
> >> >>>> it leads to a lot of efforts for these people. Having a single
> >> umbrella
> >> >>>> project with N subprojects reduces the administrative work etc and
> >> >>> enhance
> >> >>>> the projects productivity.
> >> >>>>
> >> >>>>
> >> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>> Hi JL,
> >> >>>>>>
> >> >>>>>> Microprofile apache effort is hosted in geronimo and John already
> >> >> spoke
> >> >>>>>> about it I think. Would probably saner to keep it all at the same
> >> >> place
> >> >>>>> for
> >> >>>>>> the foundation.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Romain Manni-Bucau
> >> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >> >>>>>> rmannibucau> |
> >> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> >>>>>> <https://www.packtpub.com/application-development/java-
> >> >>>>>> ee-8-high-performance>
> >> >>>>>>
> >> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> >> >>>>>> :
> >> >>>>>>
> >> >>>>>>> Hi all,
> >> >>>>>>>
> >> >>>>>>> I was wondering if we could have the Microprofile JWT
> implemented
> >> in
> >> >>>>>> TomEE.
> >> >>>>>>> What do you think?
> >> >>>>>>>
> >> >>>>>>> I was reading the spec and I'd like to contribute that in.
> >> >>>>>>>
> >> >>>>>>> Jean-Louis
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> Jean-Louis Monteiro
> >> >>>>>>> http://twitter.com/jlouismonteiro
> >> >>>>>>> http://www.tomitribe.com
> >> >>>>>>>
> >> >>>
> >>
> >> --
> >> Andy Gumbrecht
> >> https://twitter.com/AndyGeeDe
> >>
> >> http://www.tomitribe.com
> >>
> >> https://www.tomitribe.io
> >>
> >>
> >> Ubique
> >>
> >>
> >>
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> > https://www.tomitribe.io
> >
> >
> > Ubique
> >
> >
>

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

Well, let's be a bit more specific.
a.)
No, Geronimo of course does not have have a monopoly on creating microprofile implementations at the ASF. Nor does TomEE.
Geronimo a good place for reusable JavaEE parts though. And G started to implement Microprofile specifications 2 years ago already. There is already quite a lot in existence over there. You really should take a look over the fence.

Instead of duplicating the work which is already done I would prefer if some folks would help with more important tasks. E.g. finally finishing TomEE8. Romain and I have so far been the ONLY ones working on that effort for the whole last year. 
b.) > I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) Tomitribe itself does not own TomEE nor created it, etc.The actual core part of TomEE (OpenEJB) is acually only a fraction of what the whole project is.It's an excellent aggregator project. But if you count in all the other parts which were needed to create TomEE7 and 8, then the whole sum is about 20 times the size of openejb: tomcat, openwebbeans, bval, johnzon, geronimo-tx, geronimo-javamail, geronimo-specs, cxf, activemq, openjpa, MyFaces, etc etc Each of those projects has at 


c.) There have been a lot of talks about moving the reusable parts of Geronimo under the umbrella of the TomEE project. That would be perfectly fine. But I iterate it once again. There are 2 tasks to do before we can go on:
1.) TomEE needs to become an umbrella project2.) the name of the reusable components must be clearly separated from the TomEE Application Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces had - that people would not identify those components as being totally independent of the TomEE application server and separately usable.


LieGrue,strub
 


    On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau <rm...@gmail.com> wrote:  
 
 No Andy, as mentionned in the discussion Geronimo hosts the microprofile
@asf. This is why jwt should probably be done in geronimo which is the asf
ee related project umbrella.

I understand it is not the most convenient for tomitribe which probably
perfers to own the full project(s) but as a foundation member I d really
like to not let company details pollute projects.

Also the discussion made clear to not do it in current repo whatever
project is used as umbrella so we should revert that and finish the
discussion before any action to not kill tomee project by a hard company
driven management making it no more in the OSS spirit.

Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
écrit :

> "Parts of the components skeletons you just created"
>
> They're just logically named empty modules for pending work?
>
>
> On 12/02/18 20:42, Mark Struberg wrote:
>
>> And what's that for?
>>
>> Is there any behind the scene stuff going on at Tomitribe or can we
>> finally get back to discussing such things on the Apache lists?
>>
>> Before we go on I'd would first finish the discussion how we want to turn
>> TomEE into an umbrella project or how the structure would be. And
>> whether/how we want to integrate the modular Geronimo parts into one
>> project or not.
>>
>> Parts of the components skeletons you just created do already exist at
>> the ASF.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>> agumbrecht@tomitribe.com> wrote:
>>
>>
>> Added project stubs:
>> https://github.com/apache/tomee/tree/master/microprofile
>>
>> Andy.
>>
>>
>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>> > Hi,
>> >
>> > Ok thanks guys.
>> > @Rudy, you are most welcome :)
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>> rdebusscher@gmail.com <ma...@gmail.com>>
>> > wrote:
>> >
>> >> I think it is a very important spec, also for non-microprofile
>> >> implementations as it can enhance the interoperability of all servers.
>> >>
>> >> I'm also very interested in the implementation (and want to help a bit
>> with
>> >> it also :) )
>> >>
>> >> regards
>> >> Rudy
>> >>
>> >>
>> >>
>> >> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
>> <ma...@yahoo.de.invalid>>
>> >> wrote:
>> >>
>> >>> To clarify this even further:
>> >>> The Geronimo Server is now officially dead.
>> >>> But the Geronimo project is not. It alredy contains quite a few
>> modular
>> >>> parts which are reused in many ASF projects and also outside.
>> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>> >>> geronimo-config, xbean-finder, etc
>> >>>
>> >>> Of course it would probably make sense to fold those 2 projects
>> together,
>> >>> as already discussed in the past.
>> >>> I'm still all open to it, but I have an important criterium to fulfil:
>> >>> If we move those portable parts to TomEE, then this would mean that
>> TomEE
>> >>> would become an 'Umbrella project'.
>> >>> And further that we would need a new name for those portable parts.
>> >>> They would effectively be mainatained by the TomEE community (which
>> has a
>> >>> big overlap with Geronimo anyway) but those parts must clearly be
>> >>> recognized separately from TomEE.
>> >>>
>> >>> Otherwise people will assume that those parts only work within TomEE -
>> >>> where in reality they would even work on WildFly or Liberty, etc. or
>> >> even a
>> >>> naked Tomcat.
>> >>> Got me?
>> >>>
>> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>> >>>
>> >>> LieGrue,
>> >>> strub
>> >>>
>> >>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>> >>> backward compatibility.
>> >>>
>> >>>
>> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> >> rmannibucau@gmail.com <ma...@gmail.com>
>> >>>> :
>> >>>>
>> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>> >>>>
>> >>>>> Guys, I have a question:
>> >>>>>
>> >>>>> Why not a project to each implementation?
>> >>>>>
>> >>>> this is the case but geronimo is used as an umbrella project.
>> >>>>
>> >>>>
>> >>>>> This way I can use just a specific if I want also.
>> >>>>>
>> >>>> exactly the goal and user usage AFAIK ;)
>> >>>>
>> >>>> long story short: we learnt from the past errors and since always the
>> >>> same
>> >>>> people work on these projects it is better to not split it accross N
>> >>>> communities since
>> >>>> it leads to a lot of efforts for these people. Having a single
>> umbrella
>> >>>> project with N subprojects reduces the administrative work etc and
>> >>> enhance
>> >>>> the projects productivity.
>> >>>>
>> >>>>
>> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>> >>> rmannibucau@gmail.com <ma...@gmail.com>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi JL,
>> >>>>>>
>> >>>>>> Microprofile apache effort is hosted in geronimo and John already
>> >> spoke
>> >>>>>> about it I think. Would probably saner to keep it all at the same
>> >> place
>> >>>>> for
>> >>>>>> the foundation.
>> >>>>>>
>> >>>>>>
>> >>>>>> Romain Manni-Bucau
>> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> >>>>>> rmannibucau> |
>> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >>>>>> <https://www.packtpub.com/application-development/java-
>> >>>>>> ee-8-high-performance>
>> >>>>>>
>> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>> >>>>>> :
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> I was wondering if we could have the Microprofile JWT implemented
>> in
>> >>>>>> TomEE.
>> >>>>>>> What do you think?
>> >>>>>>>
>> >>>>>>> I was reading the spec and I'd like to contribute that in.
>> >>>>>>>
>> >>>>>>> Jean-Louis
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Jean-Louis Monteiro
>> >>>>>>> http://twitter.com/jlouismonteiro
>> >>>>>>> http://www.tomitribe.com
>> >>>>>>>
>> >>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>>
>> http://www.tomitribe.com
>>
>> https://www.tomitribe.io
>>
>>
>> Ubique
>>
>>
>>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique
>
>  

Re: Implementing Microprofile JWT

[Jonathan Gallimore <jo...@gmail.com>]

On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> @asf. This is why jwt should probably be done in geronimo which is the asf
> ee related project umbrella.
>

I don't recall that discussion. Where did it take place?


>
> I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) but as a foundation member I d really
> like to not let company details pollute projects


> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard company
> driven management making it no more in the OSS spirit.
>

I agree the discussion should happen first, and I note that the change has
been reverted. I recall that we agreed on this list that we'd create new
git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
other components sit under TomEE, I imagine that they would follow the same
pattern - i.e. discuss first, agree location, create repo or move things
around as appropriate.

I don't know what your specific issues are here, but I think you are making
some assumptions that are simply not true.

Jon



>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
> écrit :
>
> > "Parts of the components skeletons you just created"
> >
> > They're just logically named empty modules for pending work?
> >
> >
> > On 12/02/18 20:42, Mark Struberg wrote:
> >
> >> And what's that for?
> >>
> >> Is there any behind the scene stuff going on at Tomitribe or can we
> >> finally get back to discussing such things on the Apache lists?
> >>
> >> Before we go on I'd would first finish the discussion how we want to
> turn
> >> TomEE into an umbrella project or how the structure would be. And
> >> whether/how we want to integrate the modular Geronimo parts into one
> >> project or not.
> >>
> >> Parts of the components skeletons you just created do already exist at
> >> the ASF.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >> agumbrecht@tomitribe.com> wrote:
> >>
> >>
> >> Added project stubs:
> >> https://github.com/apache/tomee/tree/master/microprofile
> >>
> >> Andy.
> >>
> >>
> >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >> > Hi,
> >> >
> >> > Ok thanks guys.
> >> > @Rudy, you are most welcome :)
> >> >
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >> rdebusscher@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> >
> >> >> I think it is a very important spec, also for non-microprofile
> >> >> implementations as it can enhance the interoperability of all
> servers.
> >> >>
> >> >> I'm also very interested in the implementation (and want to help a
> bit
> >> with
> >> >> it also :) )
> >> >>
> >> >> regards
> >> >> Rudy
> >> >>
> >> >>
> >> >>
> >> >> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
> >> <ma...@yahoo.de.invalid>>
> >> >> wrote:
> >> >>
> >> >>> To clarify this even further:
> >> >>> The Geronimo Server is now officially dead.
> >> >>> But the Geronimo project is not. It alredy contains quite a few
> >> modular
> >> >>> parts which are reused in many ASF projects and also outside.
> >> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >> >>> geronimo-config, xbean-finder, etc
> >> >>>
> >> >>> Of course it would probably make sense to fold those 2 projects
> >> together,
> >> >>> as already discussed in the past.
> >> >>> I'm still all open to it, but I have an important criterium to
> fulfil:
> >> >>> If we move those portable parts to TomEE, then this would mean that
> >> TomEE
> >> >>> would become an 'Umbrella project'.
> >> >>> And further that we would need a new name for those portable parts.
> >> >>> They would effectively be mainatained by the TomEE community (which
> >> has a
> >> >>> big overlap with Geronimo anyway) but those parts must clearly be
> >> >>> recognized separately from TomEE.
> >> >>>
> >> >>> Otherwise people will assume that those parts only work within
> TomEE -
> >> >>> where in reality they would even work on WildFly or Liberty, etc. or
> >> >> even a
> >> >>> naked Tomcat.
> >> >>> Got me?
> >> >>>
> >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department'
> :)
> >> >>>
> >> >>> LieGrue,
> >> >>> strub
> >> >>>
> >> >>> PS: I'd also love to keep the org.apache.geronimo package name to
> ease
> >> >>> backward compatibility.
> >> >>>
> >> >>>
> >> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >> >> rmannibucau@gmail.com <ma...@gmail.com>
> >> >>>> :
> >> >>>>
> >> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> >> >>>>
> >> >>>>> Guys, I have a question:
> >> >>>>>
> >> >>>>> Why not a project to each implementation?
> >> >>>>>
> >> >>>> this is the case but geronimo is used as an umbrella project.
> >> >>>>
> >> >>>>
> >> >>>>> This way I can use just a specific if I want also.
> >> >>>>>
> >> >>>> exactly the goal and user usage AFAIK ;)
> >> >>>>
> >> >>>> long story short: we learnt from the past errors and since always
> the
> >> >>> same
> >> >>>> people work on these projects it is better to not split it accross
> N
> >> >>>> communities since
> >> >>>> it leads to a lot of efforts for these people. Having a single
> >> umbrella
> >> >>>> project with N subprojects reduces the administrative work etc and
> >> >>> enhance
> >> >>>> the projects productivity.
> >> >>>>
> >> >>>>
> >> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>> Hi JL,
> >> >>>>>>
> >> >>>>>> Microprofile apache effort is hosted in geronimo and John already
> >> >> spoke
> >> >>>>>> about it I think. Would probably saner to keep it all at the same
> >> >> place
> >> >>>>> for
> >> >>>>>> the foundation.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Romain Manni-Bucau
> >> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >> >>>>>> rmannibucau> |
> >> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> >>>>>> <https://www.packtpub.com/application-development/java-
> >> >>>>>> ee-8-high-performance>
> >> >>>>>>
> >> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> >> >>>>>> :
> >> >>>>>>
> >> >>>>>>> Hi all,
> >> >>>>>>>
> >> >>>>>>> I was wondering if we could have the Microprofile JWT
> implemented
> >> in
> >> >>>>>> TomEE.
> >> >>>>>>> What do you think?
> >> >>>>>>>
> >> >>>>>>> I was reading the spec and I'd like to contribute that in.
> >> >>>>>>>
> >> >>>>>>> Jean-Louis
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> Jean-Louis Monteiro
> >> >>>>>>> http://twitter.com/jlouismonteiro
> >> >>>>>>> http://www.tomitribe.com
> >> >>>>>>>
> >> >>>
> >>
> >> --
> >> Andy Gumbrecht
> >> https://twitter.com/AndyGeeDe
> >>
> >> http://www.tomitribe.com
> >>
> >> https://www.tomitribe.io
> >>
> >>
> >> Ubique
> >>
> >>
> >>
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> > https://www.tomitribe.io
> >
> >
> > Ubique
> >
> >
>

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

No Andy, as mentionned in the discussion Geronimo hosts the microprofile
@asf. This is why jwt should probably be done in geronimo which is the asf
ee related project umbrella.

I understand it is not the most convenient for tomitribe which probably
perfers to own the full project(s) but as a foundation member I d really
like to not let company details pollute projects.

Also the discussion made clear to not do it in current repo whatever
project is used as umbrella so we should revert that and finish the
discussion before any action to not kill tomee project by a hard company
driven management making it no more in the OSS spirit.

Le 12 févr. 2018 21:14, "Andy Gumbrecht" <ag...@tomitribe.com> a
écrit :

> "Parts of the components skeletons you just created"
>
> They're just logically named empty modules for pending work?
>
>
> On 12/02/18 20:42, Mark Struberg wrote:
>
>> And what's that for?
>>
>> Is there any behind the scene stuff going on at Tomitribe or can we
>> finally get back to discussing such things on the Apache lists?
>>
>> Before we go on I'd would first finish the discussion how we want to turn
>> TomEE into an umbrella project or how the structure would be. And
>> whether/how we want to integrate the modular Geronimo parts into one
>> project or not.
>>
>> Parts of the components skeletons you just created do already exist at
>> the ASF.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>> agumbrecht@tomitribe.com> wrote:
>>
>>
>> Added project stubs:
>> https://github.com/apache/tomee/tree/master/microprofile
>>
>> Andy.
>>
>>
>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>> > Hi,
>> >
>> > Ok thanks guys.
>> > @Rudy, you are most welcome :)
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>> rdebusscher@gmail.com <ma...@gmail.com>>
>> > wrote:
>> >
>> >> I think it is a very important spec, also for non-microprofile
>> >> implementations as it can enhance the interoperability of all servers.
>> >>
>> >> I'm also very interested in the implementation (and want to help a bit
>> with
>> >> it also :) )
>> >>
>> >> regards
>> >> Rudy
>> >>
>> >>
>> >>
>> >> On 2 February 2018 at 11:23, Mark Struberg <struberg@yahoo.de.invalid
>> <ma...@yahoo.de.invalid>>
>> >> wrote:
>> >>
>> >>> To clarify this even further:
>> >>> The Geronimo Server is now officially dead.
>> >>> But the Geronimo project is not. It alredy contains quite a few
>> modular
>> >>> parts which are reused in many ASF projects and also outside.
>> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>> >>> geronimo-config, xbean-finder, etc
>> >>>
>> >>> Of course it would probably make sense to fold those 2 projects
>> together,
>> >>> as already discussed in the past.
>> >>> I'm still all open to it, but I have an important criterium to fulfil:
>> >>> If we move those portable parts to TomEE, then this would mean that
>> TomEE
>> >>> would become an 'Umbrella project'.
>> >>> And further that we would need a new name for those portable parts.
>> >>> They would effectively be mainatained by the TomEE community (which
>> has a
>> >>> big overlap with Geronimo anyway) but those parts must clearly be
>> >>> recognized separately from TomEE.
>> >>>
>> >>> Otherwise people will assume that those parts only work within TomEE -
>> >>> where in reality they would even work on WildFly or Liberty, etc. or
>> >> even a
>> >>> naked Tomcat.
>> >>> Got me?
>> >>>
>> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>> >>>
>> >>> LieGrue,
>> >>> strub
>> >>>
>> >>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>> >>> backward compatibility.
>> >>>
>> >>>
>> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> >> rmannibucau@gmail.com <ma...@gmail.com>
>> >>>> :
>> >>>>
>> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>> >>>>
>> >>>>> Guys, I have a question:
>> >>>>>
>> >>>>> Why not a project to each implementation?
>> >>>>>
>> >>>> this is the case but geronimo is used as an umbrella project.
>> >>>>
>> >>>>
>> >>>>> This way I can use just a specific if I want also.
>> >>>>>
>> >>>> exactly the goal and user usage AFAIK ;)
>> >>>>
>> >>>> long story short: we learnt from the past errors and since always the
>> >>> same
>> >>>> people work on these projects it is better to not split it accross N
>> >>>> communities since
>> >>>> it leads to a lot of efforts for these people. Having a single
>> umbrella
>> >>>> project with N subprojects reduces the administrative work etc and
>> >>> enhance
>> >>>> the projects productivity.
>> >>>>
>> >>>>
>> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>> >>> rmannibucau@gmail.com <ma...@gmail.com>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi JL,
>> >>>>>>
>> >>>>>> Microprofile apache effort is hosted in geronimo and John already
>> >> spoke
>> >>>>>> about it I think. Would probably saner to keep it all at the same
>> >> place
>> >>>>> for
>> >>>>>> the foundation.
>> >>>>>>
>> >>>>>>
>> >>>>>> Romain Manni-Bucau
>> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> >>>>>> rmannibucau> |
>> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >>>>>> <https://www.packtpub.com/application-development/java-
>> >>>>>> ee-8-high-performance>
>> >>>>>>
>> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>> >>>>>> :
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> I was wondering if we could have the Microprofile JWT implemented
>> in
>> >>>>>> TomEE.
>> >>>>>>> What do you think?
>> >>>>>>>
>> >>>>>>> I was reading the spec and I'd like to contribute that in.
>> >>>>>>>
>> >>>>>>> Jean-Louis
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Jean-Louis Monteiro
>> >>>>>>> http://twitter.com/jlouismonteiro
>> >>>>>>> http://www.tomitribe.com
>> >>>>>>>
>> >>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>>
>> http://www.tomitribe.com
>>
>> https://www.tomitribe.io
>>
>>
>> Ubique
>>
>>
>>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique
>
>

Re: Implementing Microprofile JWT

[Andy Gumbrecht <ag...@tomitribe.com>]

Reverted.


On 12/02/18 21:14, Andy Gumbrecht wrote:
>
> "Parts of the components skeletons you just created"
>
> They're just logically named empty modules for pending work?
>
>
> On 12/02/18 20:42, Mark Struberg wrote:
>> And what's that for?
>>
>> Is there any behind the scene stuff going on at Tomitribe or can we 
>> finally get back to discussing such things on the Apache lists?
>>
>> Before we go on I'd would first finish the discussion how we want to 
>> turn TomEE into an umbrella project or how the structure would be. 
>> And whether/how we want to integrate the modular Geronimo parts into 
>> one project or not.
>>
>> Parts of the components skeletons you just created do already exist 
>> at the ASF.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
>> <ag...@tomitribe.com> wrote:
>>
>>
>> Added project stubs:
>> https://github.com/apache/tomee/tree/master/microprofile
>>
>> Andy.
>>
>>
>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>> > Hi,
>> >
>> > Ok thanks guys.
>> > @Rudy, you are most welcome :)
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
>> <rdebusscher@gmail.com <ma...@gmail.com>>
>> > wrote:
>> >
>> >> I think it is a very important spec, also for non-microprofile
>> >> implementations as it can enhance the interoperability of all servers.
>> >>
>> >> I'm also very interested in the implementation (and want to help a 
>> bit with
>> >> it also :) )
>> >>
>> >> regards
>> >> Rudy
>> >>
>> >>
>> >>
>> >> On 2 February 2018 at 11:23, Mark Struberg 
>> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>
>> >> wrote:
>> >>
>> >>> To clarify this even further:
>> >>> The Geronimo Server is now officially dead.
>> >>> But the Geronimo project is not. It alredy contains quite a few 
>> modular
>> >>> parts which are reused in many ASF projects and also outside.
>> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>> >>> geronimo-config, xbean-finder, etc
>> >>>
>> >>> Of course it would probably make sense to fold those 2 projects 
>> together,
>> >>> as already discussed in the past.
>> >>> I'm still all open to it, but I have an important criterium to 
>> fulfil:
>> >>> If we move those portable parts to TomEE, then this would mean 
>> that TomEE
>> >>> would become an 'Umbrella project'.
>> >>> And further that we would need a new name for those portable parts.
>> >>> They would effectively be mainatained by the TomEE community 
>> (which has a
>> >>> big overlap with Geronimo anyway) but those parts must clearly be
>> >>> recognized separately from TomEE.
>> >>>
>> >>> Otherwise people will assume that those parts only work within 
>> TomEE -
>> >>> where in reality they would even work on WildFly or Liberty, etc. or
>> >> even a
>> >>> naked Tomcat.
>> >>> Got me?
>> >>>
>> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts 
>> Department' :)
>> >>>
>> >>> LieGrue,
>> >>> strub
>> >>>
>> >>> PS: I'd also love to keep the org.apache.geronimo package name to 
>> ease
>> >>> backward compatibility.
>> >>>
>> >>>
>> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> >> rmannibucau@gmail.com <ma...@gmail.com>
>> >>>> :
>> >>>>
>> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
>> >>>>
>> >>>>> Guys, I have a question:
>> >>>>>
>> >>>>> Why not a project to each implementation?
>> >>>>>
>> >>>> this is the case but geronimo is used as an umbrella project.
>> >>>>
>> >>>>
>> >>>>> This way I can use just a specific if I want also.
>> >>>>>
>> >>>> exactly the goal and user usage AFAIK ;)
>> >>>>
>> >>>> long story short: we learnt from the past errors and since 
>> always the
>> >>> same
>> >>>> people work on these projects it is better to not split it accross N
>> >>>> communities since
>> >>>> it leads to a lot of efforts for these people. Having a single 
>> umbrella
>> >>>> project with N subprojects reduces the administrative work etc and
>> >>> enhance
>> >>>> the projects productivity.
>> >>>>
>> >>>>
>> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>> >>> rmannibucau@gmail.com <ma...@gmail.com>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi JL,
>> >>>>>>
>> >>>>>> Microprofile apache effort is hosted in geronimo and John already
>> >> spoke
>> >>>>>> about it I think. Would probably saner to keep it all at the same
>> >> place
>> >>>>> for
>> >>>>>> the foundation.
>> >>>>>>
>> >>>>>>
>> >>>>>> Romain Manni-Bucau
>> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> >>>>>> rmannibucau> |
>> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >>>>>> <https://www.packtpub.com/application-development/java-
>> >>>>>> ee-8-high-performance>
>> >>>>>>
>> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
>> >>>>>> :
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> I was wondering if we could have the Microprofile JWT 
>> implemented in
>> >>>>>> TomEE.
>> >>>>>>> What do you think?
>> >>>>>>>
>> >>>>>>> I was reading the spec and I'd like to contribute that in.
>> >>>>>>>
>> >>>>>>> Jean-Louis
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Jean-Louis Monteiro
>> >>>>>>> http://twitter.com/jlouismonteiro
>> >>>>>>> http://www.tomitribe.com
>> >>>>>>>
>> >>>
>>
>> -- 
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>>
>> http://www.tomitribe.com
>>
>> https://www.tomitribe.io
>>
>>
>> Ubique
>>
>>
>
> -- 
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Implementing Microprofile JWT

[Andy Gumbrecht <ag...@tomitribe.com>]

"Parts of the components skeletons you just created"

They're just logically named empty modules for pending work?


On 12/02/18 20:42, Mark Struberg wrote:
> And what's that for?
>
> Is there any behind the scene stuff going on at Tomitribe or can we 
> finally get back to discussing such things on the Apache lists?
>
> Before we go on I'd would first finish the discussion how we want to 
> turn TomEE into an umbrella project or how the structure would be. And 
> whether/how we want to integrate the modular Geronimo parts into one 
> project or not.
>
> Parts of the components skeletons you just created do already exist at 
> the ASF.
>
> LieGrue,
> strub
>
>
>
> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
> <ag...@tomitribe.com> wrote:
>
>
> Added project stubs:
> https://github.com/apache/tomee/tree/master/microprofile
>
> Andy.
>
>
> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> > Hi,
> >
> > Ok thanks guys.
> > @Rudy, you are most welcome :)
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
> <rdebusscher@gmail.com <ma...@gmail.com>>
> > wrote:
> >
> >> I think it is a very important spec, also for non-microprofile
> >> implementations as it can enhance the interoperability of all servers.
> >>
> >> I'm also very interested in the implementation (and want to help a 
> bit with
> >> it also :) )
> >>
> >> regards
> >> Rudy
> >>
> >>
> >>
> >> On 2 February 2018 at 11:23, Mark Struberg 
> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>
> >> wrote:
> >>
> >>> To clarify this even further:
> >>> The Geronimo Server is now officially dead.
> >>> But the Geronimo project is not. It alredy contains quite a few 
> modular
> >>> parts which are reused in many ASF projects and also outside.
> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >>> geronimo-config, xbean-finder, etc
> >>>
> >>> Of course it would probably make sense to fold those 2 projects 
> together,
> >>> as already discussed in the past.
> >>> I'm still all open to it, but I have an important criterium to fulfil:
> >>> If we move those portable parts to TomEE, then this would mean 
> that TomEE
> >>> would become an 'Umbrella project'.
> >>> And further that we would need a new name for those portable parts.
> >>> They would effectively be mainatained by the TomEE community 
> (which has a
> >>> big overlap with Geronimo anyway) but those parts must clearly be
> >>> recognized separately from TomEE.
> >>>
> >>> Otherwise people will assume that those parts only work within TomEE -
> >>> where in reality they would even work on WildFly or Liberty, etc. or
> >> even a
> >>> naked Tomcat.
> >>> Got me?
> >>>
> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>> PS: I'd also love to keep the org.apache.geronimo package name to ease
> >>> backward compatibility.
> >>>
> >>>
> >>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >> rmannibucau@gmail.com <ma...@gmail.com>
> >>>> :
> >>>>
> >>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>>> osantana@tomitribe.com <ma...@tomitribe.com>>:
> >>>>
> >>>>> Guys, I have a question:
> >>>>>
> >>>>> Why not a project to each implementation?
> >>>>>
> >>>> this is the case but geronimo is used as an umbrella project.
> >>>>
> >>>>
> >>>>> This way I can use just a specific if I want also.
> >>>>>
> >>>> exactly the goal and user usage AFAIK ;)
> >>>>
> >>>> long story short: we learnt from the past errors and since always the
> >>> same
> >>>> people work on these projects it is better to not split it accross N
> >>>> communities since
> >>>> it leads to a lot of efforts for these people. Having a single 
> umbrella
> >>>> project with N subprojects reduces the administrative work etc and
> >>> enhance
> >>>> the projects productivity.
> >>>>
> >>>>
> >>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com <ma...@gmail.com>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi JL,
> >>>>>>
> >>>>>> Microprofile apache effort is hosted in geronimo and John already
> >> spoke
> >>>>>> about it I think. Would probably saner to keep it all at the same
> >> place
> >>>>> for
> >>>>>> the foundation.
> >>>>>>
> >>>>>>
> >>>>>> Romain Manni-Bucau
> >>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >>>>>> rmannibucau> |
> >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>> <https://www.packtpub.com/application-development/java-
> >>>>>> ee-8-high-performance>
> >>>>>>
> >>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> >>> jlmonteiro@tomitribe.com <ma...@tomitribe.com>
> >>>>>> :
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> I was wondering if we could have the Microprofile JWT 
> implemented in
> >>>>>> TomEE.
> >>>>>>> What do you think?
> >>>>>>>
> >>>>>>> I was reading the spec and I'd like to contribute that in.
> >>>>>>>
> >>>>>>> Jean-Louis
> >>>>>>>
> >>>>>>> --
> >>>>>>> Jean-Louis Monteiro
> >>>>>>> http://twitter.com/jlouismonteiro
> >>>>>>> http://www.tomitribe.com
> >>>>>>>
> >>>
>
> -- 
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
>
> http://www.tomitribe.com
>
> https://www.tomitribe.io
>
>
> Ubique
>
>

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

And what's that for?
Is there any behind the scene stuff going on at Tomitribe or can we finally get back to discussing such things on the Apache lists?
Before we go on I'd would first finish the discussion how we want to turn TomEE into an umbrella project or how the structure would be. And whether/how we want to integrate the modular Geronimo parts into one project or not.
Parts of the components skeletons you just created do already exist at the ASF.
LieGrue,strub



    On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <ag...@tomitribe.com> wrote:  
 
 Added project stubs: 
https://github.com/apache/tomee/tree/master/microprofile

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <rd...@gmail.com>
> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a bit with
>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few modular
>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects together,
>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to fulfil:
>>> If we move those portable parts to TomEE, then this would mean that TomEE
>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community (which has a
>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within TomEE -
>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>> backward compatibility.
>>>
>>>
>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>> :
>>>>
>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>> osantana@tomitribe.com>:
>>>>
>>>>> Guys, I have a question:
>>>>>
>>>>> Why not a project to each implementation?
>>>>>
>>>> this is the case but geronimo is used as an umbrella project.
>>>>
>>>>
>>>>> This way I can use just a specific if I want also.
>>>>>
>>>> exactly the goal and user usage AFAIK ;)
>>>>
>>>> long story short: we learnt from the past errors and since always the
>>> same
>>>> people work on these projects it is better to not split it accross N
>>>> communities since
>>>> it leads to a lot of efforts for these people. Having a single umbrella
>>>> project with N subprojects reduces the administrative work etc and
>>> enhance
>>>> the projects productivity.
>>>>
>>>>
>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi JL,
>>>>>>
>>>>>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>>>>>> about it I think. Would probably saner to keep it all at the same
>> place
>>>>> for
>>>>>> the foundation.
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>> rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>> ee-8-high-performance>
>>>>>>
>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com
>>>>>> :
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I was wondering if we could have the Microprofile JWT implemented in
>>>>>> TomEE.
>>>>>>> What do you think?
>>>>>>>
>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>
>>>>>>> Jean-Louis
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Louis Monteiro
>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>> http://www.tomitribe.com
>>>>>>>
>>>

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

  

Re: Implementing Microprofile JWT

[Andy Gumbrecht <ag...@tomitribe.com>]

Added project stubs: 
https://github.com/apache/tomee/tree/master/microprofile

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <rd...@gmail.com>
> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a bit with
>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few modular
>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects together,
>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to fulfil:
>>> If we move those portable parts to TomEE, then this would mean that TomEE
>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community (which has a
>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within TomEE -
>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>> backward compatibility.
>>>
>>>
>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>> :
>>>>
>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>> osantana@tomitribe.com>:
>>>>
>>>>> Guys, I have a question:
>>>>>
>>>>> Why not a project to each implementation?
>>>>>
>>>> this is the case but geronimo is used as an umbrella project.
>>>>
>>>>
>>>>> This way I can use just a specific if I want also.
>>>>>
>>>> exactly the goal and user usage AFAIK ;)
>>>>
>>>> long story short: we learnt from the past errors and since always the
>>> same
>>>> people work on these projects it is better to not split it accross N
>>>> communities since
>>>> it leads to a lot of efforts for these people. Having a single umbrella
>>>> project with N subprojects reduces the administrative work etc and
>>> enhance
>>>> the projects productivity.
>>>>
>>>>
>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi JL,
>>>>>>
>>>>>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>>>>>> about it I think. Would probably saner to keep it all at the same
>> place
>>>>> for
>>>>>> the foundation.
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>> rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <https://www.packtpub.com/application-development/java-
>>>>>> ee-8-high-performance>
>>>>>>
>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com
>>>>>> :
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I was wondering if we could have the Microprofile JWT implemented in
>>>>>> TomEE.
>>>>>>> What do you think?
>>>>>>>
>>>>>>> I was reading the spec and I'd like to contribute that in.
>>>>>>>
>>>>>>> Jean-Louis
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Louis Monteiro
>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>> http://www.tomitribe.com
>>>>>>>
>>>

-- 
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro <jl...@tomitribe.com>]

Hi,

Ok thanks guys.
@Rudy, you are most welcome :)

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <rd...@gmail.com>
wrote:

> I think it is a very important spec, also for non-microprofile
> implementations as it can enhance the interoperability of all servers.
>
> I'm also very interested in the implementation (and want to help a bit with
> it also :) )
>
> regards
> Rudy
>
>
>
> On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
> > To clarify this even further:
> > The Geronimo Server is now officially dead.
> > But the Geronimo project is not. It alredy contains quite a few modular
> > parts which are reused in many ASF projects and also outside.
> > Examples is the geronimo-transaction-manager, geronimo-javamail,
> > geronimo-config, xbean-finder, etc
> >
> > Of course it would probably make sense to fold those 2 projects together,
> > as already discussed in the past.
> > I'm still all open to it, but I have an important criterium to fulfil:
> > If we move those portable parts to TomEE, then this would mean that TomEE
> > would become an 'Umbrella project'.
> > And further that we would need a new name for those portable parts.
> > They would effectively be mainatained by the TomEE community (which has a
> > big overlap with Geronimo anyway) but those parts must clearly be
> > recognized separately from TomEE.
> >
> > Otherwise people will assume that those parts only work within TomEE -
> > where in reality they would even work on WildFly or Liberty, etc. or
> even a
> > naked Tomcat.
> > Got me?
> >
> > We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
> >
> > LieGrue,
> > strub
> >
> > PS: I'd also love to keep the org.apache.geronimo package name to ease
> > backward compatibility.
> >
> >
> > > Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > >
> > > 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > > osantana@tomitribe.com>:
> > >
> > >> Guys, I have a question:
> > >>
> > >> Why not a project to each implementation?
> > >>
> > >
> > > this is the case but geronimo is used as an umbrella project.
> > >
> > >
> > >> This way I can use just a specific if I want also.
> > >>
> > >
> > > exactly the goal and user usage AFAIK ;)
> > >
> > > long story short: we learnt from the past errors and since always the
> > same
> > > people work on these projects it is better to not split it accross N
> > > communities since
> > > it leads to a lot of efforts for these people. Having a single umbrella
> > > project with N subprojects reduces the administrative work etc and
> > enhance
> > > the projects productivity.
> > >
> > >
> > >> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi JL,
> > >>>
> > >>> Microprofile apache effort is hosted in geronimo and John already
> spoke
> > >>> about it I think. Would probably saner to keep it all at the same
> place
> > >> for
> > >>> the foundation.
> > >>>
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > >>> rmannibucau> |
> > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >>> <https://www.packtpub.com/application-development/java-
> > >>> ee-8-high-performance>
> > >>>
> > >>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com
> > >>> :
> > >>>
> > >>>> Hi all,
> > >>>>
> > >>>> I was wondering if we could have the Microprofile JWT implemented in
> > >>> TomEE.
> > >>>> What do you think?
> > >>>>
> > >>>> I was reading the spec and I'd like to contribute that in.
> > >>>>
> > >>>> Jean-Louis
> > >>>>
> > >>>> --
> > >>>> Jean-Louis Monteiro
> > >>>> http://twitter.com/jlouismonteiro
> > >>>> http://www.tomitribe.com
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: Implementing Microprofile JWT

[Rudy De Busscher <rd...@gmail.com>]

I think it is a very important spec, also for non-microprofile
implementations as it can enhance the interoperability of all servers.

I'm also very interested in the implementation (and want to help a bit with
it also :) )

regards
Rudy



On 2 February 2018 at 11:23, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> To clarify this even further:
> The Geronimo Server is now officially dead.
> But the Geronimo project is not. It alredy contains quite a few modular
> parts which are reused in many ASF projects and also outside.
> Examples is the geronimo-transaction-manager, geronimo-javamail,
> geronimo-config, xbean-finder, etc
>
> Of course it would probably make sense to fold those 2 projects together,
> as already discussed in the past.
> I'm still all open to it, but I have an important criterium to fulfil:
> If we move those portable parts to TomEE, then this would mean that TomEE
> would become an 'Umbrella project'.
> And further that we would need a new name for those portable parts.
> They would effectively be mainatained by the TomEE community (which has a
> big overlap with Geronimo anyway) but those parts must clearly be
> recognized separately from TomEE.
>
> Otherwise people will assume that those parts only work within TomEE -
> where in reality they would even work on WildFly or Liberty, etc. or even a
> naked Tomcat.
> Got me?
>
> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>
> LieGrue,
> strub
>
> PS: I'd also love to keep the org.apache.geronimo package name to ease
> backward compatibility.
>
>
> > Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> > osantana@tomitribe.com>:
> >
> >> Guys, I have a question:
> >>
> >> Why not a project to each implementation?
> >>
> >
> > this is the case but geronimo is used as an umbrella project.
> >
> >
> >> This way I can use just a specific if I want also.
> >>
> >
> > exactly the goal and user usage AFAIK ;)
> >
> > long story short: we learnt from the past errors and since always the
> same
> > people work on these projects it is better to not split it accross N
> > communities since
> > it leads to a lot of efforts for these people. Having a single umbrella
> > project with N subprojects reduces the administrative work etc and
> enhance
> > the projects productivity.
> >
> >
> >> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> wrote:
> >>
> >>> Hi JL,
> >>>
> >>> Microprofile apache effort is hosted in geronimo and John already spoke
> >>> about it I think. Would probably saner to keep it all at the same place
> >> for
> >>> the foundation.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >>> rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>> <https://www.packtpub.com/application-development/java-
> >>> ee-8-high-performance>
> >>>
> >>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com
> >>> :
> >>>
> >>>> Hi all,
> >>>>
> >>>> I was wondering if we could have the Microprofile JWT implemented in
> >>> TomEE.
> >>>> What do you think?
> >>>>
> >>>> I was reading the spec and I'd like to contribute that in.
> >>>>
> >>>> Jean-Louis
> >>>>
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>
> >>
>
>

Re: Implementing Microprofile JWT

[Mark Struberg <st...@yahoo.de.INVALID>]

To clarify this even further: 
The Geronimo Server is now officially dead. 
But the Geronimo project is not. It alredy contains quite a few modular parts which are reused in many ASF projects and also outside.
Examples is the geronimo-transaction-manager, geronimo-javamail, geronimo-config, xbean-finder, etc

Of course it would probably make sense to fold those 2 projects together, as already discussed in the past.
I'm still all open to it, but I have an important criterium to fulfil: 
If we move those portable parts to TomEE, then this would mean that TomEE would become an 'Umbrella project'.
And further that we would need a new name for those portable parts. 
They would effectively be mainatained by the TomEE community (which has a big overlap with Geronimo anyway) but those parts must clearly be recognized separately from TomEE.

Otherwise people will assume that those parts only work within TomEE - where in reality they would even work on WildFly or Liberty, etc. or even a naked Tomcat.
Got me?

We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :) 

LieGrue,
strub

PS: I'd also love to keep the org.apache.geronimo package name to ease backward compatibility.


> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> 
> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> osantana@tomitribe.com>:
> 
>> Guys, I have a question:
>> 
>> Why not a project to each implementation?
>> 
> 
> this is the case but geronimo is used as an umbrella project.
> 
> 
>> This way I can use just a specific if I want also.
>> 
> 
> exactly the goal and user usage AFAIK ;)
> 
> long story short: we learnt from the past errors and since always the same
> people work on these projects it is better to not split it accross N
> communities since
> it leads to a lot of efforts for these people. Having a single umbrella
> project with N subprojects reduces the administrative work etc and enhance
> the projects productivity.
> 
> 
>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>> 
>>> Hi JL,
>>> 
>>> Microprofile apache effort is hosted in geronimo and John already spoke
>>> about it I think. Would probably saner to keep it all at the same place
>> for
>>> the foundation.
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>> rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <https://www.packtpub.com/application-development/java-
>>> ee-8-high-performance>
>>> 
>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com
>>> :
>>> 
>>>> Hi all,
>>>> 
>>>> I was wondering if we could have the Microprofile JWT implemented in
>>> TomEE.
>>>> What do you think?
>>>> 
>>>> I was reading the spec and I'd like to contribute that in.
>>>> 
>>>> Jean-Louis
>>>> 
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>> 
>>> 
>> 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
osantana@tomitribe.com>:

> Guys, I have a question:
>
> Why not a project to each implementation?
>

this is the case but geronimo is used as an umbrella project.


> This way I can use just a specific if I want also.
>

exactly the goal and user usage AFAIK ;)

long story short: we learnt from the past errors and since always the same
people work on these projects it is better to not split it accross N
communities since
it leads to a lot of efforts for these people. Having a single umbrella
project with N subprojects reduces the administrative work etc and enhance
the projects productivity.


> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi JL,
> >
> > Microprofile apache effort is hosted in geronimo and John already spoke
> > about it I think. Would probably saner to keep it all at the same place
> for
> > the foundation.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
> > 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com
> >:
> >
> > > Hi all,
> > >
> > > I was wondering if we could have the Microprofile JWT implemented in
> > TomEE.
> > > What do you think?
> > >
> > > I was reading the spec and I'd like to contribute that in.
> > >
> > > Jean-Louis
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> >
>

Re: Implementing Microprofile JWT

[Otávio Gonçalves de Santana <os...@tomitribe.com>]

Guys, I have a question:

Why not a project to each implementation?
This way I can use just a specific if I want also.

On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Hi JL,
>
> Microprofile apache effort is hosted in geronimo and John already spoke
> about it I think. Would probably saner to keep it all at the same place for
> the foundation.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
>
> > Hi all,
> >
> > I was wondering if we could have the Microprofile JWT implemented in
> TomEE.
> > What do you think?
> >
> > I was reading the spec and I'd like to contribute that in.
> >
> > Jean-Louis
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
>

Re: Implementing Microprofile JWT

[Romain Manni-Bucau <rm...@gmail.com>]

Hi JL,

Microprofile apache effort is hosted in geronimo and John already spoke
about it I think. Would probably saner to keep it all at the same place for
the foundation.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <jl...@tomitribe.com>:

> Hi all,
>
> I was wondering if we could have the Microprofile JWT implemented in TomEE.
> What do you think?
>
> I was reading the spec and I'd like to contribute that in.
>
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>