You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2018/03/19 00:02:55 UTC
[VOTE] Explore creating a reusable JWT Library
The vote for merging PR 123 does not address community will on what to do with the code beyond merging it. One can realistically vote +1 to merge the code, but then desire to see the code cleaned up and moved elsewhere. One can realistically desire seeing an attempt to clean up the code to find what is reusable and may wish to withhold a final decision until we see how fruitful such a module would be.
Out of respect for people who may not know exactly how they feel (TomEE or Geronimo), this is a vote for the latter.
Vote: Should we attempt to extract code from the JWT PR to see what is reusable and how successful such a jar would be?
+1 Let's give it a shot here
+-0
-1 Let's do this elsewhere
If the vote is +1 to attempt an extraction of reusable code here, final conclusion of if that extraction is worth it or where it should live is not being voted on. People are welcome to decide differently based on the results of the exercise.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
I don't think you have answered my question. You specifically said: "I will
make sure to help to make it releasable." If this code is moved to a blank
repository, irrespective of what is the TLP for that repo, what actions
were you going to take to "make it releasable"?
Jon
On Wed, Mar 28, 2018 at 9:21 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 2018-03-28 10:17 GMT+02:00 Jonathan Gallimore <
> jonathan.gallimore@gmail.com>
> :
>
> > On Wed, Mar 28, 2018 at 6:13 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > Roberto PR *is* merged JL.
> > > He did the work to be able to consume any CDI "container" lib.
> > >
> > > So I'd just extract the code as we discussed together in G before that
> > mess
> > > and move forward to keep TCK and add the lib in the MP distro Roberto
> > > created to fit that design.
> > >
> > > As soon as you imported the lib in G, I will make sure to help to make
> it
> > > releasable.
> > >
> >
> > What does that mean? What are the changes you're proposing, and why can't
> > Jean-Louis do them?
> >
>
> Just move the "main" code to the repo created @G and import the new lib in
> tomee MP as Roberto did for config. Nothing blocking JL to do them at all.
>
>
> >
> > Jon
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 29, 2018, at 3:03 PM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>
> i would like JWT support but it has to be done right. is the plan to place it as a sub project under the TomEE umbrella? is the project going to have a future as an independent module which can be reused in G etc?
Current status is there's a PR with 19 new classes in it that aren't already in TomEE. They could potentially be reusable outside of TomEE. The code could potentially be less classes if refined. The discussion is where should that exploration be done. I think it'd also be pragmatic to evaluate how much overhead 19 classes are worth; it's own jar, it's own git repo. Those are open questions.
The statement being made is that this code shouldn't live in TomEE as a library or module or separate git repo where it could be mistaken as being a component that doesn't work outside of an app server and instead should be in Geronimo and called geronimo-mp-jwt to avoid that misunderstanding. In terms of being reused in Geronimo, there's no server there anymore to reuse the code and the project is a bit of an abandoned building. Of the 66 people that have commit, only 3 are active. The statement being made that Geronimo as a project, not as a server, could hold all reusable app server components for all of the ASF and code from TomEE should be moved to Geronimo to help achieve that vision.
One could argue that moving the code from an alive app server to a dead app server doesn't achieve the main objective of avoiding perception that code is not reusable.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
I agree, and I don't think that is quite decided yet. I'm fairly agnostic
on the "where", but I don't think it should stay in a PR.
It's early days, and it could potentially move at different points in the
future. TomEE has changed a fair bit since my first contribution in 2007 :).
I think we need to make sure we're enabling everyone to keep working and
collaborating.
Jon
On Thu, 29 Mar 2018, 23:03 Matthew Broadhead, <
matthew.broadhead@nbmlaw.co.uk> wrote:
> i would like JWT support but it has to be done right. is the plan to
> place it as a sub project under the TomEE umbrella? is the project
> going to have a future as an independent module which can be reused in G
> etc?
>
> On 29/03/2018 23:18, Jonathan Gallimore wrote:
> > I suspect some of this is aimed at me. I'd be fine to send PRs and earn
> > committer status through meritocracy. To be clear, I'm not blocking this
> > being merged in TomEE or Geronimo. Your -1 vetoes it being merged into
> > TomEE.
> >
> > I appreciate your reply to my question about the changes you'd like to
> the
> > JWT work. They sound like good suggestions, and as long as there is open
> > discussion and collaboration on the appropriate list, I'm ok with it. I
> > don't think they should block a merge as work can continue after the
> merge.
> >
> > Your comment "As soon as you imported the lib in G, I will make sure to
> > help to make it
> > releasable.", coupled with me asking twice what that meant, sounded like
> > it was going to be immediately changed and released potentially without
> > much discussion as soon as it lands in Geronimo.
> >
> > I'm not committer on Geronimo - if I implemented part of MP and it winds
> up
> > there, my hope is that the Geronimo community would help and enable me to
> > contribute further and ultimately become a committee, just as OpenEJB did
> > 10 years ago.
> >
> > So just to be clear, I'm not blocking / vetoing anything, and I encourage
> > this to be merged somewhere and open collaboration to continue wherever
> it
> > ends up.
> >
> > Jon
> >
> >
> > On Thu, 29 Mar 2018, 21:49 Romain Manni-Bucau, <rm...@gmail.com>
> > wrote:
> >
> >> Globally that is it. You explained a lot why geronimo failed and not
> sure
> >> why tomee is kind of taking the same path - well actually cause of
> "perms
> >> lack" fear from what I read. This is not a safe reason (+not that
> relevant
> >> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite
> as
> >> we have been 7 years ago instead of just going on different paths cause
> of
> >> a fears.
> >>
> >>
> >>
> >> Le 29 mars 2018 21:57, "David Blevins" <da...@gmail.com> a
> écrit :
> >>
> >>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> wrote:
> >>> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a
> >> écrit :
> >>>
> >>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >>> wrote:
> >>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
> >>> wrote:
> >>>>> Is your -1 on the basis that the code must be moved to Geronimo?
> >>>> That + the fact tomee is not and shouldnt become a put it all project
> >> just
> >>>> become of scm perms IMO but stay an integration project to keep sense
> >> and
> >>>> not mess up its own image and mess up the quality of our reusable
> libs.
> >>>> Do you see this as a one-time situation or do you intend to vote the
> >> same
> >>>> way on any future MicroProfile implementation work in TomEE?
> >>>>
> >>>> For example, should work be started to implement MicroProfile
> >> OpenTracing
> >>>> in TomEE, would that PR be -1 on the basis the implementation should
> be
> >> in
> >>>> Geronimo?
> >>> Being said it will be in G anyway since that is half of G definition
> >> since
> >>> some months now (since server has been dropped), I ll do my best to
> keep
> >> it
> >>> consistent in our small ecosystem and do the same to have strong
> reusable
> >>> libs since there is no technical blockers @MP to have it and a strong
> >>> integration solution (tomee) and not a mess with an in between state.
> >> I'm reading that as a yes that you would -1 future MP implementation
> work
> >> in TomEE on the basis it should live in Geronimo, but you hope it
> doesn't
> >> come to that and will do your best to create good implementations in
> >> Geronimo so it isn't necessary.
> >>
> >> If I misunderstood, please clarify.
> >>
> >>
> >> -David
> >>
> >>
>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
i would like JWT support but it has to be done right. is the plan to
place it as a sub project under the TomEE umbrella? is the project
going to have a future as an independent module which can be reused in G
etc?
On 29/03/2018 23:18, Jonathan Gallimore wrote:
> I suspect some of this is aimed at me. I'd be fine to send PRs and earn
> committer status through meritocracy. To be clear, I'm not blocking this
> being merged in TomEE or Geronimo. Your -1 vetoes it being merged into
> TomEE.
>
> I appreciate your reply to my question about the changes you'd like to the
> JWT work. They sound like good suggestions, and as long as there is open
> discussion and collaboration on the appropriate list, I'm ok with it. I
> don't think they should block a merge as work can continue after the merge.
>
> Your comment "As soon as you imported the lib in G, I will make sure to
> help to make it
> releasable.", coupled with me asking twice what that meant, sounded like
> it was going to be immediately changed and released potentially without
> much discussion as soon as it lands in Geronimo.
>
> I'm not committer on Geronimo - if I implemented part of MP and it winds up
> there, my hope is that the Geronimo community would help and enable me to
> contribute further and ultimately become a committee, just as OpenEJB did
> 10 years ago.
>
> So just to be clear, I'm not blocking / vetoing anything, and I encourage
> this to be merged somewhere and open collaboration to continue wherever it
> ends up.
>
> Jon
>
>
> On Thu, 29 Mar 2018, 21:49 Romain Manni-Bucau, <rm...@gmail.com>
> wrote:
>
>> Globally that is it. You explained a lot why geronimo failed and not sure
>> why tomee is kind of taking the same path - well actually cause of "perms
>> lack" fear from what I read. This is not a safe reason (+not that relevant
>> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
>> we have been 7 years ago instead of just going on different paths cause of
>> a fears.
>>
>>
>>
>> Le 29 mars 2018 21:57, "David Blevins" <da...@gmail.com> a écrit :
>>
>>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a
>> écrit :
>>>
>>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
>>> wrote:
>>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>> That + the fact tomee is not and shouldnt become a put it all project
>> just
>>>> become of scm perms IMO but stay an integration project to keep sense
>> and
>>>> not mess up its own image and mess up the quality of our reusable libs.
>>>> Do you see this as a one-time situation or do you intend to vote the
>> same
>>>> way on any future MicroProfile implementation work in TomEE?
>>>>
>>>> For example, should work be started to implement MicroProfile
>> OpenTracing
>>>> in TomEE, would that PR be -1 on the basis the implementation should be
>> in
>>>> Geronimo?
>>> Being said it will be in G anyway since that is half of G definition
>> since
>>> some months now (since server has been dropped), I ll do my best to keep
>> it
>>> consistent in our small ecosystem and do the same to have strong reusable
>>> libs since there is no technical blockers @MP to have it and a strong
>>> integration solution (tomee) and not a mess with an in between state.
>> I'm reading that as a yes that you would -1 future MP implementation work
>> in TomEE on the basis it should live in Geronimo, but you hope it doesn't
>> come to that and will do your best to create good implementations in
>> Geronimo so it isn't necessary.
>>
>> If I misunderstood, please clarify.
>>
>>
>> -David
>>
>>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
I suspect some of this is aimed at me. I'd be fine to send PRs and earn
committer status through meritocracy. To be clear, I'm not blocking this
being merged in TomEE or Geronimo. Your -1 vetoes it being merged into
TomEE.
I appreciate your reply to my question about the changes you'd like to the
JWT work. They sound like good suggestions, and as long as there is open
discussion and collaboration on the appropriate list, I'm ok with it. I
don't think they should block a merge as work can continue after the merge.
Your comment "As soon as you imported the lib in G, I will make sure to
help to make it
releasable.", coupled with me asking twice what that meant, sounded like
it was going to be immediately changed and released potentially without
much discussion as soon as it lands in Geronimo.
I'm not committer on Geronimo - if I implemented part of MP and it winds up
there, my hope is that the Geronimo community would help and enable me to
contribute further and ultimately become a committee, just as OpenEJB did
10 years ago.
So just to be clear, I'm not blocking / vetoing anything, and I encourage
this to be merged somewhere and open collaboration to continue wherever it
ends up.
Jon
On Thu, 29 Mar 2018, 21:49 Romain Manni-Bucau, <rm...@gmail.com>
wrote:
> Globally that is it. You explained a lot why geronimo failed and not sure
> why tomee is kind of taking the same path - well actually cause of "perms
> lack" fear from what I read. This is not a safe reason (+not that relevant
> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
> we have been 7 years ago instead of just going on different paths cause of
> a fears.
>
>
>
> Le 29 mars 2018 21:57, "David Blevins" <da...@gmail.com> a écrit :
>
> > On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a
> écrit :
> >
> >
> >> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >>
> >>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
> > wrote:
> >>> Is your -1 on the basis that the code must be moved to Geronimo?
> >>
> >> That + the fact tomee is not and shouldnt become a put it all project
> just
> >> become of scm perms IMO but stay an integration project to keep sense
> and
> >> not mess up its own image and mess up the quality of our reusable libs.
> >
> > > Do you see this as a one-time situation or do you intend to vote the
> same
> > > way on any future MicroProfile implementation work in TomEE?
> > >
> > > For example, should work be started to implement MicroProfile
> OpenTracing
> > > in TomEE, would that PR be -1 on the basis the implementation should be
> in
> > > Geronimo?
> >
> > Being said it will be in G anyway since that is half of G definition
> since
> > some months now (since server has been dropped), I ll do my best to keep
> it
> > consistent in our small ecosystem and do the same to have strong reusable
> > libs since there is no technical blockers @MP to have it and a strong
> > integration solution (tomee) and not a mess with an in between state.
>
> I'm reading that as a yes that you would -1 future MP implementation work
> in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> come to that and will do your best to create good implementations in
> Geronimo so it isn't necessary.
>
> If I misunderstood, please clarify.
>
>
> -David
>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Globally that is it. You explained a lot why geronimo failed and not sure
why tomee is kind of taking the same path - well actually cause of "perms
lack" fear from what I read. This is not a safe reason (+not that relevant
@asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
we have been 7 years ago instead of just going on different paths cause of
a fears.
Le 29 mars 2018 21:57, "David Blevins" <da...@gmail.com> a écrit :
> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit :
>
>
>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
> wrote:
>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>
>> That + the fact tomee is not and shouldnt become a put it all project
just
>> become of scm perms IMO but stay an integration project to keep sense and
>> not mess up its own image and mess up the quality of our reusable libs.
>
> > Do you see this as a one-time situation or do you intend to vote the
same
> > way on any future MicroProfile implementation work in TomEE?
> >
> > For example, should work be started to implement MicroProfile
OpenTracing
> > in TomEE, would that PR be -1 on the basis the implementation should be
in
> > Geronimo?
>
> Being said it will be in G anyway since that is half of G definition since
> some months now (since server has been dropped), I ll do my best to keep
it
> consistent in our small ecosystem and do the same to have strong reusable
> libs since there is no technical blockers @MP to have it and a strong
> integration solution (tomee) and not a mess with an in between state.
I'm reading that as a yes that you would -1 future MP implementation work
in TomEE on the basis it should live in Geronimo, but you hope it doesn't
come to that and will do your best to create good implementations in
Geronimo so it isn't necessary.
If I misunderstood, please clarify.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-03-30 7:24 GMT+02:00 Jonathan Gallimore <jo...@gmail.com>:
> On Fri, 30 Mar 2018, 06:06 Romain Manni-Bucau, <rm...@gmail.com>
> wrote:
>
> > Le 30 mars 2018 04:30, "David Blevins" <da...@gmail.com> a
> écrit :
> >
> >
> > > On Mar 29, 2018, at 12:57 PM, David Blevins <da...@gmail.com>
> > wrote:
> > >
> > >> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> > >>
> > >> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a
> > écrit
> > :
> > >>
> > >>
> > >>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>>> On Mar 28, 2018, at 6:29 PM, David Blevins <david.blevins@gmail.com
> >
> > >> wrote:
> > >>>> Is your -1 on the basis that the code must be moved to Geronimo?
> > >>>
> > >>> That + the fact tomee is not and shouldnt become a put it all project
> > just
> > >>> become of scm perms IMO but stay an integration project to keep sense
> > and
> > >>> not mess up its own image and mess up the quality of our reusable
> libs.
> > >>
> > >>> Do you see this as a one-time situation or do you intend to vote the
> > same
> > >>> way on any future MicroProfile implementation work in TomEE?
> > >>>
> > >>> For example, should work be started to implement MicroProfile
> > OpenTracing
> > >>> in TomEE, would that PR be -1 on the basis the implementation should
> be
> > in
> > >>> Geronimo?
> > >>
> > >> Being said it will be in G anyway since that is half of G definition
> > since
> > >> some months now (since server has been dropped), I ll do my best to
> keep
> > it
> > >> consistent in our small ecosystem and do the same to have strong
> > reusable
> > >> libs since there is no technical blockers @MP to have it and a strong
> > >> integration solution (tomee) and not a mess with an in between state.
> > >
> > > I'm reading that as a yes that you would -1 future MP implementation
> work
> > in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> > come to that and will do your best to create good implementations in
> > Geronimo so it isn't necessary.
> > >
> > > If I misunderstood, please clarify.
> >
> > > On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> > >
> > > Globally that is it. You explained a lot why geronimo failed and not
> sure
> > > why tomee is kind of taking the same path - well actually cause of
> "perms
> > > lack" fear from what I read. This is not a safe reason (+not that
> > relevant
> > > @asf thanks to the meritocracy) and Id prefer to keep "us" being unite
> as
> > > we have been 7 years ago instead of just going on different paths cause
> > of
> > > a fears.
> >
> > I think we should openly discuss your perspective and how it might be
> > perceived by the project. There are 11 +1 votes, 5 of them binding. It
> > does appear that overall the project would like to move forward with the
> > code. You -1 the code on the basis that it should go to Geronimo instead
> > with the clear statement you will continue to -1 so on future
> MicroProfile
> > code. Can you see how this creates a situation where 11 people feel they
> > have no ability to contribute to the project now or in the future? Do
> you
> > feel this is the spirit of the Apache Way and represents community over
> > code?
> >
> >
> > More than never but I just dont ignore other projects. I understand most
> of
> > voting people are not involved in G and therefore I can see where they
> come
> > from (and no Jon, this was not directed to you in particular).
> >
> > The main difference is Im thinking of communities and not community.
> >
> > You are also plain wrong saying there is no way to contribute, there are
> > plenty as on any asf projects and for most people it will be the exact
> > same.
> >
>
> Is that what was said?
>
Was my understanding of "people feel they have no ability to contribute to
the project now or in the future"
>
>
> > Project is created @G, if T duplicates it what does happen? We get an
> half
> > baked flavor on one side and another one on the other? Do you think it is
> > the right thing for asf David? Do you want to split communities? Do you
> > want to make of TomEE a put it all project which means getting rid of
> TomEE
> > as a thing?
> >
> >
> > Im really fed up to be always felt as the bad guy but I also know it is
> > wrong and will fail. Short terms it will fake some activity on the
> project
> > (is it the goal?) Which can be good, long terms it will kill all the good
> > of TomEE AND our libraries as mentionned earlier.
> >
> > If you want to pass it in force you can but please remove me from the pmc
> > before.
> >
>
> I very much would not want that.
>
Me neither (both parts of the sentence) but can be needed seeing current
state and I don't think I'll accept anytime soon the fact that a community
ignores (to not say rejects) another one
which is kind of what happens here.
>
> Jon
>
>
> >
> >
> >
> > -David
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Fri, 30 Mar 2018, 06:06 Romain Manni-Bucau, <rm...@gmail.com>
wrote:
> Le 30 mars 2018 04:30, "David Blevins" <da...@gmail.com> a écrit :
>
>
> > On Mar 29, 2018, at 12:57 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> >> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
> >>
> >> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a
> écrit
> :
> >>
> >>
> >>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> >> wrote:
> >>>
> >>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
> >> wrote:
> >>>> Is your -1 on the basis that the code must be moved to Geronimo?
> >>>
> >>> That + the fact tomee is not and shouldnt become a put it all project
> just
> >>> become of scm perms IMO but stay an integration project to keep sense
> and
> >>> not mess up its own image and mess up the quality of our reusable libs.
> >>
> >>> Do you see this as a one-time situation or do you intend to vote the
> same
> >>> way on any future MicroProfile implementation work in TomEE?
> >>>
> >>> For example, should work be started to implement MicroProfile
> OpenTracing
> >>> in TomEE, would that PR be -1 on the basis the implementation should be
> in
> >>> Geronimo?
> >>
> >> Being said it will be in G anyway since that is half of G definition
> since
> >> some months now (since server has been dropped), I ll do my best to keep
> it
> >> consistent in our small ecosystem and do the same to have strong
> reusable
> >> libs since there is no technical blockers @MP to have it and a strong
> >> integration solution (tomee) and not a mess with an in between state.
> >
> > I'm reading that as a yes that you would -1 future MP implementation work
> in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> come to that and will do your best to create good implementations in
> Geronimo so it isn't necessary.
> >
> > If I misunderstood, please clarify.
>
> > On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Globally that is it. You explained a lot why geronimo failed and not sure
> > why tomee is kind of taking the same path - well actually cause of "perms
> > lack" fear from what I read. This is not a safe reason (+not that
> relevant
> > @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
> > we have been 7 years ago instead of just going on different paths cause
> of
> > a fears.
>
> I think we should openly discuss your perspective and how it might be
> perceived by the project. There are 11 +1 votes, 5 of them binding. It
> does appear that overall the project would like to move forward with the
> code. You -1 the code on the basis that it should go to Geronimo instead
> with the clear statement you will continue to -1 so on future MicroProfile
> code. Can you see how this creates a situation where 11 people feel they
> have no ability to contribute to the project now or in the future? Do you
> feel this is the spirit of the Apache Way and represents community over
> code?
>
>
> More than never but I just dont ignore other projects. I understand most of
> voting people are not involved in G and therefore I can see where they come
> from (and no Jon, this was not directed to you in particular).
>
> The main difference is Im thinking of communities and not community.
>
> You are also plain wrong saying there is no way to contribute, there are
> plenty as on any asf projects and for most people it will be the exact
> same.
>
Is that what was said?
> Project is created @G, if T duplicates it what does happen? We get an half
> baked flavor on one side and another one on the other? Do you think it is
> the right thing for asf David? Do you want to split communities? Do you
> want to make of TomEE a put it all project which means getting rid of TomEE
> as a thing?
>
>
> Im really fed up to be always felt as the bad guy but I also know it is
> wrong and will fail. Short terms it will fake some activity on the project
> (is it the goal?) Which can be good, long terms it will kill all the good
> of TomEE AND our libraries as mentionned earlier.
>
> If you want to pass it in force you can but please remive me from the pmc
> before.
>
I very much would not want that.
Jon
>
>
>
> -David
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
CXF doesn't do that AFAIK and fully relies on the JVM API, Tomcat has some
code (
https://github.com/apache/tomcat/blob/trunk/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java)
but it is not much reusable so having a kind of commons-keys (bouncycastle
@asf to not hide it ;)).
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-05-02 10:28 GMT+02:00 Matthew Broadhead <matthew.broadhead@nbmlaw.co.uk
>:
> aren't there apache projects already dealing with public key formats? cxf
> must have done a lot of work on that? would this just be a wrapper to
> existing libs?
>
>
>
> On 02/05/18 10:03, Jean-Louis Monteiro wrote:
>
>> PCS8 "standard" or not is probably the one to no miss
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> On Wed, May 2, 2018 at 6:27 AM, Rudy De Busscher <rd...@gmail.com>
>> wrote:
>>
>> Primarily what I'd like to do is really nail the public key format
>>>> manipulation. I did a huge amount of research in this and would like to
>>>> come up with an extremely well tested library that can natively read all
>>>> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line
>>>>
>>> tools
>>>
>>>> for converting between them.
>>>>
>>>
>>> That would be super awesome. I have been working on the same thing the
>>> past
>>> month or so.
>>>
>>> Rudy
>>>
>>> On 2 May 2018 at 00:13, David Blevins <da...@gmail.com> wrote:
>>>
>>> Requested a repo we could potentially use for this.
>>>>
>>>> Primarily what I'd like to do is really nail the public key format
>>>> manipulation. I did a huge amount of research in this and would like to
>>>> come up with an extremely well tested library that can natively read all
>>>> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line
>>>>
>>> tools
>>>
>>>> for converting between them.
>>>>
>>>> This could be useful to both the TomEE and Geronimo MicroProfile JWT
>>>>
>>> impls.
>>>
>>>>
>>>> --
>>>> David Blevins
>>>> http://twitter.com/dblevins
>>>> http://www.tomitribe.com
>>>>
>>>> On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro <
>>>>>
>>>> jlmonteiro@tomitribe.com> wrote:
>>>>
>>>>> The code still is in a PR (#123) for the moment
>>>>>
>>>>> I'm in to help.
>>>>> Still some small fixes to do and I'd like MP-Config to be used to
>>>>>
>>>> configure
>>>>
>>>>> keys, issues, and others.
>>>>>
>>>>> --
>>>>> Jean-Louis Monteiro
>>>>> http://twitter.com/jlouismonteiro
>>>>> http://www.tomitribe.com
>>>>>
>>>>> On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg
>>>>>
>>>> <struberg@yahoo.de.invalid
>>>
>>>> wrote:
>>>>>
>>>>> As noted elsewhere: the vote question was a mixture of 'what do you
>>>>>> think' (consensus -> majority vote) and 'is it ok' (technical ->
>>>>>>
>>>>> unanimous
>>>>
>>>>> vote).
>>>>>> I'd also be in favour to do the generic parts in Geronimo and only do
>>>>>>
>>>>> the
>>>>
>>>>> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If
>>>>>>
>>>>> this
>>>>
>>>>> is interpreted as commit vote then I vote -0
>>>>>> The work is the same and as long as it's been done I'm fine either
>>>>>>
>>>>> ways.
>>>
>>>> Now that we did all the 3 weeks of rambling and discussions let's
>>>>>>
>>>>> focus
>>>
>>>> on
>>>>
>>>>> the important stuff.
>>>>>> Where is the code? Who did already work on it? Or do we again have 30
>>>>>> people discussing but just 2 working? ;)
>>>>>>
>>>>>> LieGrue,strub
>>>>>> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
>>>>>> david.blevins@gmail.com> wrote:
>>>>>>
>>>>>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <
>>>>>>>
>>>>>> rmannibucau@gmail.com
>>>
>>>> wrote:
>>>>>>
>>>>>>> It was more as a "if im always the only one seeing tomee differently
>>>>>>>
>>>>>> i
>>>
>>>> can
>>>>>>
>>>>>>> leave to let you space". Not as a threat.
>>>>>>>
>>>>>> That's a generous sentiment. Either way the best outcome is that you
>>>>>>
>>>>> stay
>>>>
>>>>> and we all learn the lesson that disagreeing is ok and healthy. How
>>>>>>
>>>>> is
>>>
>>>> the
>>>>
>>>>> most important part.
>>>>>>
>>>>>> Disagreement can be an incredibly productive and innovative thing if
>>>>>>
>>>>> done
>>>>
>>>>> right. By definition, that means this project is sitting on some
>>>>>> incredible innovative potential.
>>>>>>
>>>>>> A concrete way I think we can measure ourselves is by the number of
>>>>>>
>>>>> people
>>>>
>>>>> who feel comfortable voting. I would consider a vote of 20 people
>>>>>>
>>>>> that
>>>
>>>> included 3 -1 votes to be significantly more healthy than a vote of 3
>>>>>> people and all +1s.
>>>>>>
>>>>>> [...]
>>>>>>> There is no veto at apache if you check rules closely. All is more
>>>>>>>
>>>>>> about
>>>>
>>>>> respect and overall consensus IIRC.
>>>>>>>
>>>>>> I want to be careful that we don't learn a false lesson as Apache does
>>>>>> have technical vetos. These are more meant for line-of-code level
>>>>>>
>>>>> input vs
>>>>
>>>>> community direction.
>>>>>>
>>>>>> The intention of the two votes was to make the line a little more
>>>>>>
>>>>> clear.
>>>
>>>> - The first vote "Merge Pull Request 123 - MicroProfile JWT support"
>>>>>>
>>>>> was
>>>
>>>> intended to flush out line-of-code level technical issues with the PR:
>>>>>> breaks the build; doesn't follow code style; introduces security
>>>>>>
>>>>> issues.
>>>
>>>> It's ultimately a Review-than-Commit vote and a -1 should be viewed
>>>>>>
>>>>> as a
>>>
>>>> technical veto.
>>>>>>
>>>>>> - The second vote "Explore creating a reusable JWT Library" was
>>>>>>
>>>>> intended
>>>
>>>> to determine overall desire on what the next step should be. No
>>>>>>
>>>>> commit
>>>
>>>> being reviewed, more of a community level discussion. A -1 should not
>>>>>>
>>>>> be
>>>>
>>>>> viewed as a veto.
>>>>>>
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
aren't there apache projects already dealing with public key formats?
cxf must have done a lot of work on that? would this just be a wrapper
to existing libs?
On 02/05/18 10:03, Jean-Louis Monteiro wrote:
> PCS8 "standard" or not is probably the one to no miss
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Wed, May 2, 2018 at 6:27 AM, Rudy De Busscher <rd...@gmail.com>
> wrote:
>
>>> Primarily what I'd like to do is really nail the public key format
>>> manipulation. I did a huge amount of research in this and would like to
>>> come up with an extremely well tested library that can natively read all
>>> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line
>> tools
>>> for converting between them.
>>
>> That would be super awesome. I have been working on the same thing the past
>> month or so.
>>
>> Rudy
>>
>> On 2 May 2018 at 00:13, David Blevins <da...@gmail.com> wrote:
>>
>>> Requested a repo we could potentially use for this.
>>>
>>> Primarily what I'd like to do is really nail the public key format
>>> manipulation. I did a huge amount of research in this and would like to
>>> come up with an extremely well tested library that can natively read all
>>> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line
>> tools
>>> for converting between them.
>>>
>>> This could be useful to both the TomEE and Geronimo MicroProfile JWT
>> impls.
>>>
>>> --
>>> David Blevins
>>> http://twitter.com/dblevins
>>> http://www.tomitribe.com
>>>
>>>> On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com> wrote:
>>>> The code still is in a PR (#123) for the moment
>>>>
>>>> I'm in to help.
>>>> Still some small fixes to do and I'd like MP-Config to be used to
>>> configure
>>>> keys, issues, and others.
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>> On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg
>> <struberg@yahoo.de.invalid
>>>> wrote:
>>>>
>>>>> As noted elsewhere: the vote question was a mixture of 'what do you
>>>>> think' (consensus -> majority vote) and 'is it ok' (technical ->
>>> unanimous
>>>>> vote).
>>>>> I'd also be in favour to do the generic parts in Geronimo and only do
>>> the
>>>>> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If
>>> this
>>>>> is interpreted as commit vote then I vote -0
>>>>> The work is the same and as long as it's been done I'm fine either
>> ways.
>>>>> Now that we did all the 3 weeks of rambling and discussions let's
>> focus
>>> on
>>>>> the important stuff.
>>>>> Where is the code? Who did already work on it? Or do we again have 30
>>>>> people discussing but just 2 working? ;)
>>>>>
>>>>> LieGrue,strub
>>>>> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
>>>>> david.blevins@gmail.com> wrote:
>>>>>
>>>>>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>>> wrote:
>>>>>> It was more as a "if im always the only one seeing tomee differently
>> i
>>>>> can
>>>>>> leave to let you space". Not as a threat.
>>>>> That's a generous sentiment. Either way the best outcome is that you
>>> stay
>>>>> and we all learn the lesson that disagreeing is ok and healthy. How
>> is
>>> the
>>>>> most important part.
>>>>>
>>>>> Disagreement can be an incredibly productive and innovative thing if
>>> done
>>>>> right. By definition, that means this project is sitting on some
>>>>> incredible innovative potential.
>>>>>
>>>>> A concrete way I think we can measure ourselves is by the number of
>>> people
>>>>> who feel comfortable voting. I would consider a vote of 20 people
>> that
>>>>> included 3 -1 votes to be significantly more healthy than a vote of 3
>>>>> people and all +1s.
>>>>>
>>>>>> [...]
>>>>>> There is no veto at apache if you check rules closely. All is more
>>> about
>>>>>> respect and overall consensus IIRC.
>>>>> I want to be careful that we don't learn a false lesson as Apache does
>>>>> have technical vetos. These are more meant for line-of-code level
>>> input vs
>>>>> community direction.
>>>>>
>>>>> The intention of the two votes was to make the line a little more
>> clear.
>>>>> - The first vote "Merge Pull Request 123 - MicroProfile JWT support"
>> was
>>>>> intended to flush out line-of-code level technical issues with the PR:
>>>>> breaks the build; doesn't follow code style; introduces security
>> issues.
>>>>> It's ultimately a Review-than-Commit vote and a -1 should be viewed
>> as a
>>>>> technical veto.
>>>>>
>>>>> - The second vote "Explore creating a reusable JWT Library" was
>> intended
>>>>> to determine overall desire on what the next step should be. No
>> commit
>>>>> being reviewed, more of a community level discussion. A -1 should not
>>> be
>>>>> viewed as a veto.
>>>>>
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
PCS8 "standard" or not is probably the one to no miss
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, May 2, 2018 at 6:27 AM, Rudy De Busscher <rd...@gmail.com>
wrote:
> >
> > Primarily what I'd like to do is really nail the public key format
> > manipulation. I did a huge amount of research in this and would like to
> > come up with an extremely well tested library that can natively read all
> > the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line
> tools
> > for converting between them.
>
>
> That would be super awesome. I have been working on the same thing the past
> month or so.
>
> Rudy
>
> On 2 May 2018 at 00:13, David Blevins <da...@gmail.com> wrote:
>
> > Requested a repo we could potentially use for this.
> >
> > Primarily what I'd like to do is really nail the public key format
> > manipulation. I did a huge amount of research in this and would like to
> > come up with an extremely well tested library that can natively read all
> > the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line
> tools
> > for converting between them.
> >
> > This could be useful to both the TomEE and Geronimo MicroProfile JWT
> impls.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> > > On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> > >
> > > The code still is in a PR (#123) for the moment
> > >
> > > I'm in to help.
> > > Still some small fixes to do and I'd like MP-Config to be used to
> > configure
> > > keys, issues, and others.
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > > On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg
> <struberg@yahoo.de.invalid
> > >
> > > wrote:
> > >
> > >> As noted elsewhere: the vote question was a mixture of 'what do you
> > >> think' (consensus -> majority vote) and 'is it ok' (technical ->
> > unanimous
> > >> vote).
> > >> I'd also be in favour to do the generic parts in Geronimo and only do
> > the
> > >> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If
> > this
> > >> is interpreted as commit vote then I vote -0
> > >> The work is the same and as long as it's been done I'm fine either
> ways.
> > >> Now that we did all the 3 weeks of rambling and discussions let's
> focus
> > on
> > >> the important stuff.
> > >> Where is the code? Who did already work on it? Or do we again have 30
> > >> people discussing but just 2 working? ;)
> > >>
> > >> LieGrue,strub
> > >> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
> > >> david.blevins@gmail.com> wrote:
> > >>
> > >>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>> It was more as a "if im always the only one seeing tomee differently
> i
> > >> can
> > >>> leave to let you space". Not as a threat.
> > >>
> > >> That's a generous sentiment. Either way the best outcome is that you
> > stay
> > >> and we all learn the lesson that disagreeing is ok and healthy. How
> is
> > the
> > >> most important part.
> > >>
> > >> Disagreement can be an incredibly productive and innovative thing if
> > done
> > >> right. By definition, that means this project is sitting on some
> > >> incredible innovative potential.
> > >>
> > >> A concrete way I think we can measure ourselves is by the number of
> > people
> > >> who feel comfortable voting. I would consider a vote of 20 people
> that
> > >> included 3 -1 votes to be significantly more healthy than a vote of 3
> > >> people and all +1s.
> > >>
> > >>> [...]
> > >>> There is no veto at apache if you check rules closely. All is more
> > about
> > >>> respect and overall consensus IIRC.
> > >>
> > >> I want to be careful that we don't learn a false lesson as Apache does
> > >> have technical vetos. These are more meant for line-of-code level
> > input vs
> > >> community direction.
> > >>
> > >> The intention of the two votes was to make the line a little more
> clear.
> > >>
> > >> - The first vote "Merge Pull Request 123 - MicroProfile JWT support"
> was
> > >> intended to flush out line-of-code level technical issues with the PR:
> > >> breaks the build; doesn't follow code style; introduces security
> issues.
> > >> It's ultimately a Review-than-Commit vote and a -1 should be viewed
> as a
> > >> technical veto.
> > >>
> > >> - The second vote "Explore creating a reusable JWT Library" was
> intended
> > >> to determine overall desire on what the next step should be. No
> commit
> > >> being reviewed, more of a community level discussion. A -1 should not
> > be
> > >> viewed as a veto.
> > >>
> > >>
> > >> -David
> > >>
> > >>
> >
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Rudy De Busscher <rd...@gmail.com>.
>
> Primarily what I'd like to do is really nail the public key format
> manipulation. I did a huge amount of research in this and would like to
> come up with an extremely well tested library that can natively read all
> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line tools
> for converting between them.
That would be super awesome. I have been working on the same thing the past
month or so.
Rudy
On 2 May 2018 at 00:13, David Blevins <da...@gmail.com> wrote:
> Requested a repo we could potentially use for this.
>
> Primarily what I'd like to do is really nail the public key format
> manipulation. I did a huge amount of research in this and would like to
> come up with an extremely well tested library that can natively read all
> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line tools
> for converting between them.
>
> This could be useful to both the TomEE and Geronimo MicroProfile JWT impls.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
> >
> > The code still is in a PR (#123) for the moment
> >
> > I'm in to help.
> > Still some small fixes to do and I'd like MP-Config to be used to
> configure
> > keys, issues, and others.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> >> As noted elsewhere: the vote question was a mixture of 'what do you
> >> think' (consensus -> majority vote) and 'is it ok' (technical ->
> unanimous
> >> vote).
> >> I'd also be in favour to do the generic parts in Geronimo and only do
> the
> >> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If
> this
> >> is interpreted as commit vote then I vote -0
> >> The work is the same and as long as it's been done I'm fine either ways.
> >> Now that we did all the 3 weeks of rambling and discussions let's focus
> on
> >> the important stuff.
> >> Where is the code? Who did already work on it? Or do we again have 30
> >> people discussing but just 2 working? ;)
> >>
> >> LieGrue,strub
> >> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
> >> david.blevins@gmail.com> wrote:
> >>
> >>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> >> wrote:
> >>>
> >>> It was more as a "if im always the only one seeing tomee differently i
> >> can
> >>> leave to let you space". Not as a threat.
> >>
> >> That's a generous sentiment. Either way the best outcome is that you
> stay
> >> and we all learn the lesson that disagreeing is ok and healthy. How is
> the
> >> most important part.
> >>
> >> Disagreement can be an incredibly productive and innovative thing if
> done
> >> right. By definition, that means this project is sitting on some
> >> incredible innovative potential.
> >>
> >> A concrete way I think we can measure ourselves is by the number of
> people
> >> who feel comfortable voting. I would consider a vote of 20 people that
> >> included 3 -1 votes to be significantly more healthy than a vote of 3
> >> people and all +1s.
> >>
> >>> [...]
> >>> There is no veto at apache if you check rules closely. All is more
> about
> >>> respect and overall consensus IIRC.
> >>
> >> I want to be careful that we don't learn a false lesson as Apache does
> >> have technical vetos. These are more meant for line-of-code level
> input vs
> >> community direction.
> >>
> >> The intention of the two votes was to make the line a little more clear.
> >>
> >> - The first vote "Merge Pull Request 123 - MicroProfile JWT support" was
> >> intended to flush out line-of-code level technical issues with the PR:
> >> breaks the build; doesn't follow code style; introduces security issues.
> >> It's ultimately a Review-than-Commit vote and a -1 should be viewed as a
> >> technical veto.
> >>
> >> - The second vote "Explore creating a reusable JWT Library" was intended
> >> to determine overall desire on what the next step should be. No commit
> >> being reviewed, more of a community level discussion. A -1 should not
> be
> >> viewed as a veto.
> >>
> >>
> >> -David
> >>
> >>
>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
Requested a repo we could potentially use for this.
Primarily what I'd like to do is really nail the public key format manipulation. I did a huge amount of research in this and would like to come up with an extremely well tested library that can natively read all the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line tools for converting between them.
This could be useful to both the TomEE and Geronimo MicroProfile JWT impls.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>
> The code still is in a PR (#123) for the moment
>
> I'm in to help.
> Still some small fixes to do and I'd like MP-Config to be used to configure
> keys, issues, and others.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
>> As noted elsewhere: the vote question was a mixture of 'what do you
>> think' (consensus -> majority vote) and 'is it ok' (technical -> unanimous
>> vote).
>> I'd also be in favour to do the generic parts in Geronimo and only do the
>> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If this
>> is interpreted as commit vote then I vote -0
>> The work is the same and as long as it's been done I'm fine either ways.
>> Now that we did all the 3 weeks of rambling and discussions let's focus on
>> the important stuff.
>> Where is the code? Who did already work on it? Or do we again have 30
>> people discussing but just 2 working? ;)
>>
>> LieGrue,strub
>> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
>> david.blevins@gmail.com> wrote:
>>
>>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>
>>> It was more as a "if im always the only one seeing tomee differently i
>> can
>>> leave to let you space". Not as a threat.
>>
>> That's a generous sentiment. Either way the best outcome is that you stay
>> and we all learn the lesson that disagreeing is ok and healthy. How is the
>> most important part.
>>
>> Disagreement can be an incredibly productive and innovative thing if done
>> right. By definition, that means this project is sitting on some
>> incredible innovative potential.
>>
>> A concrete way I think we can measure ourselves is by the number of people
>> who feel comfortable voting. I would consider a vote of 20 people that
>> included 3 -1 votes to be significantly more healthy than a vote of 3
>> people and all +1s.
>>
>>> [...]
>>> There is no veto at apache if you check rules closely. All is more about
>>> respect and overall consensus IIRC.
>>
>> I want to be careful that we don't learn a false lesson as Apache does
>> have technical vetos. These are more meant for line-of-code level input vs
>> community direction.
>>
>> The intention of the two votes was to make the line a little more clear.
>>
>> - The first vote "Merge Pull Request 123 - MicroProfile JWT support" was
>> intended to flush out line-of-code level technical issues with the PR:
>> breaks the build; doesn't follow code style; introduces security issues.
>> It's ultimately a Review-than-Commit vote and a -1 should be viewed as a
>> technical veto.
>>
>> - The second vote "Explore creating a reusable JWT Library" was intended
>> to determine overall desire on what the next step should be. No commit
>> being reviewed, more of a community level discussion. A -1 should not be
>> viewed as a veto.
>>
>>
>> -David
>>
>>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
The code still is in a PR (#123) for the moment
I'm in to help.
Still some small fixes to do and I'd like MP-Config to be used to configure
keys, issues, and others.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg <st...@yahoo.de.invalid>
wrote:
> As noted elsewhere: the vote question was a mixture of 'what do you
> think' (consensus -> majority vote) and 'is it ok' (technical -> unanimous
> vote).
> I'd also be in favour to do the generic parts in Geronimo and only do the
> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If this
> is interpreted as commit vote then I vote -0
> The work is the same and as long as it's been done I'm fine either ways.
> Now that we did all the 3 weeks of rambling and discussions let's focus on
> the important stuff.
> Where is the code? Who did already work on it? Or do we again have 30
> people discussing but just 2 working? ;)
>
> LieGrue,strub
> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <
> david.blevins@gmail.com> wrote:
>
> > On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > It was more as a "if im always the only one seeing tomee differently i
> can
> > leave to let you space". Not as a threat.
>
> That's a generous sentiment. Either way the best outcome is that you stay
> and we all learn the lesson that disagreeing is ok and healthy. How is the
> most important part.
>
> Disagreement can be an incredibly productive and innovative thing if done
> right. By definition, that means this project is sitting on some
> incredible innovative potential.
>
> A concrete way I think we can measure ourselves is by the number of people
> who feel comfortable voting. I would consider a vote of 20 people that
> included 3 -1 votes to be significantly more healthy than a vote of 3
> people and all +1s.
>
> > [...]
> > There is no veto at apache if you check rules closely. All is more about
> > respect and overall consensus IIRC.
>
> I want to be careful that we don't learn a false lesson as Apache does
> have technical vetos. These are more meant for line-of-code level input vs
> community direction.
>
> The intention of the two votes was to make the line a little more clear.
>
> - The first vote "Merge Pull Request 123 - MicroProfile JWT support" was
> intended to flush out line-of-code level technical issues with the PR:
> breaks the build; doesn't follow code style; introduces security issues.
> It's ultimately a Review-than-Commit vote and a -1 should be viewed as a
> technical veto.
>
> - The second vote "Explore creating a reusable JWT Library" was intended
> to determine overall desire on what the next step should be. No commit
> being reviewed, more of a community level discussion. A -1 should not be
> viewed as a veto.
>
>
> -David
>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
As noted elsewhere: the vote question was a mixture of 'what do you think' (consensus -> majority vote) and 'is it ok' (technical -> unanimous vote).
I'd also be in favour to do the generic parts in Geronimo and only do the integration in TomEE. So yes, in a consensus vote I'd also vote -1. If this is interpreted as commit vote then I vote -0
The work is the same and as long as it's been done I'm fine either ways. Now that we did all the 3 weeks of rambling and discussions let's focus on the important stuff.
Where is the code? Who did already work on it? Or do we again have 30 people discussing but just 2 working? ;)
LieGrue,strub
On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins <da...@gmail.com> wrote:
> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> It was more as a "if im always the only one seeing tomee differently i can
> leave to let you space". Not as a threat.
That's a generous sentiment. Either way the best outcome is that you stay and we all learn the lesson that disagreeing is ok and healthy. How is the most important part.
Disagreement can be an incredibly productive and innovative thing if done right. By definition, that means this project is sitting on some incredible innovative potential.
A concrete way I think we can measure ourselves is by the number of people who feel comfortable voting. I would consider a vote of 20 people that included 3 -1 votes to be significantly more healthy than a vote of 3 people and all +1s.
> [...]
> There is no veto at apache if you check rules closely. All is more about
> respect and overall consensus IIRC.
I want to be careful that we don't learn a false lesson as Apache does have technical vetos. These are more meant for line-of-code level input vs community direction.
The intention of the two votes was to make the line a little more clear.
- The first vote "Merge Pull Request 123 - MicroProfile JWT support" was intended to flush out line-of-code level technical issues with the PR: breaks the build; doesn't follow code style; introduces security issues. It's ultimately a Review-than-Commit vote and a -1 should be viewed as a technical veto.
- The second vote "Explore creating a reusable JWT Library" was intended to determine overall desire on what the next step should be. No commit being reviewed, more of a community level discussion. A -1 should not be viewed as a veto.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> It was more as a "if im always the only one seeing tomee differently i can
> leave to let you space". Not as a threat.
That's a generous sentiment. Either way the best outcome is that you stay and we all learn the lesson that disagreeing is ok and healthy. How is the most important part.
Disagreement can be an incredibly productive and innovative thing if done right. By definition, that means this project is sitting on some incredible innovative potential.
A concrete way I think we can measure ourselves is by the number of people who feel comfortable voting. I would consider a vote of 20 people that included 3 -1 votes to be significantly more healthy than a vote of 3 people and all +1s.
> [...]
> There is no veto at apache if you check rules closely. All is more about
> respect and overall consensus IIRC.
I want to be careful that we don't learn a false lesson as Apache does have technical vetos. These are more meant for line-of-code level input vs community direction.
The intention of the two votes was to make the line a little more clear.
- The first vote "Merge Pull Request 123 - MicroProfile JWT support" was intended to flush out line-of-code level technical issues with the PR: breaks the build; doesn't follow code style; introduces security issues. It's ultimately a Review-than-Commit vote and a -1 should be viewed as a technical veto.
- The second vote "Explore creating a reusable JWT Library" was intended to determine overall desire on what the next step should be. No commit being reviewed, more of a community level discussion. A -1 should not be viewed as a veto.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 30 mars 2018 23:46, "David Blevins" <da...@gmail.com> a écrit :
> On Mar 29, 2018, at 10:06 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> Le 30 mars 2018 04:30, "David Blevins" <da...@gmail.com> a écrit :
>
>
>> On Mar 29, 2018, at 12:57 PM, David Blevins <da...@gmail.com>
> wrote:
>>
>>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>>
>>> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit
> :
>>>
>>>
>>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>
>>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
>>> wrote:
>>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>>
>>>> That + the fact tomee is not and shouldnt become a put it all project
> just
>>>> become of scm perms IMO but stay an integration project to keep sense
> and
>>>> not mess up its own image and mess up the quality of our reusable libs.
>>>
>>>> Do you see this as a one-time situation or do you intend to vote the
> same
>>>> way on any future MicroProfile implementation work in TomEE?
>>>>
>>>> For example, should work be started to implement MicroProfile
> OpenTracing
>>>> in TomEE, would that PR be -1 on the basis the implementation should be
> in
>>>> Geronimo?
>>>
>>> Being said it will be in G anyway since that is half of G definition
> since
>>> some months now (since server has been dropped), I ll do my best to keep
> it
>>> consistent in our small ecosystem and do the same to have strong
reusable
>>> libs since there is no technical blockers @MP to have it and a strong
>>> integration solution (tomee) and not a mess with an in between state.
>>
>> I'm reading that as a yes that you would -1 future MP implementation work
> in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> come to that and will do your best to create good implementations in
> Geronimo so it isn't necessary.
>>
>> If I misunderstood, please clarify.
>
>> On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>> Globally that is it. You explained a lot why geronimo failed and not sure
>> why tomee is kind of taking the same path - well actually cause of "perms
>> lack" fear from what I read. This is not a safe reason (+not that
relevant
>> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
>> we have been 7 years ago instead of just going on different paths cause
of
>> a fears.
>
> > I think we should openly discuss your perspective and how it might be
> > perceived by the project. There are 11 +1 votes, 5 of them binding. It
> > does appear that overall the project would like to move forward with the
> > code. You -1 the code on the basis that it should go to Geronimo
instead
> > with the clear statement you will continue to -1 on future MicroProfile
> > code. Can you see how this creates a situation where 11 people feel
they
> > have no ability to contribute to the project now or in the future? Do
you
> > feel this is the spirit of the Apache Way and represents community over
> > code?
>
>
> More than never but I just dont ignore other projects. I understand most
of
> voting people are not involved in G and therefore I can see where they
come
> from (and no Jon, this was not directed to you in particular).
>
> The main difference is Im thinking of communities and not community.
I think it would be fair to assume everyone is thinking of communities
plural and that no one is ignoring the greater good of Apache. Only that
there are differences in opinion on what that is and how it should be
achieved.
> You are also plain wrong saying there is no way to contribute, there are
> plenty as on any asf projects and for most people it will be the exact
same.
>
> Project is created @G, if T duplicates it what does happen? We get an half
> baked flavor on one side and another one on the other? Do you think it is
> the right thing for asf David? Do you want to split communities? Do you
> want to make of TomEE a put it all project which means getting rid of
TomEE
> as a thing?
We need to acknowledge that the community voted on where to continue
working on the code and that vote was overwhelmingly to continue evolving
it here. The perspective of "TomEE is duplicating Geronimo" is a bit
skewed as you created that repo in Geronimo during this vote. One could
question if that is healthy behavior, but ultimately it's ok. Per ASF
rules, duplication is absolutely ok, not a bad thing and business as
usual. You feel it is bad and are entitled to that opinion, but I don't
see you acknowledging your role in actively creating this duplication you
don't like.
There is also no code in the Geronimo repo you created, so if duplication
is a concern it can be avoided. It stands to reason that for you where the
code lives, Geronimo, is the most important thing and if that means
duplication, that's a sacrifice you're willing to make. Again, this is an
absolutely fine perspective and ok by Apache rules. People should be
allowed to work where they want.
There is no code cause the fact to have started 2 threads in 2 communities
for the same project but JL in a position where i guess he is very bad to
do anything. Just my guess maybe. I also dont want to redo the code from
myself to not be disrespectful to JL.
> Im really fed up to be always felt as the bad guy but I also know it is
> wrong and will fail. Short terms it will fake some activity on the project
> (is it the goal?) Which can be good, long terms it will kill all the good
> of TomEE AND our libraries as mentionned earlier.
>
> If you want to pass it in force you can but please remive me from the pmc
> before.
You are not the bad guy and it would be terrible to see you step down from
the PMC. I would not support you being removed and would actively address
any movement in that direction. I don't think we as a community grow by
removing people.
My definition of success is coming through this with you still strong, not
the bad guy, but also that everyone feels they have the ability to keep
moving forward even if you disagree. That this is business as usual and
disagreement is ok, even encouraged. As PMC chair I feel it is my
responsibility to protect your and everyone's ability to disagree, but make
sure it is healthy and voices are both used and heard. If anyone feels
like the bad guy, I'm doing a terrible job. If anyone feels like their
voice doesn't matter, I'm doing a terrible job. You have a strong voice
and that is an asset for the project. I don't think the solution is for
your voice to get weaker, but for other voices to get a bit stronger. I
think it's a common mistake to focus too much on the voices that talk, and
not enough on the ones that don't. As I tend to say, "the only people who
don't break the build are the ones who do nothing."
As for leaving the PMC, I'd request you don't. I think that teaches others
that disagreeing with you has consequences and will make them less likely
to feel comfortable disagreeing with you in any form. We need to get to a
place where disagreement is encouraged in a healthy way and discussion
around disagreement is encouraged, not punished. When people feel it is
safe to be wrong, they contribute more and earlier in the creative process.
It was more as a "if im always the only one seeing tomee differently i can
leave to let you space". Not as a threat.
What I do feel I need to clarify with the board is if a technical veto can
be issued on the basis that the code should exist exclusively in another
project. A technical veto is usually meant to be accompanied by something
that can be fixed so the code can potentially move forward. In this
situation it's been clarified there is nothing that could be done to make
the code acceptable here, moreover the code is in fact desirable and should
live in Geronimo. This seems to say there's nothing technically wrong with
the code and this is a community based -1. That's also ok, but if it is
about community direction likely the majority vote should carry, not the
minority.
There is no veto at apache if you check rules closely. All is more about
respect and overall consensus IIRC.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 29, 2018, at 10:06 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le 30 mars 2018 04:30, "David Blevins" <da...@gmail.com> a écrit :
>
>
>> On Mar 29, 2018, at 12:57 PM, David Blevins <da...@gmail.com>
> wrote:
>>
>>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>>
>>> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit
> :
>>>
>>>
>>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>
>>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
>>> wrote:
>>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>>
>>>> That + the fact tomee is not and shouldnt become a put it all project
> just
>>>> become of scm perms IMO but stay an integration project to keep sense
> and
>>>> not mess up its own image and mess up the quality of our reusable libs.
>>>
>>>> Do you see this as a one-time situation or do you intend to vote the
> same
>>>> way on any future MicroProfile implementation work in TomEE?
>>>>
>>>> For example, should work be started to implement MicroProfile
> OpenTracing
>>>> in TomEE, would that PR be -1 on the basis the implementation should be
> in
>>>> Geronimo?
>>>
>>> Being said it will be in G anyway since that is half of G definition
> since
>>> some months now (since server has been dropped), I ll do my best to keep
> it
>>> consistent in our small ecosystem and do the same to have strong reusable
>>> libs since there is no technical blockers @MP to have it and a strong
>>> integration solution (tomee) and not a mess with an in between state.
>>
>> I'm reading that as a yes that you would -1 future MP implementation work
> in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> come to that and will do your best to create good implementations in
> Geronimo so it isn't necessary.
>>
>> If I misunderstood, please clarify.
>
>> On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>> Globally that is it. You explained a lot why geronimo failed and not sure
>> why tomee is kind of taking the same path - well actually cause of "perms
>> lack" fear from what I read. This is not a safe reason (+not that relevant
>> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
>> we have been 7 years ago instead of just going on different paths cause of
>> a fears.
>
> > I think we should openly discuss your perspective and how it might be
> > perceived by the project. There are 11 +1 votes, 5 of them binding. It
> > does appear that overall the project would like to move forward with the
> > code. You -1 the code on the basis that it should go to Geronimo instead
> > with the clear statement you will continue to -1 on future MicroProfile
> > code. Can you see how this creates a situation where 11 people feel they
> > have no ability to contribute to the project now or in the future? Do you
> > feel this is the spirit of the Apache Way and represents community over
> > code?
>
>
> More than never but I just dont ignore other projects. I understand most of
> voting people are not involved in G and therefore I can see where they come
> from (and no Jon, this was not directed to you in particular).
>
> The main difference is Im thinking of communities and not community.
I think it would be fair to assume everyone is thinking of communities plural and that no one is ignoring the greater good of Apache. Only that there are differences in opinion on what that is and how it should be achieved.
> You are also plain wrong saying there is no way to contribute, there are
> plenty as on any asf projects and for most people it will be the exact same.
>
> Project is created @G, if T duplicates it what does happen? We get an half
> baked flavor on one side and another one on the other? Do you think it is
> the right thing for asf David? Do you want to split communities? Do you
> want to make of TomEE a put it all project which means getting rid of TomEE
> as a thing?
We need to acknowledge that the community voted on where to continue working on the code and that vote was overwhelmingly to continue evolving it here. The perspective of "TomEE is duplicating Geronimo" is a bit skewed as you created that repo in Geronimo during this vote. One could question if that is healthy behavior, but ultimately it's ok. Per ASF rules, duplication is absolutely ok, not a bad thing and business as usual. You feel it is bad and are entitled to that opinion, but I don't see you acknowledging your role in actively creating this duplication you don't like.
There is also no code in the Geronimo repo you created, so if duplication is a concern it can be avoided. It stands to reason that for you where the code lives, Geronimo, is the most important thing and if that means duplication, that's a sacrifice you're willing to make. Again, this is an absolutely fine perspective and ok by Apache rules. People should be allowed to work where they want.
> Im really fed up to be always felt as the bad guy but I also know it is
> wrong and will fail. Short terms it will fake some activity on the project
> (is it the goal?) Which can be good, long terms it will kill all the good
> of TomEE AND our libraries as mentionned earlier.
>
> If you want to pass it in force you can but please remive me from the pmc
> before.
You are not the bad guy and it would be terrible to see you step down from the PMC. I would not support you being removed and would actively address any movement in that direction. I don't think we as a community grow by removing people.
My definition of success is coming through this with you still strong, not the bad guy, but also that everyone feels they have the ability to keep moving forward even if you disagree. That this is business as usual and disagreement is ok, even encouraged. As PMC chair I feel it is my responsibility to protect your and everyone's ability to disagree, but make sure it is healthy and voices are both used and heard. If anyone feels like the bad guy, I'm doing a terrible job. If anyone feels like their voice doesn't matter, I'm doing a terrible job. You have a strong voice and that is an asset for the project. I don't think the solution is for your voice to get weaker, but for other voices to get a bit stronger. I think it's a common mistake to focus too much on the voices that talk, and not enough on the ones that don't. As I tend to say, "the only people who don't break the build are the ones who do nothing."
As for leaving the PMC, I'd request you don't. I think that teaches others that disagreeing with you has consequences and will make them less likely to feel comfortable disagreeing with you in any form. We need to get to a place where disagreement is encouraged in a healthy way and discussion around disagreement is encouraged, not punished. When people feel it is safe to be wrong, they contribute more and earlier in the creative process.
What I do feel I need to clarify with the board is if a technical veto can be issued on the basis that the code should exist exclusively in another project. A technical veto is usually meant to be accompanied by something that can be fixed so the code can potentially move forward. In this situation it's been clarified there is nothing that could be done to make the code acceptable here, moreover the code is in fact desirable and should live in Geronimo. This seems to say there's nothing technically wrong with the code and this is a community based -1. That's also ok, but if it is about community direction likely the majority vote should carry, not the minority.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 30 mars 2018 04:30, "David Blevins" <da...@gmail.com> a écrit :
> On Mar 29, 2018, at 12:57 PM, David Blevins <da...@gmail.com>
wrote:
>
>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>>
>> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit
:
>>
>>
>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>
>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
>> wrote:
>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>
>>> That + the fact tomee is not and shouldnt become a put it all project
just
>>> become of scm perms IMO but stay an integration project to keep sense
and
>>> not mess up its own image and mess up the quality of our reusable libs.
>>
>>> Do you see this as a one-time situation or do you intend to vote the
same
>>> way on any future MicroProfile implementation work in TomEE?
>>>
>>> For example, should work be started to implement MicroProfile
OpenTracing
>>> in TomEE, would that PR be -1 on the basis the implementation should be
in
>>> Geronimo?
>>
>> Being said it will be in G anyway since that is half of G definition
since
>> some months now (since server has been dropped), I ll do my best to keep
it
>> consistent in our small ecosystem and do the same to have strong reusable
>> libs since there is no technical blockers @MP to have it and a strong
>> integration solution (tomee) and not a mess with an in between state.
>
> I'm reading that as a yes that you would -1 future MP implementation work
in TomEE on the basis it should live in Geronimo, but you hope it doesn't
come to that and will do your best to create good implementations in
Geronimo so it isn't necessary.
>
> If I misunderstood, please clarify.
> On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> Globally that is it. You explained a lot why geronimo failed and not sure
> why tomee is kind of taking the same path - well actually cause of "perms
> lack" fear from what I read. This is not a safe reason (+not that relevant
> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
> we have been 7 years ago instead of just going on different paths cause of
> a fears.
I think we should openly discuss your perspective and how it might be
perceived by the project. There are 11 +1 votes, 5 of them binding. It
does appear that overall the project would like to move forward with the
code. You -1 the code on the basis that it should go to Geronimo instead
with the clear statement you will continue to -1 so on future MicroProfile
code. Can you see how this creates a situation where 11 people feel they
have no ability to contribute to the project now or in the future? Do you
feel this is the spirit of the Apache Way and represents community over
code?
More than never but I just dont ignore other projects. I understand most of
voting people are not involved in G and therefore I can see where they come
from (and no Jon, this was not directed to you in particular).
The main difference is Im thinking of communities and not community.
You are also plain wrong saying there is no way to contribute, there are
plenty as on any asf projects and for most people it will be the exact same.
Project is created @G, if T duplicates it what does happen? We get an half
baked flavor on one side and another one on the other? Do you think it is
the right thing for asf David? Do you want to split communities? Do you
want to make of TomEE a put it all project which means getting rid of TomEE
as a thing?
Im really fed up to be always felt as the bad guy but I also know it is
wrong and will fail. Short terms it will fake some activity on the project
(is it the goal?) Which can be good, long terms it will kill all the good
of TomEE AND our libraries as mentionned earlier.
If you want to pass it in force you can but please remive me from the pmc
before.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 29, 2018, at 12:57 PM, David Blevins <da...@gmail.com> wrote:
>
>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>
>> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit :
>>
>>
>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>
>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
>> wrote:
>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>
>>> That + the fact tomee is not and shouldnt become a put it all project just
>>> become of scm perms IMO but stay an integration project to keep sense and
>>> not mess up its own image and mess up the quality of our reusable libs.
>>
>>> Do you see this as a one-time situation or do you intend to vote the same
>>> way on any future MicroProfile implementation work in TomEE?
>>>
>>> For example, should work be started to implement MicroProfile OpenTracing
>>> in TomEE, would that PR be -1 on the basis the implementation should be in
>>> Geronimo?
>>
>> Being said it will be in G anyway since that is half of G definition since
>> some months now (since server has been dropped), I ll do my best to keep it
>> consistent in our small ecosystem and do the same to have strong reusable
>> libs since there is no technical blockers @MP to have it and a strong
>> integration solution (tomee) and not a mess with an in between state.
>
> I'm reading that as a yes that you would -1 future MP implementation work in TomEE on the basis it should live in Geronimo, but you hope it doesn't come to that and will do your best to create good implementations in Geronimo so it isn't necessary.
>
> If I misunderstood, please clarify.
> On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Globally that is it. You explained a lot why geronimo failed and not sure
> why tomee is kind of taking the same path - well actually cause of "perms
> lack" fear from what I read. This is not a safe reason (+not that relevant
> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
> we have been 7 years ago instead of just going on different paths cause of
> a fears.
I think we should openly discuss your perspective and how it might be perceived by the project. There are 11 +1 votes, 5 of them binding. It does appear that overall the project would like to move forward with the code. You -1 the code on the basis that it should go to Geronimo instead with the clear statement you will continue to -1 so on future MicroProfile code. Can you see how this creates a situation where 11 people feel they have no ability to contribute to the project now or in the future? Do you feel this is the spirit of the Apache Way and represents community over code?
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit :
>
>
>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>>> On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
> wrote:
>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>
>> That + the fact tomee is not and shouldnt become a put it all project just
>> become of scm perms IMO but stay an integration project to keep sense and
>> not mess up its own image and mess up the quality of our reusable libs.
>
> > Do you see this as a one-time situation or do you intend to vote the same
> > way on any future MicroProfile implementation work in TomEE?
> >
> > For example, should work be started to implement MicroProfile OpenTracing
> > in TomEE, would that PR be -1 on the basis the implementation should be in
> > Geronimo?
>
> Being said it will be in G anyway since that is half of G definition since
> some months now (since server has been dropped), I ll do my best to keep it
> consistent in our small ecosystem and do the same to have strong reusable
> libs since there is no technical blockers @MP to have it and a strong
> integration solution (tomee) and not a mess with an in between state.
I'm reading that as a yes that you would -1 future MP implementation work in TomEE on the basis it should live in Geronimo, but you hope it doesn't come to that and will do your best to create good implementations in Geronimo so it isn't necessary.
If I misunderstood, please clarify.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 29 mars 2018 20:49, "David Blevins" <da...@gmail.com> a écrit :
> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> > On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com>
wrote:
> > Is your -1 on the basis that the code must be moved to Geronimo?
>
> That + the fact tomee is not and shouldnt become a put it all project just
> become of scm perms IMO but stay an integration project to keep sense and
> not mess up its own image and mess up the quality of our reusable libs.
Do you see this as a one-time situation or do you intend to vote the same
way on any future MicroProfile implementation work in TomEE?
For example, should work be started to implement MicroProfile OpenTracing
in TomEE, would that PR be -1 on the basis the implementation should be in
Geronimo?
Being said it will be in G anyway since that is half of G definition since
some months now (since server has been dropped), I ll do my best to keep it
consistent in our small ecosystem and do the same to have strong reusable
libs since there is no technical blockers @MP to have it and a strong
integration solution (tomee) and not a mess with an in between state.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> > On Mar 28, 2018, at 6:29 PM, David Blevins <da...@gmail.com> wrote:
> > Is your -1 on the basis that the code must be moved to Geronimo?
>
> That + the fact tomee is not and shouldnt become a put it all project just
> become of scm perms IMO but stay an integration project to keep sense and
> not mess up its own image and mess up the quality of our reusable libs.
Do you see this as a one-time situation or do you intend to vote the same way on any future MicroProfile implementation work in TomEE?
For example, should work be started to implement MicroProfile OpenTracing in TomEE, would that PR be -1 on the basis the implementation should be in Geronimo?
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 29 mars 2018 03:29, "David Blevins" <da...@gmail.com> a écrit :
> On Mar 28, 2018, at 1:21 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> Just move the "main" code to the repo created @G and import the new lib in
> tomee MP as Roberto did for config. Nothing blocking JL to do them at all.
I will need to include the recent discussion in the April board report and
I want to fairly represent everyone's votes.
Is your -1 on the basis that the code must be moved to Geronimo?
That + the fact tomee is not and shouldnt become a put it all project just
become of scm perms IMO but stay an integration project to keep sense and
not mess up its own image and mess up the quality of our reusable libs.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 28, 2018, at 1:21 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Just move the "main" code to the repo created @G and import the new lib in
> tomee MP as Roberto did for config. Nothing blocking JL to do them at all.
I will need to include the recent discussion in the April board report and I want to fairly represent everyone's votes.
Is your -1 on the basis that the code must be moved to Geronimo?
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-03-28 10:17 GMT+02:00 Jonathan Gallimore <jo...@gmail.com>
:
> On Wed, Mar 28, 2018 at 6:13 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Roberto PR *is* merged JL.
> > He did the work to be able to consume any CDI "container" lib.
> >
> > So I'd just extract the code as we discussed together in G before that
> mess
> > and move forward to keep TCK and add the lib in the MP distro Roberto
> > created to fit that design.
> >
> > As soon as you imported the lib in G, I will make sure to help to make it
> > releasable.
> >
>
> What does that mean? What are the changes you're proposing, and why can't
> Jean-Louis do them?
>
Just move the "main" code to the repo created @G and import the new lib in
tomee MP as Roberto did for config. Nothing blocking JL to do them at all.
>
> Jon
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Wed, Mar 28, 2018 at 6:13 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Roberto PR *is* merged JL.
> He did the work to be able to consume any CDI "container" lib.
>
> So I'd just extract the code as we discussed together in G before that mess
> and move forward to keep TCK and add the lib in the MP distro Roberto
> created to fit that design.
>
> As soon as you imported the lib in G, I will make sure to help to make it
> releasable.
>
What does that mean? What are the changes you're proposing, and why can't
Jean-Louis do them?
Jon
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Matthew: with JWT you get a self contained token you validate without any
remote call, you just need to put @LoginConfig (from the MP spec, not the
servlet one) or the equivalent in the web.xml to activate it. To configure
it you can use mp-config to set the certificate which validate the JWT
signature (and optionally the date validation range).
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-03-29 12:59 GMT+02:00 Matthew Broadhead <matthew.broadhead@nbmlaw.co.uk
>:
> thanks for the more detailed explanation and it is good that @RolesAllowed
> will finally work.
> by "configuration of an oauth endpoint" i meant that the user could define
> an endpoint in config that would allow TomEE to use that as as a security
> provider. i.e. not using TomEE itself as a security provider.
> in keycloak a realm client has a "keycloak OIDC JSON" file that is created
> through the user interface. this is dropped into the webapp and a valve
> has to be setup in context.xml
> <Context path="/your-context-path">
> <Valve className="org.keycloak.adapters.tomcat.KeycloakAuthenticato
> rValve"/>
> </Context>
> i just wondered if it was similar. are there any docs?
>
>
> On 29/03/2018 04:00, David Blevins wrote:
>
>> On Mar 28, 2018, at 1:22 AM, Matthew Broadhead <
>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>
>>> would it allow configuration of an oauth endpoint in TomEE and then
>>> defining security-constraint in the web.xml of a webapp? seems like a good
>>> plan if it drops the need for 3rd party libs
>>>
>> Very close. It wouldn't provide an endpoint that creates JWT tokens, but
>> it would provide functionality for JWT tokens to be *validated* when passed
>> to TomEE in the "Authorization" header of any HTTP request.
>>
>> But, absolutely yes that validation would be done without the need for
>> any third-party libraries. The assumption is that TomEE would need to be
>> given the RSA public key corresponding to the private key the token server
>> used to create the JWT.
>>
>> After validation, there are three groups of additional features to make
>> things convenient for developers:
>>
>> - Identity: The server is required to propagate the JWT `sub` to
>> getCallerPrinciple() and similar existing calls in various Java EE apis
>>
>> - Permissions: `@RolesAllowed` finally becomes useful as the server is
>> required to honor the JWT `scopes` claim in uses of `@RolesAllowed` and
>> `isCallerInRole()`
>>
>> - Claims: Any other values of the incoming JWT can be injected into
>> your code via CDI `@Inject @Claim("foo")` as a handful of different data
>> types. I.e. you can use it as a secure cookie if you want and do not need
>> to write any parsing code.
>>
>> You still need something to create the tokens, which could be done with
>> an API Gateway or some code you write. You wouldn't put that code on all
>> microservices as the power of JWT is that there's one source of identity
>> that the enterprise trusts so that should be some fairly small set of very
>> secure servers who hold the private key and do not share it.
>>
>> Hope that puts some color on it. We'll want to document the feature and
>> this is a good start, so more questions the better.
>>
>>
>> -David
>>
>>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
thanks for the more detailed explanation and it is good that
@RolesAllowed will finally work.
by "configuration of an oauth endpoint" i meant that the user could
define an endpoint in config that would allow TomEE to use that as as a
security provider. i.e. not using TomEE itself as a security provider.
in keycloak a realm client has a "keycloak OIDC JSON" file that is
created through the user interface. this is dropped into the webapp and
a valve has to be setup in context.xml
<Context path="/your-context-path">
<Valve
className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>
</Context>
i just wondered if it was similar. are there any docs?
On 29/03/2018 04:00, David Blevins wrote:
>> On Mar 28, 2018, at 1:22 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>>
>> would it allow configuration of an oauth endpoint in TomEE and then defining security-constraint in the web.xml of a webapp? seems like a good plan if it drops the need for 3rd party libs
> Very close. It wouldn't provide an endpoint that creates JWT tokens, but it would provide functionality for JWT tokens to be *validated* when passed to TomEE in the "Authorization" header of any HTTP request.
>
> But, absolutely yes that validation would be done without the need for any third-party libraries. The assumption is that TomEE would need to be given the RSA public key corresponding to the private key the token server used to create the JWT.
>
> After validation, there are three groups of additional features to make things convenient for developers:
>
> - Identity: The server is required to propagate the JWT `sub` to getCallerPrinciple() and similar existing calls in various Java EE apis
>
> - Permissions: `@RolesAllowed` finally becomes useful as the server is required to honor the JWT `scopes` claim in uses of `@RolesAllowed` and `isCallerInRole()`
>
> - Claims: Any other values of the incoming JWT can be injected into your code via CDI `@Inject @Claim("foo")` as a handful of different data types. I.e. you can use it as a secure cookie if you want and do not need to write any parsing code.
>
> You still need something to create the tokens, which could be done with an API Gateway or some code you write. You wouldn't put that code on all microservices as the power of JWT is that there's one source of identity that the enterprise trusts so that should be some fairly small set of very secure servers who hold the private key and do not share it.
>
> Hope that puts some color on it. We'll want to document the feature and this is a good start, so more questions the better.
>
>
> -David
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
> On Mar 28, 2018, at 1:22 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>
> would it allow configuration of an oauth endpoint in TomEE and then defining security-constraint in the web.xml of a webapp? seems like a good plan if it drops the need for 3rd party libs
Very close. It wouldn't provide an endpoint that creates JWT tokens, but it would provide functionality for JWT tokens to be *validated* when passed to TomEE in the "Authorization" header of any HTTP request.
But, absolutely yes that validation would be done without the need for any third-party libraries. The assumption is that TomEE would need to be given the RSA public key corresponding to the private key the token server used to create the JWT.
After validation, there are three groups of additional features to make things convenient for developers:
- Identity: The server is required to propagate the JWT `sub` to getCallerPrinciple() and similar existing calls in various Java EE apis
- Permissions: `@RolesAllowed` finally becomes useful as the server is required to honor the JWT `scopes` claim in uses of `@RolesAllowed` and `isCallerInRole()`
- Claims: Any other values of the incoming JWT can be injected into your code via CDI `@Inject @Claim("foo")` as a handful of different data types. I.e. you can use it as a secure cookie if you want and do not need to write any parsing code.
You still need something to create the tokens, which could be done with an API Gateway or some code you write. You wouldn't put that code on all microservices as the power of JWT is that there's one source of identity that the enterprise trusts so that should be some fairly small set of very secure servers who hold the private key and do not share it.
Hope that puts some color on it. We'll want to document the feature and this is a good start, so more questions the better.
-David
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-03-28 10:22 GMT+02:00 Matthew Broadhead <matthew.broadhead@nbmlaw.co.uk
>:
> would it allow configuration of an oauth endpoint in TomEE and then
> defining security-constraint in the web.xml of a webapp? seems like a good
> plan if it drops the need for 3rd party libs
It is a "client" lib and in web.xml you can put "MP-JWT" to ensure the JWT
are validated and propagated to the request. (= validation side, not
emittion)
>
>
> On 28/03/2018 10:15, Romain Manni-Bucau wrote:
>
>> Hi Matthew,
>>
>> it is an impl of https://github.com/eclipse/microprofile-jwt-auth
>>
>> Normally with a JWT you can drop these things as well - can need some
>> wrapper to handle the representation in a less raw way but nothing crazy.
>>
>>
>> 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-03-28 10:10 GMT+02:00 Matthew Broadhead <
>> matthew.broadhead@nbmlaw.co.uk
>>
>>> :
>>> is this about JSON web tokens or some other JWT?
>>> is this JWT library similar to something like the keycloak tomcat
>>> adapter?
>>> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
>>> ava/tomcat-adapter.html
>>> if so is there a specification on this and do different IDPs handle this
>>> differently. i.e. if TomEE had a JWT adapter would it no longer need the
>>> keycloak adapter?
>>> for instance the keycloak includes structures like UserRepresentation,
>>> RoleRepresentation, CredentialRepresentation. would this be handled in a
>>> new JWT lib?
>>>
>>>
>>> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
>>>
>>> Roberto PR *is* merged JL.
>>>> He did the work to be able to consume any CDI "container" lib.
>>>>
>>>> So I'd just extract the code as we discussed together in G before that
>>>> mess
>>>> and move forward to keep TCK and add the lib in the MP distro Roberto
>>>> created to fit that design.
>>>>
>>>> As soon as you imported the lib in G, I will make sure to help to make
>>>> it
>>>> releasable.
>>>>
>>>> As the ee concurrency utilities dev I can guarantee you it is wrong to
>>>> put
>>>> it in TomEE :( - mea culpa here.
>>>>
>>>> I can understand the "i cant commit" but you can PR and several of these
>>>> objections are coming from people willing RTC which leads to the same
>>>> blocking state so not sure I get the rational to break projects here and
>>>> make them messy which would deserve asf IMHO.
>>>>
>>>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <
>>>> jonathan.gallimore@gmail.com
>>>> a écrit :
>>>>
>>>> If it can sit in its own repository, and that improves re-usability,
>>>> that
>>>>
>>>>> sounds like a good thing to me. I'd be happy with that under the TomEE
>>>>> TLP.
>>>>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>>>>> committer, I am not yet a Geronimo committer (maybe someday....) so I
>>>>> would
>>>>> lean towards TomEE. Wherever it sits, it needs to be possible to work
>>>>> on
>>>>> it
>>>>> without being blocked.
>>>>>
>>>>> Jon
>>>>>
>>>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>>>>> jlmonteiro@tomitribe.com> wrote:
>>>>>
>>>>> What about this vote David?
>>>>>
>>>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>>>>>>
>>>>>> not
>>>>>
>>>>> merged.
>>>>>> Most of the JWT code is server independent and therefor could be
>>>>>>
>>>>>> extracted
>>>>>
>>>>> into a separate library.
>>>>>>
>>>>>> So where the code sits is definitely a question we need to address.
>>>>>> I don't believe the current TomEE repo is a good home.
>>>>>>
>>>>>> TomEE as the Apache TLP can on the other hand become an home.
>>>>>> We only need another another repo where we could put some reusable
>>>>>> code.
>>>>>>
>>>>>> There are a couple of utility classes in TomEE that could also become
>>>>>> a
>>>>>> reusable library.
>>>>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon
>>>>>> donation.
>>>>>>
>>>>>> So I would probably propose to create a dedicated git repo where we
>>>>>> could
>>>>>> put all the reusable parts.
>>>>>> One benefit I see is that we could make the TomEE codebase a bit
>>>>>> lighter.
>>>>>>
>>>>>> What do you guys think?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Louis Monteiro
>>>>>> http://twitter.com/jlouismonteiro
>>>>>> http://www.tomitribe.com
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
>>>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>>>
>>>>>> does this mean a reusable JWT library external to TomEE, or within the
>>>>>>
>>>>>>> TomEE project?
>>>>>>> i have to agree with previous statements i read that TomEE is a
>>>>>>> bundle
>>>>>>>
>>>>>>> of
>>>>>> libraries and not really the place to locate reusable pluggable
>>>>>> projects.
>>>>>> it is more like the place where you might plug a project in once it is
>>>>>>
>>>>>>> working
>>>>>>>
>>>>>>>
>>>>>>> On 19/03/2018 11:39, Jonathan Gallimore wrote:
>>>>>>>
>>>>>>> What's the other vote ("Geronimo one")?
>>>>>>>
>>>>>>>> Jon
>>>>>>>>
>>>>>>>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hey David,
>>>>>>>>
>>>>>>>> How does this vote relates to the geronimo one you launched?
>>>>>>>>>
>>>>>>>>> Are they purely concurrent or can they be conditional one for the
>>>>>>>>>
>>>>>>>>> other?
>>>>>>>>
>>>>>>>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>> The vote for merging PR 123 does not address community will on what
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>
>>>>>>> do
>>>>>>
>>>>>> with the code beyond merging it. One can realistically vote +1 to
>>>>>>>
>>>>>>>> merge
>>>>>>>>>
>>>>>>>> the code, but then desire to see the code cleaned up and moved
>>>>>>>
>>>>>>>> elsewhere.
>>>>>>>>>> One can realistically desire seeing an attempt to clean up the
>>>>>>>>>> code
>>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>
>>>>>>>> find
>>>>>>
>>>>>>> what is reusable and may wish to withhold a final decision until we
>>>>>>>>> see
>>>>>>>>>
>>>>>>>> how
>>>>>>>
>>>>>>>> fruitful such a module would be.
>>>>>>>>>
>>>>>>>>>> Out of respect for people who may not know exactly how they feel
>>>>>>>>>>
>>>>>>>>>> (TomEE
>>>>>>>>>
>>>>>>>> or
>>>>>>>
>>>>>>>> Geronimo), this is a vote for the latter.
>>>>>>>>>
>>>>>>>>>> Vote: Should we attempt to extract code from the JWT PR to see
>>>>>>>>>> what
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>
>>>>>>>> reusable and how successful such a jar would be?
>>>>>>
>>>>>>> +1 Let's give it a shot here
>>>>>>>>>> +-0
>>>>>>>>>> -1 Let's do this elsewhere
>>>>>>>>>>
>>>>>>>>>> If the vote is +1 to attempt an extraction of reusable code here,
>>>>>>>>>>
>>>>>>>>>> final
>>>>>>>>>
>>>>>>>> conclusion of if that extraction is worth it or where it should live
>>>>>>>
>>>>>>>> is
>>>>>>>>>
>>>>>>>> not
>>>>>>>
>>>>>>>> being voted on. People are welcome to decide differently based on
>>>>>>>>> the
>>>>>>>>>
>>>>>>>> results of the exercise.
>>>>>>
>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Jon: drop some SE style code to move to CDI style and allow apps to
override "naturally" impls + droppring jose dep are the main ones. Some
optim in the Bean impl should pby be planned too but can need some more
investment and are less blocking for a 1.0.0.
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-03-28 10:46 GMT+02:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
> Yes it would allow that.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Wed, Mar 28, 2018 at 10:22 AM, Matthew Broadhead <
> matthew.broadhead@nbmlaw.co.uk> wrote:
>
> > would it allow configuration of an oauth endpoint in TomEE and then
> > defining security-constraint in the web.xml of a webapp? seems like a
> good
> > plan if it drops the need for 3rd party libs
> >
> >
> > On 28/03/2018 10:15, Romain Manni-Bucau wrote:
> >
> >> Hi Matthew,
> >>
> >> it is an impl of https://github.com/eclipse/microprofile-jwt-auth
> >>
> >> Normally with a JWT you can drop these things as well - can need some
> >> wrapper to handle the representation in a less raw way but nothing
> crazy.
> >>
> >>
> >> 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-03-28 10:10 GMT+02:00 Matthew Broadhead <
> >> matthew.broadhead@nbmlaw.co.uk
> >>
> >>> :
> >>> is this about JSON web tokens or some other JWT?
> >>> is this JWT library similar to something like the keycloak tomcat
> >>> adapter?
> >>> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
> >>> ava/tomcat-adapter.html
> >>> if so is there a specification on this and do different IDPs handle
> this
> >>> differently. i.e. if TomEE had a JWT adapter would it no longer need
> the
> >>> keycloak adapter?
> >>> for instance the keycloak includes structures like UserRepresentation,
> >>> RoleRepresentation, CredentialRepresentation. would this be handled in
> a
> >>> new JWT lib?
> >>>
> >>>
> >>> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
> >>>
> >>> Roberto PR *is* merged JL.
> >>>> He did the work to be able to consume any CDI "container" lib.
> >>>>
> >>>> So I'd just extract the code as we discussed together in G before that
> >>>> mess
> >>>> and move forward to keep TCK and add the lib in the MP distro Roberto
> >>>> created to fit that design.
> >>>>
> >>>> As soon as you imported the lib in G, I will make sure to help to make
> >>>> it
> >>>> releasable.
> >>>>
> >>>> As the ee concurrency utilities dev I can guarantee you it is wrong to
> >>>> put
> >>>> it in TomEE :( - mea culpa here.
> >>>>
> >>>> I can understand the "i cant commit" but you can PR and several of
> these
> >>>> objections are coming from people willing RTC which leads to the same
> >>>> blocking state so not sure I get the rational to break projects here
> and
> >>>> make them messy which would deserve asf IMHO.
> >>>>
> >>>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <
> >>>> jonathan.gallimore@gmail.com
> >>>> a écrit :
> >>>>
> >>>> If it can sit in its own repository, and that improves re-usability,
> >>>> that
> >>>>
> >>>>> sounds like a good thing to me. I'd be happy with that under the
> TomEE
> >>>>> TLP.
> >>>>> I am sure some folks will prefer to see it under Geronimo. I am a
> TomEE
> >>>>> committer, I am not yet a Geronimo committer (maybe someday....) so I
> >>>>> would
> >>>>> lean towards TomEE. Wherever it sits, it needs to be possible to work
> >>>>> on
> >>>>> it
> >>>>> without being blocked.
> >>>>>
> >>>>> Jon
> >>>>>
> >>>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
> >>>>> jlmonteiro@tomitribe.com> wrote:
> >>>>>
> >>>>> What about this vote David?
> >>>>>
> >>>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are
> still
> >>>>>>
> >>>>>> not
> >>>>>
> >>>>> merged.
> >>>>>> Most of the JWT code is server independent and therefor could be
> >>>>>>
> >>>>>> extracted
> >>>>>
> >>>>> into a separate library.
> >>>>>>
> >>>>>> So where the code sits is definitely a question we need to address.
> >>>>>> I don't believe the current TomEE repo is a good home.
> >>>>>>
> >>>>>> TomEE as the Apache TLP can on the other hand become an home.
> >>>>>> We only need another another repo where we could put some reusable
> >>>>>> code.
> >>>>>>
> >>>>>> There are a couple of utility classes in TomEE that could also
> become
> >>>>>> a
> >>>>>> reusable library.
> >>>>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon
> >>>>>> donation.
> >>>>>>
> >>>>>> So I would probably propose to create a dedicated git repo where we
> >>>>>> could
> >>>>>> put all the reusable parts.
> >>>>>> One benefit I see is that we could make the TomEE codebase a bit
> >>>>>> lighter.
> >>>>>>
> >>>>>> What do you guys think?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Jean-Louis Monteiro
> >>>>>> http://twitter.com/jlouismonteiro
> >>>>>> http://www.tomitribe.com
> >>>>>>
> >>>>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
> >>>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
> >>>>>>
> >>>>>> does this mean a reusable JWT library external to TomEE, or within
> the
> >>>>>>
> >>>>>>> TomEE project?
> >>>>>>> i have to agree with previous statements i read that TomEE is a
> >>>>>>> bundle
> >>>>>>>
> >>>>>>> of
> >>>>>> libraries and not really the place to locate reusable pluggable
> >>>>>> projects.
> >>>>>> it is more like the place where you might plug a project in once it
> is
> >>>>>>
> >>>>>>> working
> >>>>>>>
> >>>>>>>
> >>>>>>> On 19/03/2018 11:39, Jonathan Gallimore wrote:
> >>>>>>>
> >>>>>>> What's the other vote ("Geronimo one")?
> >>>>>>>
> >>>>>>>> Jon
> >>>>>>>>
> >>>>>>>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
> >>>>>>>> rmannibucau@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hey David,
> >>>>>>>>
> >>>>>>>> How does this vote relates to the geronimo one you launched?
> >>>>>>>>>
> >>>>>>>>> Are they purely concurrent or can they be conditional one for the
> >>>>>>>>>
> >>>>>>>>> other?
> >>>>>>>>
> >>>>>>>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com>
> a
> >>>>>>>>> écrit :
> >>>>>>>>>
> >>>>>>>>> The vote for merging PR 123 does not address community will on
> what
> >>>>>>>>>
> >>>>>>>>> to
> >>>>>>>>
> >>>>>>> do
> >>>>>>
> >>>>>> with the code beyond merging it. One can realistically vote +1 to
> >>>>>>>
> >>>>>>>> merge
> >>>>>>>>>
> >>>>>>>> the code, but then desire to see the code cleaned up and moved
> >>>>>>>
> >>>>>>>> elsewhere.
> >>>>>>>>>> One can realistically desire seeing an attempt to clean up the
> >>>>>>>>>> code
> >>>>>>>>>>
> >>>>>>>>>> to
> >>>>>>>>>
> >>>>>>>> find
> >>>>>>
> >>>>>>> what is reusable and may wish to withhold a final decision until we
> >>>>>>>>> see
> >>>>>>>>>
> >>>>>>>> how
> >>>>>>>
> >>>>>>>> fruitful such a module would be.
> >>>>>>>>>
> >>>>>>>>>> Out of respect for people who may not know exactly how they feel
> >>>>>>>>>>
> >>>>>>>>>> (TomEE
> >>>>>>>>>
> >>>>>>>> or
> >>>>>>>
> >>>>>>>> Geronimo), this is a vote for the latter.
> >>>>>>>>>
> >>>>>>>>>> Vote: Should we attempt to extract code from the JWT PR to see
> >>>>>>>>>> what
> >>>>>>>>>>
> >>>>>>>>>> is
> >>>>>>>>>
> >>>>>>>> reusable and how successful such a jar would be?
> >>>>>>
> >>>>>>> +1 Let's give it a shot here
> >>>>>>>>>> +-0
> >>>>>>>>>> -1 Let's do this elsewhere
> >>>>>>>>>>
> >>>>>>>>>> If the vote is +1 to attempt an extraction of reusable code
> here,
> >>>>>>>>>>
> >>>>>>>>>> final
> >>>>>>>>>
> >>>>>>>> conclusion of if that extraction is worth it or where it should
> live
> >>>>>>>
> >>>>>>>> is
> >>>>>>>>>
> >>>>>>>> not
> >>>>>>>
> >>>>>>>> being voted on. People are welcome to decide differently based on
> >>>>>>>>> the
> >>>>>>>>>
> >>>>>>>> results of the exercise.
> >>>>>>
> >>>>>>>
> >>>>>>>>>> -David
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Yes it would allow that.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Mar 28, 2018 at 10:22 AM, Matthew Broadhead <
matthew.broadhead@nbmlaw.co.uk> wrote:
> would it allow configuration of an oauth endpoint in TomEE and then
> defining security-constraint in the web.xml of a webapp? seems like a good
> plan if it drops the need for 3rd party libs
>
>
> On 28/03/2018 10:15, Romain Manni-Bucau wrote:
>
>> Hi Matthew,
>>
>> it is an impl of https://github.com/eclipse/microprofile-jwt-auth
>>
>> Normally with a JWT you can drop these things as well - can need some
>> wrapper to handle the representation in a less raw way but nothing crazy.
>>
>>
>> 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-03-28 10:10 GMT+02:00 Matthew Broadhead <
>> matthew.broadhead@nbmlaw.co.uk
>>
>>> :
>>> is this about JSON web tokens or some other JWT?
>>> is this JWT library similar to something like the keycloak tomcat
>>> adapter?
>>> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
>>> ava/tomcat-adapter.html
>>> if so is there a specification on this and do different IDPs handle this
>>> differently. i.e. if TomEE had a JWT adapter would it no longer need the
>>> keycloak adapter?
>>> for instance the keycloak includes structures like UserRepresentation,
>>> RoleRepresentation, CredentialRepresentation. would this be handled in a
>>> new JWT lib?
>>>
>>>
>>> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
>>>
>>> Roberto PR *is* merged JL.
>>>> He did the work to be able to consume any CDI "container" lib.
>>>>
>>>> So I'd just extract the code as we discussed together in G before that
>>>> mess
>>>> and move forward to keep TCK and add the lib in the MP distro Roberto
>>>> created to fit that design.
>>>>
>>>> As soon as you imported the lib in G, I will make sure to help to make
>>>> it
>>>> releasable.
>>>>
>>>> As the ee concurrency utilities dev I can guarantee you it is wrong to
>>>> put
>>>> it in TomEE :( - mea culpa here.
>>>>
>>>> I can understand the "i cant commit" but you can PR and several of these
>>>> objections are coming from people willing RTC which leads to the same
>>>> blocking state so not sure I get the rational to break projects here and
>>>> make them messy which would deserve asf IMHO.
>>>>
>>>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <
>>>> jonathan.gallimore@gmail.com
>>>> a écrit :
>>>>
>>>> If it can sit in its own repository, and that improves re-usability,
>>>> that
>>>>
>>>>> sounds like a good thing to me. I'd be happy with that under the TomEE
>>>>> TLP.
>>>>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>>>>> committer, I am not yet a Geronimo committer (maybe someday....) so I
>>>>> would
>>>>> lean towards TomEE. Wherever it sits, it needs to be possible to work
>>>>> on
>>>>> it
>>>>> without being blocked.
>>>>>
>>>>> Jon
>>>>>
>>>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>>>>> jlmonteiro@tomitribe.com> wrote:
>>>>>
>>>>> What about this vote David?
>>>>>
>>>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>>>>>>
>>>>>> not
>>>>>
>>>>> merged.
>>>>>> Most of the JWT code is server independent and therefor could be
>>>>>>
>>>>>> extracted
>>>>>
>>>>> into a separate library.
>>>>>>
>>>>>> So where the code sits is definitely a question we need to address.
>>>>>> I don't believe the current TomEE repo is a good home.
>>>>>>
>>>>>> TomEE as the Apache TLP can on the other hand become an home.
>>>>>> We only need another another repo where we could put some reusable
>>>>>> code.
>>>>>>
>>>>>> There are a couple of utility classes in TomEE that could also become
>>>>>> a
>>>>>> reusable library.
>>>>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon
>>>>>> donation.
>>>>>>
>>>>>> So I would probably propose to create a dedicated git repo where we
>>>>>> could
>>>>>> put all the reusable parts.
>>>>>> One benefit I see is that we could make the TomEE codebase a bit
>>>>>> lighter.
>>>>>>
>>>>>> What do you guys think?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Louis Monteiro
>>>>>> http://twitter.com/jlouismonteiro
>>>>>> http://www.tomitribe.com
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
>>>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>>>
>>>>>> does this mean a reusable JWT library external to TomEE, or within the
>>>>>>
>>>>>>> TomEE project?
>>>>>>> i have to agree with previous statements i read that TomEE is a
>>>>>>> bundle
>>>>>>>
>>>>>>> of
>>>>>> libraries and not really the place to locate reusable pluggable
>>>>>> projects.
>>>>>> it is more like the place where you might plug a project in once it is
>>>>>>
>>>>>>> working
>>>>>>>
>>>>>>>
>>>>>>> On 19/03/2018 11:39, Jonathan Gallimore wrote:
>>>>>>>
>>>>>>> What's the other vote ("Geronimo one")?
>>>>>>>
>>>>>>>> Jon
>>>>>>>>
>>>>>>>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hey David,
>>>>>>>>
>>>>>>>> How does this vote relates to the geronimo one you launched?
>>>>>>>>>
>>>>>>>>> Are they purely concurrent or can they be conditional one for the
>>>>>>>>>
>>>>>>>>> other?
>>>>>>>>
>>>>>>>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>> The vote for merging PR 123 does not address community will on what
>>>>>>>>>
>>>>>>>>> to
>>>>>>>>
>>>>>>> do
>>>>>>
>>>>>> with the code beyond merging it. One can realistically vote +1 to
>>>>>>>
>>>>>>>> merge
>>>>>>>>>
>>>>>>>> the code, but then desire to see the code cleaned up and moved
>>>>>>>
>>>>>>>> elsewhere.
>>>>>>>>>> One can realistically desire seeing an attempt to clean up the
>>>>>>>>>> code
>>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>
>>>>>>>> find
>>>>>>
>>>>>>> what is reusable and may wish to withhold a final decision until we
>>>>>>>>> see
>>>>>>>>>
>>>>>>>> how
>>>>>>>
>>>>>>>> fruitful such a module would be.
>>>>>>>>>
>>>>>>>>>> Out of respect for people who may not know exactly how they feel
>>>>>>>>>>
>>>>>>>>>> (TomEE
>>>>>>>>>
>>>>>>>> or
>>>>>>>
>>>>>>>> Geronimo), this is a vote for the latter.
>>>>>>>>>
>>>>>>>>>> Vote: Should we attempt to extract code from the JWT PR to see
>>>>>>>>>> what
>>>>>>>>>>
>>>>>>>>>> is
>>>>>>>>>
>>>>>>>> reusable and how successful such a jar would be?
>>>>>>
>>>>>>> +1 Let's give it a shot here
>>>>>>>>>> +-0
>>>>>>>>>> -1 Let's do this elsewhere
>>>>>>>>>>
>>>>>>>>>> If the vote is +1 to attempt an extraction of reusable code here,
>>>>>>>>>>
>>>>>>>>>> final
>>>>>>>>>
>>>>>>>> conclusion of if that extraction is worth it or where it should live
>>>>>>>
>>>>>>>> is
>>>>>>>>>
>>>>>>>> not
>>>>>>>
>>>>>>>> being voted on. People are welcome to decide differently based on
>>>>>>>>> the
>>>>>>>>>
>>>>>>>> results of the exercise.
>>>>>>
>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
would it allow configuration of an oauth endpoint in TomEE and then
defining security-constraint in the web.xml of a webapp? seems like a
good plan if it drops the need for 3rd party libs
On 28/03/2018 10:15, Romain Manni-Bucau wrote:
> Hi Matthew,
>
> it is an impl of https://github.com/eclipse/microprofile-jwt-auth
>
> Normally with a JWT you can drop these things as well - can need some
> wrapper to handle the representation in a less raw way but nothing crazy.
>
>
> 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-03-28 10:10 GMT+02:00 Matthew Broadhead <matthew.broadhead@nbmlaw.co.uk
>> :
>> is this about JSON web tokens or some other JWT?
>> is this JWT library similar to something like the keycloak tomcat adapter?
>> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
>> ava/tomcat-adapter.html
>> if so is there a specification on this and do different IDPs handle this
>> differently. i.e. if TomEE had a JWT adapter would it no longer need the
>> keycloak adapter?
>> for instance the keycloak includes structures like UserRepresentation,
>> RoleRepresentation, CredentialRepresentation. would this be handled in a
>> new JWT lib?
>>
>>
>> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
>>
>>> Roberto PR *is* merged JL.
>>> He did the work to be able to consume any CDI "container" lib.
>>>
>>> So I'd just extract the code as we discussed together in G before that
>>> mess
>>> and move forward to keep TCK and add the lib in the MP distro Roberto
>>> created to fit that design.
>>>
>>> As soon as you imported the lib in G, I will make sure to help to make it
>>> releasable.
>>>
>>> As the ee concurrency utilities dev I can guarantee you it is wrong to put
>>> it in TomEE :( - mea culpa here.
>>>
>>> I can understand the "i cant commit" but you can PR and several of these
>>> objections are coming from people willing RTC which leads to the same
>>> blocking state so not sure I get the rational to break projects here and
>>> make them messy which would deserve asf IMHO.
>>>
>>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <jonathan.gallimore@gmail.com
>>> a écrit :
>>>
>>> If it can sit in its own repository, and that improves re-usability, that
>>>> sounds like a good thing to me. I'd be happy with that under the TomEE
>>>> TLP.
>>>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>>>> committer, I am not yet a Geronimo committer (maybe someday....) so I
>>>> would
>>>> lean towards TomEE. Wherever it sits, it needs to be possible to work on
>>>> it
>>>> without being blocked.
>>>>
>>>> Jon
>>>>
>>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>>>> jlmonteiro@tomitribe.com> wrote:
>>>>
>>>> What about this vote David?
>>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>>>>>
>>>> not
>>>>
>>>>> merged.
>>>>> Most of the JWT code is server independent and therefor could be
>>>>>
>>>> extracted
>>>>
>>>>> into a separate library.
>>>>>
>>>>> So where the code sits is definitely a question we need to address.
>>>>> I don't believe the current TomEE repo is a good home.
>>>>>
>>>>> TomEE as the Apache TLP can on the other hand become an home.
>>>>> We only need another another repo where we could put some reusable code.
>>>>>
>>>>> There are a couple of utility classes in TomEE that could also become a
>>>>> reusable library.
>>>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon
>>>>> donation.
>>>>>
>>>>> So I would probably propose to create a dedicated git repo where we
>>>>> could
>>>>> put all the reusable parts.
>>>>> One benefit I see is that we could make the TomEE codebase a bit
>>>>> lighter.
>>>>>
>>>>> What do you guys think?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jean-Louis Monteiro
>>>>> http://twitter.com/jlouismonteiro
>>>>> http://www.tomitribe.com
>>>>>
>>>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
>>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>>
>>>>> does this mean a reusable JWT library external to TomEE, or within the
>>>>>> TomEE project?
>>>>>> i have to agree with previous statements i read that TomEE is a bundle
>>>>>>
>>>>> of
>>>>> libraries and not really the place to locate reusable pluggable
>>>>> projects.
>>>>> it is more like the place where you might plug a project in once it is
>>>>>> working
>>>>>>
>>>>>>
>>>>>> On 19/03/2018 11:39, Jonathan Gallimore wrote:
>>>>>>
>>>>>> What's the other vote ("Geronimo one")?
>>>>>>> Jon
>>>>>>>
>>>>>>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hey David,
>>>>>>>
>>>>>>>> How does this vote relates to the geronimo one you launched?
>>>>>>>>
>>>>>>>> Are they purely concurrent or can they be conditional one for the
>>>>>>>>
>>>>>>> other?
>>>>>>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>> The vote for merging PR 123 does not address community will on what
>>>>>>>>
>>>>>>> to
>>>>> do
>>>>>
>>>>>> with the code beyond merging it. One can realistically vote +1 to
>>>>>>>> merge
>>>>>> the code, but then desire to see the code cleaned up and moved
>>>>>>>>> elsewhere.
>>>>>>>>> One can realistically desire seeing an attempt to clean up the code
>>>>>>>>>
>>>>>>>> to
>>>>> find
>>>>>>>> what is reusable and may wish to withhold a final decision until we
>>>>>>>> see
>>>>>> how
>>>>>>>> fruitful such a module would be.
>>>>>>>>> Out of respect for people who may not know exactly how they feel
>>>>>>>>>
>>>>>>>> (TomEE
>>>>>> or
>>>>>>>> Geronimo), this is a vote for the latter.
>>>>>>>>> Vote: Should we attempt to extract code from the JWT PR to see what
>>>>>>>>>
>>>>>>>> is
>>>>> reusable and how successful such a jar would be?
>>>>>>>>> +1 Let's give it a shot here
>>>>>>>>> +-0
>>>>>>>>> -1 Let's do this elsewhere
>>>>>>>>>
>>>>>>>>> If the vote is +1 to attempt an extraction of reusable code here,
>>>>>>>>>
>>>>>>>> final
>>>>>> conclusion of if that extraction is worth it or where it should live
>>>>>>>> is
>>>>>> not
>>>>>>>> being voted on. People are welcome to decide differently based on
>>>>>>>> the
>>>>> results of the exercise.
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Matthew,
it is an impl of https://github.com/eclipse/microprofile-jwt-auth
Normally with a JWT you can drop these things as well - can need some
wrapper to handle the representation in a less raw way but nothing crazy.
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-03-28 10:10 GMT+02:00 Matthew Broadhead <matthew.broadhead@nbmlaw.co.uk
>:
> is this about JSON web tokens or some other JWT?
> is this JWT library similar to something like the keycloak tomcat adapter?
> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
> ava/tomcat-adapter.html
> if so is there a specification on this and do different IDPs handle this
> differently. i.e. if TomEE had a JWT adapter would it no longer need the
> keycloak adapter?
> for instance the keycloak includes structures like UserRepresentation,
> RoleRepresentation, CredentialRepresentation. would this be handled in a
> new JWT lib?
>
>
> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
>
>> Roberto PR *is* merged JL.
>> He did the work to be able to consume any CDI "container" lib.
>>
>> So I'd just extract the code as we discussed together in G before that
>> mess
>> and move forward to keep TCK and add the lib in the MP distro Roberto
>> created to fit that design.
>>
>> As soon as you imported the lib in G, I will make sure to help to make it
>> releasable.
>>
>> As the ee concurrency utilities dev I can guarantee you it is wrong to put
>> it in TomEE :( - mea culpa here.
>>
>> I can understand the "i cant commit" but you can PR and several of these
>> objections are coming from people willing RTC which leads to the same
>> blocking state so not sure I get the rational to break projects here and
>> make them messy which would deserve asf IMHO.
>>
>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <jonathan.gallimore@gmail.com
>> >
>> a écrit :
>>
>> If it can sit in its own repository, and that improves re-usability, that
>>> sounds like a good thing to me. I'd be happy with that under the TomEE
>>> TLP.
>>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>>> committer, I am not yet a Geronimo committer (maybe someday....) so I
>>> would
>>> lean towards TomEE. Wherever it sits, it needs to be possible to work on
>>> it
>>> without being blocked.
>>>
>>> Jon
>>>
>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com> wrote:
>>>
>>> What about this vote David?
>>>>
>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>>>>
>>> not
>>>
>>>> merged.
>>>> Most of the JWT code is server independent and therefor could be
>>>>
>>> extracted
>>>
>>>> into a separate library.
>>>>
>>>> So where the code sits is definitely a question we need to address.
>>>> I don't believe the current TomEE repo is a good home.
>>>>
>>>> TomEE as the Apache TLP can on the other hand become an home.
>>>> We only need another another repo where we could put some reusable code.
>>>>
>>>> There are a couple of utility classes in TomEE that could also become a
>>>> reusable library.
>>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon
>>>> donation.
>>>>
>>>> So I would probably propose to create a dedicated git repo where we
>>>> could
>>>> put all the reusable parts.
>>>> One benefit I see is that we could make the TomEE codebase a bit
>>>> lighter.
>>>>
>>>> What do you guys think?
>>>>
>>>>
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>
>>>> does this mean a reusable JWT library external to TomEE, or within the
>>>>> TomEE project?
>>>>> i have to agree with previous statements i read that TomEE is a bundle
>>>>>
>>>> of
>>>
>>>> libraries and not really the place to locate reusable pluggable
>>>>>
>>>> projects.
>>>
>>>> it is more like the place where you might plug a project in once it is
>>>>> working
>>>>>
>>>>>
>>>>> On 19/03/2018 11:39, Jonathan Gallimore wrote:
>>>>>
>>>>> What's the other vote ("Geronimo one")?
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hey David,
>>>>>>
>>>>>>> How does this vote relates to the geronimo one you launched?
>>>>>>>
>>>>>>> Are they purely concurrent or can they be conditional one for the
>>>>>>>
>>>>>> other?
>>>>
>>>>>
>>>>>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>> The vote for merging PR 123 does not address community will on what
>>>>>>>
>>>>>> to
>>>
>>>> do
>>>>
>>>>> with the code beyond merging it. One can realistically vote +1 to
>>>>>>>>
>>>>>>> merge
>>>>
>>>>> the code, but then desire to see the code cleaned up and moved
>>>>>>>> elsewhere.
>>>>>>>> One can realistically desire seeing an attempt to clean up the code
>>>>>>>>
>>>>>>> to
>>>
>>>> find
>>>>>>>
>>>>>>> what is reusable and may wish to withhold a final decision until we
>>>>>>>>
>>>>>>> see
>>>>
>>>>> how
>>>>>>>
>>>>>>> fruitful such a module would be.
>>>>>>>>
>>>>>>>> Out of respect for people who may not know exactly how they feel
>>>>>>>>
>>>>>>> (TomEE
>>>>
>>>>> or
>>>>>>>
>>>>>>> Geronimo), this is a vote for the latter.
>>>>>>>>
>>>>>>>> Vote: Should we attempt to extract code from the JWT PR to see what
>>>>>>>>
>>>>>>> is
>>>
>>>> reusable and how successful such a jar would be?
>>>>>>>>
>>>>>>>> +1 Let's give it a shot here
>>>>>>>> +-0
>>>>>>>> -1 Let's do this elsewhere
>>>>>>>>
>>>>>>>> If the vote is +1 to attempt an extraction of reusable code here,
>>>>>>>>
>>>>>>> final
>>>>
>>>>> conclusion of if that extraction is worth it or where it should live
>>>>>>>>
>>>>>>> is
>>>>
>>>>> not
>>>>>>>
>>>>>>> being voted on. People are welcome to decide differently based on
>>>>>>>>
>>>>>>> the
>>>
>>>> results of the exercise.
>>>>>>>>
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
is this about JSON web tokens or some other JWT?
is this JWT library similar to something like the keycloak tomcat
adapter?
http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/java/tomcat-adapter.html
if so is there a specification on this and do different IDPs handle this
differently. i.e. if TomEE had a JWT adapter would it no longer need
the keycloak adapter?
for instance the keycloak includes structures like UserRepresentation,
RoleRepresentation, CredentialRepresentation. would this be handled in a
new JWT lib?
On 28/03/2018 07:13, Romain Manni-Bucau wrote:
> Roberto PR *is* merged JL.
> He did the work to be able to consume any CDI "container" lib.
>
> So I'd just extract the code as we discussed together in G before that mess
> and move forward to keep TCK and add the lib in the MP distro Roberto
> created to fit that design.
>
> As soon as you imported the lib in G, I will make sure to help to make it
> releasable.
>
> As the ee concurrency utilities dev I can guarantee you it is wrong to put
> it in TomEE :( - mea culpa here.
>
> I can understand the "i cant commit" but you can PR and several of these
> objections are coming from people willing RTC which leads to the same
> blocking state so not sure I get the rational to break projects here and
> make them messy which would deserve asf IMHO.
>
> Le 27 mars 2018 23:37, "Jonathan Gallimore" <jo...@gmail.com>
> a écrit :
>
>> If it can sit in its own repository, and that improves re-usability, that
>> sounds like a good thing to me. I'd be happy with that under the TomEE TLP.
>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>> committer, I am not yet a Geronimo committer (maybe someday....) so I would
>> lean towards TomEE. Wherever it sits, it needs to be possible to work on it
>> without being blocked.
>>
>> Jon
>>
>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>> jlmonteiro@tomitribe.com> wrote:
>>
>>> What about this vote David?
>>>
>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>> not
>>> merged.
>>> Most of the JWT code is server independent and therefor could be
>> extracted
>>> into a separate library.
>>>
>>> So where the code sits is definitely a question we need to address.
>>> I don't believe the current TomEE repo is a good home.
>>>
>>> TomEE as the Apache TLP can on the other hand become an home.
>>> We only need another another repo where we could put some reusable code.
>>>
>>> There are a couple of utility classes in TomEE that could also become a
>>> reusable library.
>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon donation.
>>>
>>> So I would probably propose to create a dedicated git repo where we could
>>> put all the reusable parts.
>>> One benefit I see is that we could make the TomEE codebase a bit lighter.
>>>
>>> What do you guys think?
>>>
>>>
>>>
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>
>>>> does this mean a reusable JWT library external to TomEE, or within the
>>>> TomEE project?
>>>> i have to agree with previous statements i read that TomEE is a bundle
>> of
>>>> libraries and not really the place to locate reusable pluggable
>> projects.
>>>> it is more like the place where you might plug a project in once it is
>>>> working
>>>>
>>>>
>>>> On 19/03/2018 11:39, Jonathan Gallimore wrote:
>>>>
>>>>> What's the other vote ("Geronimo one")?
>>>>>
>>>>> Jon
>>>>>
>>>>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hey David,
>>>>>> How does this vote relates to the geronimo one you launched?
>>>>>>
>>>>>> Are they purely concurrent or can they be conditional one for the
>>> other?
>>>>>>
>>>>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
>>>>>> écrit :
>>>>>>
>>>>>> The vote for merging PR 123 does not address community will on what
>> to
>>> do
>>>>>>> with the code beyond merging it. One can realistically vote +1 to
>>> merge
>>>>>>> the code, but then desire to see the code cleaned up and moved
>>>>>>> elsewhere.
>>>>>>> One can realistically desire seeing an attempt to clean up the code
>> to
>>>>>> find
>>>>>>
>>>>>>> what is reusable and may wish to withhold a final decision until we
>>> see
>>>>>> how
>>>>>>
>>>>>>> fruitful such a module would be.
>>>>>>>
>>>>>>> Out of respect for people who may not know exactly how they feel
>>> (TomEE
>>>>>> or
>>>>>>
>>>>>>> Geronimo), this is a vote for the latter.
>>>>>>>
>>>>>>> Vote: Should we attempt to extract code from the JWT PR to see what
>> is
>>>>>>> reusable and how successful such a jar would be?
>>>>>>>
>>>>>>> +1 Let's give it a shot here
>>>>>>> +-0
>>>>>>> -1 Let's do this elsewhere
>>>>>>>
>>>>>>> If the vote is +1 to attempt an extraction of reusable code here,
>>> final
>>>>>>> conclusion of if that extraction is worth it or where it should live
>>> is
>>>>>> not
>>>>>>
>>>>>>> being voted on. People are welcome to decide differently based on
>> the
>>>>>>> results of the exercise.
>>>>>>>
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Roberto PR *is* merged JL.
He did the work to be able to consume any CDI "container" lib.
So I'd just extract the code as we discussed together in G before that mess
and move forward to keep TCK and add the lib in the MP distro Roberto
created to fit that design.
As soon as you imported the lib in G, I will make sure to help to make it
releasable.
As the ee concurrency utilities dev I can guarantee you it is wrong to put
it in TomEE :( - mea culpa here.
I can understand the "i cant commit" but you can PR and several of these
objections are coming from people willing RTC which leads to the same
blocking state so not sure I get the rational to break projects here and
make them messy which would deserve asf IMHO.
Le 27 mars 2018 23:37, "Jonathan Gallimore" <jo...@gmail.com>
a écrit :
> If it can sit in its own repository, and that improves re-usability, that
> sounds like a good thing to me. I'd be happy with that under the TomEE TLP.
> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
> committer, I am not yet a Geronimo committer (maybe someday....) so I would
> lean towards TomEE. Wherever it sits, it needs to be possible to work on it
> without being blocked.
>
> Jon
>
> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
> > What about this vote David?
> >
> > Roberto's PR for MP-Config integration and mine about MP-JWT are still
> not
> > merged.
> > Most of the JWT code is server independent and therefor could be
> extracted
> > into a separate library.
> >
> > So where the code sits is definitely a question we need to address.
> > I don't believe the current TomEE repo is a good home.
> >
> > TomEE as the Apache TLP can on the other hand become an home.
> > We only need another another repo where we could put some reusable code.
> >
> > There are a couple of utility classes in TomEE that could also become a
> > reusable library.
> > I have prepared and pushed the 2 PRs for Chatterbox and Sheldon donation.
> >
> > So I would probably propose to create a dedicated git repo where we could
> > put all the reusable parts.
> > One benefit I see is that we could make the TomEE codebase a bit lighter.
> >
> > What do you guys think?
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
> > matthew.broadhead@nbmlaw.co.uk> wrote:
> >
> > > does this mean a reusable JWT library external to TomEE, or within the
> > > TomEE project?
> > > i have to agree with previous statements i read that TomEE is a bundle
> of
> > > libraries and not really the place to locate reusable pluggable
> projects.
> > > it is more like the place where you might plug a project in once it is
> > > working
> > >
> > >
> > > On 19/03/2018 11:39, Jonathan Gallimore wrote:
> > >
> > >> What's the other vote ("Geronimo one")?
> > >>
> > >> Jon
> > >>
> > >> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
> > >> rmannibucau@gmail.com>
> > >> wrote:
> > >>
> > >> Hey David,
> > >>>
> > >>> How does this vote relates to the geronimo one you launched?
> > >>>
> > >>> Are they purely concurrent or can they be conditional one for the
> > other?
> > >>>
> > >>>
> > >>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
> > >>> écrit :
> > >>>
> > >>> The vote for merging PR 123 does not address community will on what
> to
> > do
> > >>>> with the code beyond merging it. One can realistically vote +1 to
> > merge
> > >>>> the code, but then desire to see the code cleaned up and moved
> > >>>> elsewhere.
> > >>>> One can realistically desire seeing an attempt to clean up the code
> to
> > >>>>
> > >>> find
> > >>>
> > >>>> what is reusable and may wish to withhold a final decision until we
> > see
> > >>>>
> > >>> how
> > >>>
> > >>>> fruitful such a module would be.
> > >>>>
> > >>>> Out of respect for people who may not know exactly how they feel
> > (TomEE
> > >>>>
> > >>> or
> > >>>
> > >>>> Geronimo), this is a vote for the latter.
> > >>>>
> > >>>> Vote: Should we attempt to extract code from the JWT PR to see what
> is
> > >>>> reusable and how successful such a jar would be?
> > >>>>
> > >>>> +1 Let's give it a shot here
> > >>>> +-0
> > >>>> -1 Let's do this elsewhere
> > >>>>
> > >>>> If the vote is +1 to attempt an extraction of reusable code here,
> > final
> > >>>> conclusion of if that extraction is worth it or where it should live
> > is
> > >>>>
> > >>> not
> > >>>
> > >>>> being voted on. People are welcome to decide differently based on
> the
> > >>>> results of the exercise.
> > >>>>
> > >>>>
> > >>>> -David
> > >>>>
> > >>>>
> > >>>>
> > >
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
If it can sit in its own repository, and that improves re-usability, that
sounds like a good thing to me. I'd be happy with that under the TomEE TLP.
I am sure some folks will prefer to see it under Geronimo. I am a TomEE
committer, I am not yet a Geronimo committer (maybe someday....) so I would
lean towards TomEE. Wherever it sits, it needs to be possible to work on it
without being blocked.
Jon
On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:
> What about this vote David?
>
> Roberto's PR for MP-Config integration and mine about MP-JWT are still not
> merged.
> Most of the JWT code is server independent and therefor could be extracted
> into a separate library.
>
> So where the code sits is definitely a question we need to address.
> I don't believe the current TomEE repo is a good home.
>
> TomEE as the Apache TLP can on the other hand become an home.
> We only need another another repo where we could put some reusable code.
>
> There are a couple of utility classes in TomEE that could also become a
> reusable library.
> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon donation.
>
> So I would probably propose to create a dedicated git repo where we could
> put all the reusable parts.
> One benefit I see is that we could make the TomEE codebase a bit lighter.
>
> What do you guys think?
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
> matthew.broadhead@nbmlaw.co.uk> wrote:
>
> > does this mean a reusable JWT library external to TomEE, or within the
> > TomEE project?
> > i have to agree with previous statements i read that TomEE is a bundle of
> > libraries and not really the place to locate reusable pluggable projects.
> > it is more like the place where you might plug a project in once it is
> > working
> >
> >
> > On 19/03/2018 11:39, Jonathan Gallimore wrote:
> >
> >> What's the other vote ("Geronimo one")?
> >>
> >> Jon
> >>
> >> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> wrote:
> >>
> >> Hey David,
> >>>
> >>> How does this vote relates to the geronimo one you launched?
> >>>
> >>> Are they purely concurrent or can they be conditional one for the
> other?
> >>>
> >>>
> >>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
> >>> écrit :
> >>>
> >>> The vote for merging PR 123 does not address community will on what to
> do
> >>>> with the code beyond merging it. One can realistically vote +1 to
> merge
> >>>> the code, but then desire to see the code cleaned up and moved
> >>>> elsewhere.
> >>>> One can realistically desire seeing an attempt to clean up the code to
> >>>>
> >>> find
> >>>
> >>>> what is reusable and may wish to withhold a final decision until we
> see
> >>>>
> >>> how
> >>>
> >>>> fruitful such a module would be.
> >>>>
> >>>> Out of respect for people who may not know exactly how they feel
> (TomEE
> >>>>
> >>> or
> >>>
> >>>> Geronimo), this is a vote for the latter.
> >>>>
> >>>> Vote: Should we attempt to extract code from the JWT PR to see what is
> >>>> reusable and how successful such a jar would be?
> >>>>
> >>>> +1 Let's give it a shot here
> >>>> +-0
> >>>> -1 Let's do this elsewhere
> >>>>
> >>>> If the vote is +1 to attempt an extraction of reusable code here,
> final
> >>>> conclusion of if that extraction is worth it or where it should live
> is
> >>>>
> >>> not
> >>>
> >>>> being voted on. People are welcome to decide differently based on the
> >>>> results of the exercise.
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>>
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
What about this vote David?
Roberto's PR for MP-Config integration and mine about MP-JWT are still not
merged.
Most of the JWT code is server independent and therefor could be extracted
into a separate library.
So where the code sits is definitely a question we need to address.
I don't believe the current TomEE repo is a good home.
TomEE as the Apache TLP can on the other hand become an home.
We only need another another repo where we could put some reusable code.
There are a couple of utility classes in TomEE that could also become a
reusable library.
I have prepared and pushed the 2 PRs for Chatterbox and Sheldon donation.
So I would probably propose to create a dedicated git repo where we could
put all the reusable parts.
One benefit I see is that we could make the TomEE codebase a bit lighter.
What do you guys think?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
matthew.broadhead@nbmlaw.co.uk> wrote:
> does this mean a reusable JWT library external to TomEE, or within the
> TomEE project?
> i have to agree with previous statements i read that TomEE is a bundle of
> libraries and not really the place to locate reusable pluggable projects.
> it is more like the place where you might plug a project in once it is
> working
>
>
> On 19/03/2018 11:39, Jonathan Gallimore wrote:
>
>> What's the other vote ("Geronimo one")?
>>
>> Jon
>>
>> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> wrote:
>>
>> Hey David,
>>>
>>> How does this vote relates to the geronimo one you launched?
>>>
>>> Are they purely concurrent or can they be conditional one for the other?
>>>
>>>
>>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a
>>> écrit :
>>>
>>> The vote for merging PR 123 does not address community will on what to do
>>>> with the code beyond merging it. One can realistically vote +1 to merge
>>>> the code, but then desire to see the code cleaned up and moved
>>>> elsewhere.
>>>> One can realistically desire seeing an attempt to clean up the code to
>>>>
>>> find
>>>
>>>> what is reusable and may wish to withhold a final decision until we see
>>>>
>>> how
>>>
>>>> fruitful such a module would be.
>>>>
>>>> Out of respect for people who may not know exactly how they feel (TomEE
>>>>
>>> or
>>>
>>>> Geronimo), this is a vote for the latter.
>>>>
>>>> Vote: Should we attempt to extract code from the JWT PR to see what is
>>>> reusable and how successful such a jar would be?
>>>>
>>>> +1 Let's give it a shot here
>>>> +-0
>>>> -1 Let's do this elsewhere
>>>>
>>>> If the vote is +1 to attempt an extraction of reusable code here, final
>>>> conclusion of if that extraction is worth it or where it should live is
>>>>
>>> not
>>>
>>>> being voted on. People are welcome to decide differently based on the
>>>> results of the exercise.
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
does this mean a reusable JWT library external to TomEE, or within the
TomEE project?
i have to agree with previous statements i read that TomEE is a bundle
of libraries and not really the place to locate reusable pluggable
projects. it is more like the place where you might plug a project in
once it is working
On 19/03/2018 11:39, Jonathan Gallimore wrote:
> What's the other vote ("Geronimo one")?
>
> Jon
>
> On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hey David,
>>
>> How does this vote relates to the geronimo one you launched?
>>
>> Are they purely concurrent or can they be conditional one for the other?
>>
>>
>> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a écrit :
>>
>>> The vote for merging PR 123 does not address community will on what to do
>>> with the code beyond merging it. One can realistically vote +1 to merge
>>> the code, but then desire to see the code cleaned up and moved elsewhere.
>>> One can realistically desire seeing an attempt to clean up the code to
>> find
>>> what is reusable and may wish to withhold a final decision until we see
>> how
>>> fruitful such a module would be.
>>>
>>> Out of respect for people who may not know exactly how they feel (TomEE
>> or
>>> Geronimo), this is a vote for the latter.
>>>
>>> Vote: Should we attempt to extract code from the JWT PR to see what is
>>> reusable and how successful such a jar would be?
>>>
>>> +1 Let's give it a shot here
>>> +-0
>>> -1 Let's do this elsewhere
>>>
>>> If the vote is +1 to attempt an extraction of reusable code here, final
>>> conclusion of if that extraction is worth it or where it should live is
>> not
>>> being voted on. People are welcome to decide differently based on the
>>> results of the exercise.
>>>
>>>
>>> -David
>>>
>>>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Jonathan Gallimore <jo...@gmail.com>.
What's the other vote ("Geronimo one")?
Jon
On Mon, Mar 19, 2018 at 6:33 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hey David,
>
> How does this vote relates to the geronimo one you launched?
>
> Are they purely concurrent or can they be conditional one for the other?
>
>
> Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a écrit :
>
> > The vote for merging PR 123 does not address community will on what to do
> > with the code beyond merging it. One can realistically vote +1 to merge
> > the code, but then desire to see the code cleaned up and moved elsewhere.
> > One can realistically desire seeing an attempt to clean up the code to
> find
> > what is reusable and may wish to withhold a final decision until we see
> how
> > fruitful such a module would be.
> >
> > Out of respect for people who may not know exactly how they feel (TomEE
> or
> > Geronimo), this is a vote for the latter.
> >
> > Vote: Should we attempt to extract code from the JWT PR to see what is
> > reusable and how successful such a jar would be?
> >
> > +1 Let's give it a shot here
> > +-0
> > -1 Let's do this elsewhere
> >
> > If the vote is +1 to attempt an extraction of reusable code here, final
> > conclusion of if that extraction is worth it or where it should live is
> not
> > being voted on. People are welcome to decide differently based on the
> > results of the exercise.
> >
> >
> > -David
> >
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hey David,
How does this vote relates to the geronimo one you launched?
Are they purely concurrent or can they be conditional one for the other?
Le 19 mars 2018 01:03, "David Blevins" <da...@gmail.com> a écrit :
> The vote for merging PR 123 does not address community will on what to do
> with the code beyond merging it. One can realistically vote +1 to merge
> the code, but then desire to see the code cleaned up and moved elsewhere.
> One can realistically desire seeing an attempt to clean up the code to find
> what is reusable and may wish to withhold a final decision until we see how
> fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE or
> Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is
> reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final
> conclusion of if that extraction is worth it or where it should live is not
> being voted on. People are welcome to decide differently based on the
> results of the exercise.
>
>
> -David
>
>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-04-10 9:24 GMT+02:00 Rudy De Busscher <rd...@gmail.com>:
> Sorry Romain but I still have doubts if the code is really reusable, like
> that you can just add it to WildFly or Payara and that it works. (like
> Geronimo Config for example)
It will support the CDI+servlet support OOTB, the PR brings the
servlet/EJB integration (independently of microprofile) and we plugged
in
for jwt-auth to have EJB integration.
But it still means we are reusable in any CDI/servlet based server
OOTB without any dep and fully cover tomee scope so yes we are
reusable - we did it intentionally.
>
> Things like integrating with @RolesAllowed is not standardized (except
> using JASPIC maybe which I tried but I had other issues)
It is done though the CDI extension
>
> More generic parts like injecting the Claims etc, that could work.
Still a CDI thing.
>
> But I'm fine that the code is maintained at Geronimo, that TomEE code only
> contains the integration parts. But it will not be a complete
> implementation of MP JWT Auth (The Geronimo project).
>
> Rudy
>
> On 10 April 2018 at 06:58, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
>> Le 10 avr. 2018 05:23, "David Blevins" <da...@gmail.com> a écrit :
>>
>> Officially closing the vote. Thanks for the patience everyone. As
>> mentioned in the other vote, this one needed some good discussion and a bit
>> of extra time.
>>
>> +1s
>> Andy Gumbrecht
>> David Blevins
>> Ivan Junckes Filho
>> Jean-Louis Monteiro
>> Jonathan Gallimore
>> Thiago Veronezi
>>
>> +0
>> Rudy De Busscher
>>
>> -1s
>> Mark Struberg
>> Romain Manni-Bucau
>>
>> This was intended as a non-technical vote, so I've registered Mark's -1 as
>> he intended it. Thanks, Mark, for the clarification. Matthew, you didn't
>> vote, your participation was quite high -- thank you! You're more then
>> welcome to vote, sir :)
>>
>> This was a consensus vote to see if there was will keep working on the JWT
>> code here and see if it could be made reusable. We didn't really need this
>> vote to accomplish anything other than to see where people's heads are at
>> and make sure we're communicating with each other clearly.
>>
>> It does seem over all that the desire is to take a couple more steps. This
>> vote did not address where the code should live in its final state. We
>> don't really know how reusable anything will be.
>>
>>
>>
>> ...it has been mention 3 times the code IS reusable and should just be a
>> lib. It was codes this exact way so no ambiguity here.
>>
>>
>> I'd probably expect us to take a few more steps, see how things look and
>> come back to the "where" topic.
>>
>>
>> -David
>>
>>
>> > On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
>> wrote:
>> >
>> > The vote for merging PR 123 does not address community will on what to do
>> with the code beyond merging it. One can realistically vote +1 to merge
>> the code, but then desire to see the code cleaned up and moved elsewhere.
>> One can realistically desire seeing an attempt to clean up the code to find
>> what is reusable and may wish to withhold a final decision until we see how
>> fruitful such a module would be.
>> >
>> > Out of respect for people who may not know exactly how they feel (TomEE
>> or Geronimo), this is a vote for the latter.
>> >
>> > Vote: Should we attempt to extract code from the JWT PR to see what is
>> reusable and how successful such a jar would be?
>> >
>> > +1 Let's give it a shot here
>> > +-0
>> > -1 Let's do this elsewhere
>> >
>> > If the vote is +1 to attempt an extraction of reusable code here, final
>> conclusion of if that extraction is worth it or where it should live is not
>> being voted on. People are welcome to decide differently based on the
>> results of the exercise.
>> >
>> >
>> > -David
>> >
>>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Rudy De Busscher <rd...@gmail.com>.
Sorry Romain but I still have doubts if the code is really reusable, like
that you can just add it to WildFly or Payara and that it works. (like
Geronimo Config for example)
Things like integrating with @RolesAllowed is not standardized (except
using JASPIC maybe which I tried but I had other issues)
More generic parts like injecting the Claims etc, that could work.
But I'm fine that the code is maintained at Geronimo, that TomEE code only
contains the integration parts. But it will not be a complete
implementation of MP JWT Auth (The Geronimo project).
Rudy
On 10 April 2018 at 06:58, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Le 10 avr. 2018 05:23, "David Blevins" <da...@gmail.com> a écrit :
>
> Officially closing the vote. Thanks for the patience everyone. As
> mentioned in the other vote, this one needed some good discussion and a bit
> of extra time.
>
> +1s
> Andy Gumbrecht
> David Blevins
> Ivan Junckes Filho
> Jean-Louis Monteiro
> Jonathan Gallimore
> Thiago Veronezi
>
> +0
> Rudy De Busscher
>
> -1s
> Mark Struberg
> Romain Manni-Bucau
>
> This was intended as a non-technical vote, so I've registered Mark's -1 as
> he intended it. Thanks, Mark, for the clarification. Matthew, you didn't
> vote, your participation was quite high -- thank you! You're more then
> welcome to vote, sir :)
>
> This was a consensus vote to see if there was will keep working on the JWT
> code here and see if it could be made reusable. We didn't really need this
> vote to accomplish anything other than to see where people's heads are at
> and make sure we're communicating with each other clearly.
>
> It does seem over all that the desire is to take a couple more steps. This
> vote did not address where the code should live in its final state. We
> don't really know how reusable anything will be.
>
>
>
> ...it has been mention 3 times the code IS reusable and should just be a
> lib. It was codes this exact way so no ambiguity here.
>
>
> I'd probably expect us to take a few more steps, see how things look and
> come back to the "where" topic.
>
>
> -David
>
>
> > On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> > The vote for merging PR 123 does not address community will on what to do
> with the code beyond merging it. One can realistically vote +1 to merge
> the code, but then desire to see the code cleaned up and moved elsewhere.
> One can realistically desire seeing an attempt to clean up the code to find
> what is reusable and may wish to withhold a final decision until we see how
> fruitful such a module would be.
> >
> > Out of respect for people who may not know exactly how they feel (TomEE
> or Geronimo), this is a vote for the latter.
> >
> > Vote: Should we attempt to extract code from the JWT PR to see what is
> reusable and how successful such a jar would be?
> >
> > +1 Let's give it a shot here
> > +-0
> > -1 Let's do this elsewhere
> >
> > If the vote is +1 to attempt an extraction of reusable code here, final
> conclusion of if that extraction is worth it or where it should live is not
> being voted on. People are welcome to decide differently based on the
> results of the exercise.
> >
> >
> > -David
> >
>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 10 avr. 2018 05:23, "David Blevins" <da...@gmail.com> a écrit :
Officially closing the vote. Thanks for the patience everyone. As
mentioned in the other vote, this one needed some good discussion and a bit
of extra time.
+1s
Andy Gumbrecht
David Blevins
Ivan Junckes Filho
Jean-Louis Monteiro
Jonathan Gallimore
Thiago Veronezi
+0
Rudy De Busscher
-1s
Mark Struberg
Romain Manni-Bucau
This was intended as a non-technical vote, so I've registered Mark's -1 as
he intended it. Thanks, Mark, for the clarification. Matthew, you didn't
vote, your participation was quite high -- thank you! You're more then
welcome to vote, sir :)
This was a consensus vote to see if there was will keep working on the JWT
code here and see if it could be made reusable. We didn't really need this
vote to accomplish anything other than to see where people's heads are at
and make sure we're communicating with each other clearly.
It does seem over all that the desire is to take a couple more steps. This
vote did not address where the code should live in its final state. We
don't really know how reusable anything will be.
...it has been mention 3 times the code IS reusable and should just be a
lib. It was codes this exact way so no ambiguity here.
I'd probably expect us to take a few more steps, see how things look and
come back to the "where" topic.
-David
> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
wrote:
>
> The vote for merging PR 123 does not address community will on what to do
with the code beyond merging it. One can realistically vote +1 to merge
the code, but then desire to see the code cleaned up and moved elsewhere.
One can realistically desire seeing an attempt to clean up the code to find
what is reusable and may wish to withhold a final decision until we see how
fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE
or Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is
reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final
conclusion of if that extraction is worth it or where it should live is not
being voted on. People are welcome to decide differently based on the
results of the exercise.
>
>
> -David
>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
The PR has been merged.
Thanks everyone for voting.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Apr 12, 2018 at 4:25 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> why -> for consistency accross our coupled communities
> why does it matter if it is in G for T? -> it doesn't
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-12 15:56 GMT+02:00 Matthew Broadhead <matthew.broadhead@nbmlaw.co.
> uk>:
> > we already include libraries from geronimo, e.g. javamail, so why does it
> > matter where the library resides as long as it can be included in the
> > package
> >
> >
> > On 11/04/2018 15:05, Romain Manni-Bucau wrote:
> >>
> >> Hi Matthew,
> >>
> >> No, technicall there are a lot of small things to do before it can be
> >> "included" but the main blocker for me is that the exact same project
> >> is created at geronimo (actually this code was designed to be owned by
> >> geronimo and the artifact imported in tomee).
> >> Since G will have it I would like to avoid to have to maintain 2
> >> versions of the "same" code, it already proved being a failure promise
> >> multiple times so it is more a management reason than a technical one
> >> since the spec is pretty trivial.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> >>
> >>
> >> 2018-04-11 14:54 GMT+02:00 Matthew Broadhead
> >> <ma...@nbmlaw.co.uk>:
> >>>
> >>> Hi David,
> >>>
> >>> Thanks for the invitation to vote. I don't want to vote because I am
> not
> >>> sure I have enough knowledge to be able to do so.
> >>>
> >>> My gut feeling would probably be to side with Mark and Romain as they
> >>> have
> >>> been very supportive with my queries about TomEE and they have shown
> >>> deep
> >>> technical knowledge about the inner workings.
> >>>
> >>> On the other hand I don't want to dismiss the excellent effort others
> are
> >>> making on the JWT issue. However as long as the code is reusable and
> >>> finds
> >>> a home it will not be wasted.
> >>>
> >>> I am still interested to know what Mark and Romain are looking for
> before
> >>> they accept it into the project. Does it need to have proven track
> >>> record
> >>> and reliability? It is a security plugin after all...
> >>>
> >>> Matthew
> >>>
> >>>
> >>> On 10/04/2018 05:23, David Blevins wrote:
> >>>>
> >>>> Officially closing the vote. Thanks for the patience everyone. As
> >>>> mentioned in the other vote, this one needed some good discussion and
> a
> >>>> bit
> >>>> of extra time.
> >>>>
> >>>> +1s
> >>>> Andy Gumbrecht
> >>>> David Blevins
> >>>> Ivan Junckes Filho
> >>>> Jean-Louis Monteiro
> >>>> Jonathan Gallimore
> >>>> Thiago Veronezi
> >>>>
> >>>> +0
> >>>> Rudy De Busscher
> >>>>
> >>>> -1s
> >>>> Mark Struberg
> >>>> Romain Manni-Bucau
> >>>>
> >>>> This was intended as a non-technical vote, so I've registered Mark's
> -1
> >>>> as
> >>>> he intended it. Thanks, Mark, for the clarification. Matthew, you
> >>>> didn't
> >>>> vote, your participation was quite high -- thank you! You're more
> then
> >>>> welcome to vote, sir :)
> >>>>
> >>>> This was a consensus vote to see if there was will keep working on the
> >>>> JWT
> >>>> code here and see if it could be made reusable. We didn't really need
> >>>> this
> >>>> vote to accomplish anything other than to see where people's heads are
> >>>> at
> >>>> and make sure we're communicating with each other clearly.
> >>>>
> >>>> It does seem over all that the desire is to take a couple more steps.
> >>>> This vote did not address where the code should live in its final
> state.
> >>>> We
> >>>> don't really know how reusable anything will be.
> >>>>
> >>>> I'd probably expect us to take a few more steps, see how things look
> and
> >>>> come back to the "where" topic.
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>>> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> The vote for merging PR 123 does not address community will on what
> to
> >>>>> do
> >>>>> with the code beyond merging it. One can realistically vote +1 to
> >>>>> merge the
> >>>>> code, but then desire to see the code cleaned up and moved elsewhere.
> >>>>> One
> >>>>> can realistically desire seeing an attempt to clean up the code to
> find
> >>>>> what
> >>>>> is reusable and may wish to withhold a final decision until we see
> how
> >>>>> fruitful such a module would be.
> >>>>>
> >>>>> Out of respect for people who may not know exactly how they feel
> (TomEE
> >>>>> or Geronimo), this is a vote for the latter.
> >>>>>
> >>>>> Vote: Should we attempt to extract code from the JWT PR to see what
> is
> >>>>> reusable and how successful such a jar would be?
> >>>>>
> >>>>> +1 Let's give it a shot here
> >>>>> +-0
> >>>>> -1 Let's do this elsewhere
> >>>>>
> >>>>> If the vote is +1 to attempt an extraction of reusable code here,
> final
> >>>>> conclusion of if that extraction is worth it or where it should live
> is
> >>>>> not
> >>>>> being voted on. People are welcome to decide differently based on
> the
> >>>>> results of the exercise.
> >>>>>
> >>>>>
> >>>>> -David
> >>>>>
> >
>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
why -> for consistency accross our coupled communities
why does it matter if it is in G for T? -> it doesn't
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
2018-04-12 15:56 GMT+02:00 Matthew Broadhead <ma...@nbmlaw.co.uk>:
> we already include libraries from geronimo, e.g. javamail, so why does it
> matter where the library resides as long as it can be included in the
> package
>
>
> On 11/04/2018 15:05, Romain Manni-Bucau wrote:
>>
>> Hi Matthew,
>>
>> No, technicall there are a lot of small things to do before it can be
>> "included" but the main blocker for me is that the exact same project
>> is created at geronimo (actually this code was designed to be owned by
>> geronimo and the artifact imported in tomee).
>> Since G will have it I would like to avoid to have to maintain 2
>> versions of the "same" code, it already proved being a failure promise
>> multiple times so it is more a management reason than a technical one
>> since the spec is pretty trivial.
>>
>> Romain Manni-Bucau
>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>>
>>
>> 2018-04-11 14:54 GMT+02:00 Matthew Broadhead
>> <ma...@nbmlaw.co.uk>:
>>>
>>> Hi David,
>>>
>>> Thanks for the invitation to vote. I don't want to vote because I am not
>>> sure I have enough knowledge to be able to do so.
>>>
>>> My gut feeling would probably be to side with Mark and Romain as they
>>> have
>>> been very supportive with my queries about TomEE and they have shown
>>> deep
>>> technical knowledge about the inner workings.
>>>
>>> On the other hand I don't want to dismiss the excellent effort others are
>>> making on the JWT issue. However as long as the code is reusable and
>>> finds
>>> a home it will not be wasted.
>>>
>>> I am still interested to know what Mark and Romain are looking for before
>>> they accept it into the project. Does it need to have proven track
>>> record
>>> and reliability? It is a security plugin after all...
>>>
>>> Matthew
>>>
>>>
>>> On 10/04/2018 05:23, David Blevins wrote:
>>>>
>>>> Officially closing the vote. Thanks for the patience everyone. As
>>>> mentioned in the other vote, this one needed some good discussion and a
>>>> bit
>>>> of extra time.
>>>>
>>>> +1s
>>>> Andy Gumbrecht
>>>> David Blevins
>>>> Ivan Junckes Filho
>>>> Jean-Louis Monteiro
>>>> Jonathan Gallimore
>>>> Thiago Veronezi
>>>>
>>>> +0
>>>> Rudy De Busscher
>>>>
>>>> -1s
>>>> Mark Struberg
>>>> Romain Manni-Bucau
>>>>
>>>> This was intended as a non-technical vote, so I've registered Mark's -1
>>>> as
>>>> he intended it. Thanks, Mark, for the clarification. Matthew, you
>>>> didn't
>>>> vote, your participation was quite high -- thank you! You're more then
>>>> welcome to vote, sir :)
>>>>
>>>> This was a consensus vote to see if there was will keep working on the
>>>> JWT
>>>> code here and see if it could be made reusable. We didn't really need
>>>> this
>>>> vote to accomplish anything other than to see where people's heads are
>>>> at
>>>> and make sure we're communicating with each other clearly.
>>>>
>>>> It does seem over all that the desire is to take a couple more steps.
>>>> This vote did not address where the code should live in its final state.
>>>> We
>>>> don't really know how reusable anything will be.
>>>>
>>>> I'd probably expect us to take a few more steps, see how things look and
>>>> come back to the "where" topic.
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>>> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> The vote for merging PR 123 does not address community will on what to
>>>>> do
>>>>> with the code beyond merging it. One can realistically vote +1 to
>>>>> merge the
>>>>> code, but then desire to see the code cleaned up and moved elsewhere.
>>>>> One
>>>>> can realistically desire seeing an attempt to clean up the code to find
>>>>> what
>>>>> is reusable and may wish to withhold a final decision until we see how
>>>>> fruitful such a module would be.
>>>>>
>>>>> Out of respect for people who may not know exactly how they feel (TomEE
>>>>> or Geronimo), this is a vote for the latter.
>>>>>
>>>>> Vote: Should we attempt to extract code from the JWT PR to see what is
>>>>> reusable and how successful such a jar would be?
>>>>>
>>>>> +1 Let's give it a shot here
>>>>> +-0
>>>>> -1 Let's do this elsewhere
>>>>>
>>>>> If the vote is +1 to attempt an extraction of reusable code here, final
>>>>> conclusion of if that extraction is worth it or where it should live is
>>>>> not
>>>>> being voted on. People are welcome to decide differently based on the
>>>>> results of the exercise.
>>>>>
>>>>>
>>>>> -David
>>>>>
>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
we already include libraries from geronimo, e.g. javamail, so why does
it matter where the library resides as long as it can be included in the
package
On 11/04/2018 15:05, Romain Manni-Bucau wrote:
> Hi Matthew,
>
> No, technicall there are a lot of small things to do before it can be
> "included" but the main blocker for me is that the exact same project
> is created at geronimo (actually this code was designed to be owned by
> geronimo and the artifact imported in tomee).
> Since G will have it I would like to avoid to have to maintain 2
> versions of the "same" code, it already proved being a failure promise
> multiple times so it is more a management reason than a technical one
> since the spec is pretty trivial.
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-11 14:54 GMT+02:00 Matthew Broadhead <ma...@nbmlaw.co.uk>:
>> Hi David,
>>
>> Thanks for the invitation to vote. I don't want to vote because I am not
>> sure I have enough knowledge to be able to do so.
>>
>> My gut feeling would probably be to side with Mark and Romain as they have
>> been very supportive with my queries about TomEE and they have shown deep
>> technical knowledge about the inner workings.
>>
>> On the other hand I don't want to dismiss the excellent effort others are
>> making on the JWT issue. However as long as the code is reusable and finds
>> a home it will not be wasted.
>>
>> I am still interested to know what Mark and Romain are looking for before
>> they accept it into the project. Does it need to have proven track record
>> and reliability? It is a security plugin after all...
>>
>> Matthew
>>
>>
>> On 10/04/2018 05:23, David Blevins wrote:
>>> Officially closing the vote. Thanks for the patience everyone. As
>>> mentioned in the other vote, this one needed some good discussion and a bit
>>> of extra time.
>>>
>>> +1s
>>> Andy Gumbrecht
>>> David Blevins
>>> Ivan Junckes Filho
>>> Jean-Louis Monteiro
>>> Jonathan Gallimore
>>> Thiago Veronezi
>>>
>>> +0
>>> Rudy De Busscher
>>>
>>> -1s
>>> Mark Struberg
>>> Romain Manni-Bucau
>>>
>>> This was intended as a non-technical vote, so I've registered Mark's -1 as
>>> he intended it. Thanks, Mark, for the clarification. Matthew, you didn't
>>> vote, your participation was quite high -- thank you! You're more then
>>> welcome to vote, sir :)
>>>
>>> This was a consensus vote to see if there was will keep working on the JWT
>>> code here and see if it could be made reusable. We didn't really need this
>>> vote to accomplish anything other than to see where people's heads are at
>>> and make sure we're communicating with each other clearly.
>>>
>>> It does seem over all that the desire is to take a couple more steps.
>>> This vote did not address where the code should live in its final state. We
>>> don't really know how reusable anything will be.
>>>
>>> I'd probably expect us to take a few more steps, see how things look and
>>> come back to the "where" topic.
>>>
>>>
>>> -David
>>>
>>>
>>>> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
>>>> wrote:
>>>>
>>>> The vote for merging PR 123 does not address community will on what to do
>>>> with the code beyond merging it. One can realistically vote +1 to merge the
>>>> code, but then desire to see the code cleaned up and moved elsewhere. One
>>>> can realistically desire seeing an attempt to clean up the code to find what
>>>> is reusable and may wish to withhold a final decision until we see how
>>>> fruitful such a module would be.
>>>>
>>>> Out of respect for people who may not know exactly how they feel (TomEE
>>>> or Geronimo), this is a vote for the latter.
>>>>
>>>> Vote: Should we attempt to extract code from the JWT PR to see what is
>>>> reusable and how successful such a jar would be?
>>>>
>>>> +1 Let's give it a shot here
>>>> +-0
>>>> -1 Let's do this elsewhere
>>>>
>>>> If the vote is +1 to attempt an extraction of reusable code here, final
>>>> conclusion of if that extraction is worth it or where it should live is not
>>>> being voted on. People are welcome to decide differently based on the
>>>> results of the exercise.
>>>>
>>>>
>>>> -David
>>>>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Matthew,
No, technicall there are a lot of small things to do before it can be
"included" but the main blocker for me is that the exact same project
is created at geronimo (actually this code was designed to be owned by
geronimo and the artifact imported in tomee).
Since G will have it I would like to avoid to have to maintain 2
versions of the "same" code, it already proved being a failure promise
multiple times so it is more a management reason than a technical one
since the spec is pretty trivial.
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
2018-04-11 14:54 GMT+02:00 Matthew Broadhead <ma...@nbmlaw.co.uk>:
> Hi David,
>
> Thanks for the invitation to vote. I don't want to vote because I am not
> sure I have enough knowledge to be able to do so.
>
> My gut feeling would probably be to side with Mark and Romain as they have
> been very supportive with my queries about TomEE and they have shown deep
> technical knowledge about the inner workings.
>
> On the other hand I don't want to dismiss the excellent effort others are
> making on the JWT issue. However as long as the code is reusable and finds
> a home it will not be wasted.
>
> I am still interested to know what Mark and Romain are looking for before
> they accept it into the project. Does it need to have proven track record
> and reliability? It is a security plugin after all...
>
> Matthew
>
>
> On 10/04/2018 05:23, David Blevins wrote:
>>
>> Officially closing the vote. Thanks for the patience everyone. As
>> mentioned in the other vote, this one needed some good discussion and a bit
>> of extra time.
>>
>> +1s
>> Andy Gumbrecht
>> David Blevins
>> Ivan Junckes Filho
>> Jean-Louis Monteiro
>> Jonathan Gallimore
>> Thiago Veronezi
>>
>> +0
>> Rudy De Busscher
>>
>> -1s
>> Mark Struberg
>> Romain Manni-Bucau
>>
>> This was intended as a non-technical vote, so I've registered Mark's -1 as
>> he intended it. Thanks, Mark, for the clarification. Matthew, you didn't
>> vote, your participation was quite high -- thank you! You're more then
>> welcome to vote, sir :)
>>
>> This was a consensus vote to see if there was will keep working on the JWT
>> code here and see if it could be made reusable. We didn't really need this
>> vote to accomplish anything other than to see where people's heads are at
>> and make sure we're communicating with each other clearly.
>>
>> It does seem over all that the desire is to take a couple more steps.
>> This vote did not address where the code should live in its final state. We
>> don't really know how reusable anything will be.
>>
>> I'd probably expect us to take a few more steps, see how things look and
>> come back to the "where" topic.
>>
>>
>> -David
>>
>>
>>> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
>>> wrote:
>>>
>>> The vote for merging PR 123 does not address community will on what to do
>>> with the code beyond merging it. One can realistically vote +1 to merge the
>>> code, but then desire to see the code cleaned up and moved elsewhere. One
>>> can realistically desire seeing an attempt to clean up the code to find what
>>> is reusable and may wish to withhold a final decision until we see how
>>> fruitful such a module would be.
>>>
>>> Out of respect for people who may not know exactly how they feel (TomEE
>>> or Geronimo), this is a vote for the latter.
>>>
>>> Vote: Should we attempt to extract code from the JWT PR to see what is
>>> reusable and how successful such a jar would be?
>>>
>>> +1 Let's give it a shot here
>>> +-0
>>> -1 Let's do this elsewhere
>>>
>>> If the vote is +1 to attempt an extraction of reusable code here, final
>>> conclusion of if that extraction is worth it or where it should live is not
>>> being voted on. People are welcome to decide differently based on the
>>> results of the exercise.
>>>
>>>
>>> -David
>>>
>
Re: [RESULT] Explore creating a reusable JWT Library
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
Hi David,
Thanks for the invitation to vote. I don't want to vote because I am
not sure I have enough knowledge to be able to do so.
My gut feeling would probably be to side with Mark and Romain as they
have been very supportive with my queries about TomEE and they have
shown deep technical knowledge about the inner workings.
On the other hand I don't want to dismiss the excellent effort others
are making on the JWT issue. However as long as the code is reusable
and finds a home it will not be wasted.
I am still interested to know what Mark and Romain are looking for
before they accept it into the project. Does it need to have proven
track record and reliability? It is a security plugin after all...
Matthew
On 10/04/2018 05:23, David Blevins wrote:
> Officially closing the vote. Thanks for the patience everyone. As mentioned in the other vote, this one needed some good discussion and a bit of extra time.
>
> +1s
> Andy Gumbrecht
> David Blevins
> Ivan Junckes Filho
> Jean-Louis Monteiro
> Jonathan Gallimore
> Thiago Veronezi
>
> +0
> Rudy De Busscher
>
> -1s
> Mark Struberg
> Romain Manni-Bucau
>
> This was intended as a non-technical vote, so I've registered Mark's -1 as he intended it. Thanks, Mark, for the clarification. Matthew, you didn't vote, your participation was quite high -- thank you! You're more then welcome to vote, sir :)
>
> This was a consensus vote to see if there was will keep working on the JWT code here and see if it could be made reusable. We didn't really need this vote to accomplish anything other than to see where people's heads are at and make sure we're communicating with each other clearly.
>
> It does seem over all that the desire is to take a couple more steps. This vote did not address where the code should live in its final state. We don't really know how reusable anything will be.
>
> I'd probably expect us to take a few more steps, see how things look and come back to the "where" topic.
>
>
> -David
>
>
>> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com> wrote:
>>
>> The vote for merging PR 123 does not address community will on what to do with the code beyond merging it. One can realistically vote +1 to merge the code, but then desire to see the code cleaned up and moved elsewhere. One can realistically desire seeing an attempt to clean up the code to find what is reusable and may wish to withhold a final decision until we see how fruitful such a module would be.
>>
>> Out of respect for people who may not know exactly how they feel (TomEE or Geronimo), this is a vote for the latter.
>>
>> Vote: Should we attempt to extract code from the JWT PR to see what is reusable and how successful such a jar would be?
>>
>> +1 Let's give it a shot here
>> +-0
>> -1 Let's do this elsewhere
>>
>> If the vote is +1 to attempt an extraction of reusable code here, final conclusion of if that extraction is worth it or where it should live is not being voted on. People are welcome to decide differently based on the results of the exercise.
>>
>>
>> -David
>>
[RESULT] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
Officially closing the vote. Thanks for the patience everyone. As mentioned in the other vote, this one needed some good discussion and a bit of extra time.
+1s
Andy Gumbrecht
David Blevins
Ivan Junckes Filho
Jean-Louis Monteiro
Jonathan Gallimore
Thiago Veronezi
+0
Rudy De Busscher
-1s
Mark Struberg
Romain Manni-Bucau
This was intended as a non-technical vote, so I've registered Mark's -1 as he intended it. Thanks, Mark, for the clarification. Matthew, you didn't vote, your participation was quite high -- thank you! You're more then welcome to vote, sir :)
This was a consensus vote to see if there was will keep working on the JWT code here and see if it could be made reusable. We didn't really need this vote to accomplish anything other than to see where people's heads are at and make sure we're communicating with each other clearly.
It does seem over all that the desire is to take a couple more steps. This vote did not address where the code should live in its final state. We don't really know how reusable anything will be.
I'd probably expect us to take a few more steps, see how things look and come back to the "where" topic.
-David
> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com> wrote:
>
> The vote for merging PR 123 does not address community will on what to do with the code beyond merging it. One can realistically vote +1 to merge the code, but then desire to see the code cleaned up and moved elsewhere. One can realistically desire seeing an attempt to clean up the code to find what is reusable and may wish to withhold a final decision until we see how fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE or Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final conclusion of if that extraction is worth it or where it should live is not being voted on. People are welcome to decide differently based on the results of the exercise.
>
>
> -David
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
+1.
I'd like to see the code merged and evolve a little within the the TomEE
context. It's relatively easy to discuss/extract reuse later, but I'd
like to see TomEE move forward first.
The same goes for the config PR from Roberto.
Andy.
On 19/03/18 01:02, David Blevins wrote:
> The vote for merging PR 123 does not address community will on what to do with the code beyond merging it. One can realistically vote +1 to merge the code, but then desire to see the code cleaned up and moved elsewhere. One can realistically desire seeing an attempt to clean up the code to find what is reusable and may wish to withhold a final decision until we see how fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE or Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final conclusion of if that extraction is worth it or where it should live is not being voted on. People are welcome to decide differently based on the results of the exercise.
>
>
> -David
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io
Ubique
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Rudy De Busscher <rd...@gmail.com>.
+0
If it needs to be reusable it should also work with other Application
Servers (which I don't believe is possible with MP JWT Auth).
So First within TomEE and then try it to extract it and make it work
elsewhere also.
Rudy
On 29 March 2018 at 20:21, Ivan Junckes Filho <iv...@gmail.com> wrote:
> I think we should keep the code in TomEE.
>
> +1
>
> On Thu, Mar 29, 2018 at 3:16 PM, Thiago Veronezi <th...@veronezi.org>
> wrote:
>
> > +1 Let's give it a shot here
> >
> > On Thu, Mar 29, 2018 at 2:12 PM, David Blevins <da...@gmail.com>
> > wrote:
> >
> > > I'd like to wrap this up so if you have other questions or would like
> to
> > > vote, now is the time. Reminder, you do not need to be a committer to
> > vote.
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > > > On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
> > > wrote:
> > > >
> > > > The vote for merging PR 123 does not address community will on what
> to
> > > do with the code beyond merging it. One can realistically vote +1 to
> > merge
> > > the code, but then desire to see the code cleaned up and moved
> elsewhere.
> > > One can realistically desire seeing an attempt to clean up the code to
> > find
> > > what is reusable and may wish to withhold a final decision until we see
> > how
> > > fruitful such a module would be.
> > > >
> > > > Out of respect for people who may not know exactly how they feel
> (TomEE
> > > or Geronimo), this is a vote for the latter.
> > > >
> > > > Vote: Should we attempt to extract code from the JWT PR to see what
> is
> > > reusable and how successful such a jar would be?
> > > >
> > > > +1 Let's give it a shot here
> > > > +-0
> > > > -1 Let's do this elsewhere
> > > >
> > > > If the vote is +1 to attempt an extraction of reusable code here,
> final
> > > conclusion of if that extraction is worth it or where it should live is
> > not
> > > being voted on. People are welcome to decide differently based on the
> > > results of the exercise.
> > > >
> > > >
> > > > -David
> > > >
> > >
> > >
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Ivan Junckes Filho <iv...@gmail.com>.
I think we should keep the code in TomEE.
+1
On Thu, Mar 29, 2018 at 3:16 PM, Thiago Veronezi <th...@veronezi.org>
wrote:
> +1 Let's give it a shot here
>
> On Thu, Mar 29, 2018 at 2:12 PM, David Blevins <da...@gmail.com>
> wrote:
>
> > I'd like to wrap this up so if you have other questions or would like to
> > vote, now is the time. Reminder, you do not need to be a committer to
> vote.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> > > On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
> > wrote:
> > >
> > > The vote for merging PR 123 does not address community will on what to
> > do with the code beyond merging it. One can realistically vote +1 to
> merge
> > the code, but then desire to see the code cleaned up and moved elsewhere.
> > One can realistically desire seeing an attempt to clean up the code to
> find
> > what is reusable and may wish to withhold a final decision until we see
> how
> > fruitful such a module would be.
> > >
> > > Out of respect for people who may not know exactly how they feel (TomEE
> > or Geronimo), this is a vote for the latter.
> > >
> > > Vote: Should we attempt to extract code from the JWT PR to see what is
> > reusable and how successful such a jar would be?
> > >
> > > +1 Let's give it a shot here
> > > +-0
> > > -1 Let's do this elsewhere
> > >
> > > If the vote is +1 to attempt an extraction of reusable code here, final
> > conclusion of if that extraction is worth it or where it should live is
> not
> > being voted on. People are welcome to decide differently based on the
> > results of the exercise.
> > >
> > >
> > > -David
> > >
> >
> >
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by Thiago Veronezi <th...@veronezi.org>.
+1 Let's give it a shot here
On Thu, Mar 29, 2018 at 2:12 PM, David Blevins <da...@gmail.com>
wrote:
> I'd like to wrap this up so if you have other questions or would like to
> vote, now is the time. Reminder, you do not need to be a committer to vote.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> > The vote for merging PR 123 does not address community will on what to
> do with the code beyond merging it. One can realistically vote +1 to merge
> the code, but then desire to see the code cleaned up and moved elsewhere.
> One can realistically desire seeing an attempt to clean up the code to find
> what is reusable and may wish to withhold a final decision until we see how
> fruitful such a module would be.
> >
> > Out of respect for people who may not know exactly how they feel (TomEE
> or Geronimo), this is a vote for the latter.
> >
> > Vote: Should we attempt to extract code from the JWT PR to see what is
> reusable and how successful such a jar would be?
> >
> > +1 Let's give it a shot here
> > +-0
> > -1 Let's do this elsewhere
> >
> > If the vote is +1 to attempt an extraction of reusable code here, final
> conclusion of if that extraction is worth it or where it should live is not
> being voted on. People are welcome to decide differently based on the
> results of the exercise.
> >
> >
> > -David
> >
>
>
Re: [VOTE] Explore creating a reusable JWT Library
Posted by David Blevins <da...@gmail.com>.
I'd like to wrap this up so if you have other questions or would like to vote, now is the time. Reminder, you do not need to be a committer to vote.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Mar 18, 2018, at 5:02 PM, David Blevins <da...@gmail.com> wrote:
>
> The vote for merging PR 123 does not address community will on what to do with the code beyond merging it. One can realistically vote +1 to merge the code, but then desire to see the code cleaned up and moved elsewhere. One can realistically desire seeing an attempt to clean up the code to find what is reusable and may wish to withhold a final decision until we see how fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE or Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final conclusion of if that extraction is worth it or where it should live is not being voted on. People are welcome to decide differently based on the results of the exercise.
>
>
> -David
>