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/04/10 03:23:04 UTC

[RESULT] Explore creating a reusable JWT Library

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>.
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
>>