Re: Implementing Microprofile JWT

[Mark Struberg]

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

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

LieGrue,
strub


> Am 15.02.2018 um 14:05 schrieb Romain Manni-Bucau :
> 
> 2018-02-15 13:30 GMT+01:00 Rudy De Busscher :
> 
>>> 
>>> Can we assume Java8 for this attempt?
>>> Oh and more important: Will the integration work based on TomEE7 (would
>>> require Java7) or the upcoming TomEE8?
>>> I'd say we should focus on TomEE8 and Java8
>> 
>> 
>> MicroProfile specs are defined in Java 8, so TomEE8 seems the only option.
>> 
> 
> CDI 2 is the constraint more than java 8 which works on TomEE 7 ;). That
> said converters should still be scannable so java 8 or not is maybe not the
> main challenge - not even sure there is a challenge to be honest, just a
> clean definition without any redefinition of what is a "context" works :).
> 
> 
>> 
>> regards
>> Rudy
>> 
>> 
>> On 15 February 2018 at 09:37, Mark Struberg 
>> wrote:
>> 
>>> 
>>> 
 Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
 :
 
 Le 15 févr. 2018 01:35, "David Blevins"  a
>>> écrit :
 
 I understand there's kind of a meta conversation going on that all
>> roads
 and discussions need to end at there being something to put a
 microprofile-jwt git repo.  I wave a white flag and gently request a
 respite from that as I don't want everything I write to be read as if
>> I'm
 attempting to steer for or against.
 
 I'm 100% supportive of reuse.  And there could be something of value to
 reuse in the end.  But at this moment if there was a microprofile-jwt
>>> git,
 even if that repo was in TomEE, I'm not sold at this point there would
>> be
 enough code there to justify it.
>>> 
>>> 
>>> No, there is no meta discussion. This is about reusability in other
>>> projects. As clearly stated as that.
>>> I think we can easily get this done by splitting it in a core part and
>>> then a second part which exposes the JsonWebToken as Principal in various
>>> EE apis. The overall structure will become way cleaner imo as it would be
>>> highly modular without adding too much overhead.
>>> 
 
 I'd probably lean towards getting a prototype done with the mutual
 understanding this part of the discussion is still open.
>>> 
>>> +1
>>> 
 Once we have code
 in hand, we can have a more informed discussion and circle back to
>> reuse.
>>> 
>>> -1 You have to design with reuse in mind.
>>> I'm not talking about making it overcomplicated and unecessarily modular,
>>> but just address the things we know already.
>>> 
 
> On Feb 14, 2018, at 11:57 AM, Mark Struberg >> 
 wrote:
> 
> If you want to have JWT working for ALL EE things then it's not
 MicroProfile-JWT anymore, isn't?
> It would be much more. Not bad of course, but still way beyond of what
 MicroProfile-JWT defines.
 
 Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines
>> about
 11 different integration points across JAX-RS, EJB, Servlets, JACC etc.
>>> As
 only JAX-RS is a required part of a MicroProfile server and the other
>>> parts
 are optional, at least 7 out of the 11 integration points are also
>>> optional.
>>> 
>>> Thanks for pointing me to this.
>>> 'integration points'. Even the spec indicates that the EE part is merely
>>> integration work.
>>> That might be a lot of work of course. But it would be cool if getting
>> the
>>> JsonWebToken would merely be one line of code which is in the mp-jwt-core
>>> package.
>>> 
 
 There are tests for much of them in the MicroProfile JWT TCK. The tests
>>> are
 also optional, but we'd definitely want to run and pass them as well as
 contribute to them if they are incomplete.
 
 If the spec is incomplete and we did miss an EE integration point,
 definitely want to update the spec to cover it.  Scott and I and the
>>> other
 folks who worked on the spec did our best to try and enumerate the ones
>>> we
 could think of, but we may have missed some.
 
> Oh and I assume it does also include a way to _create_ JsonWebTokens,
 right?
 
 The token creation would be done by an OAuth provider, which is outside
>>> the
 MP JWT specification.
>>> 
>>> Oki, I will start a discussion over at MicroProfile.
>>> Thinking about a JsonWebTokenBuilder or something.
>>> 
 
 The specification does have requirements that define what the token
>>> should
 look like, but they're all very minimal so that we could be as
>> compatible
 as possible with as many existing OAuth provider implementations as
 possible.
 
 Effectively it says the JWT must be signed with an RSA private key the
 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

2018-02-15 13:30 GMT+01:00 Rudy De Busscher :

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

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


>
> regards
> Rudy
>
>
> On 15 February 2018 at 09:37, Mark Struberg 
> wrote:
>
> >
> >
> > > Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Le 15 févr. 2018 01:35, "David Blevins"  a
> > écrit :
> > >
> > > I understand there's kind of a meta conversation going on that all
> roads
> > > and discussions need to end at there being something to put a
> > > microprofile-jwt git repo.  I wave a white flag and gently request a
> > > respite from that as I don't want everything I write to be read as if
> I'm
> > > attempting to steer for or against.
> > >
> > > I'm 100% supportive of reuse.  And there could be something of value to
> > > reuse in the end.  But at this moment if there was a microprofile-jwt
> > git,
> > > even if that repo was in TomEE, I'm not sold at this point there would
> be
> > > enough code there to justify it.
> >
> >
> > No, there is no meta discussion. This is about reusability in other
> > projects. As clearly stated as that.
> > I think we can easily get this done by splitting it in a core part and
> > then a second part which exposes the JsonWebToken as Principal in various
> > EE apis. The overall structure will become way cleaner imo as it would be
> > highly modular without adding too much overhead.
> >
> > >
> > > I'd probably lean towards getting a prototype done with the mutual
> > > understanding this part of the discussion is still open.
> >
> > +1
> >
> > > Once we have code
> > > in hand, we can have a more informed discussion and circle back to
> reuse.
> >
> > -1 You have to design with reuse in mind.
> > I'm not talking about making it overcomplicated and unecessarily modular,
> > but just address the things we know already.
> >
> > >
> > >> On Feb 14, 2018, at 11:57 AM, Mark Struberg  >
> > > wrote:
> > >>
> > >> If you want to have JWT working for ALL EE things then it's not
> > > MicroProfile-JWT anymore, isn't?
> > >> It would be much more. Not bad of course, but still way beyond of what
> > > MicroProfile-JWT defines.
> > >
> > > Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines
> about
> > > 11 different integration points across JAX-RS, EJB, Servlets, JACC etc.
> > As
> > > only JAX-RS is a required part of a MicroProfile server and the other
> > parts
> > > are optional, at least 7 out of the 11 integration points are also
> > optional.
> >
> > Thanks for pointing me to this.
> > 'integration points'. Even the spec indicates that the EE part is merely
> > integration work.
> > That might be a lot of work of course. But it would be cool if getting
> the
> > JsonWebToken would merely be one line of code which is in the mp-jwt-core
> > package.
> >
> > >
> > > There are tests for much of them in the MicroProfile JWT TCK. The tests
> > are
> > > also optional, but we'd definitely want to run and pass them as well as
> > > contribute to them if they are incomplete.
> > >
> > > If the spec is incomplete and we did miss an EE integration point,
> > > definitely want to update the spec to cover it.  Scott and I and the
> > other
> > > folks who worked on the spec did our best to try and enumerate the ones
> > we
> > > could think of, but we may have missed some.
> > >
> > >> Oh and I assume it does also include a way to _create_ JsonWebTokens,
> > > right?
> > >
> > > The token creation would be done by an OAuth provider, which is outside
> > the
> > > MP JWT specification.
> >
> > Oki, I will start a discussion over at MicroProfile.
> > Thinking about a JsonWebTokenBuilder or something.
> >
> > >
> > > The specification does have requirements that define what the token
> > should
> > > look like, but they're all very minimal so that we could be as
> compatible
> > > as possible with as many existing OAuth provider implementations as
> > > possible.
> > >
> > > Effectively it says the JWT must be signed with an RSA private key the
> > > OAuth Provider owns and assumes the MicroProfile server has been given
> > the
> > > public key.  How that public key is passed is also outside the
> > > specification, but generally, it'll be on disk or sitting in the docker
> > > image somewhere.
> >
> > JWT doesn't even require oauth2, isn't?
> > Of course oauth2 _could_ be the payload. 

Re: Implementing Microprofile JWT

[Rudy De Busscher]

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


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

regards
Rudy


On 15 February 2018 at 09:37, Mark Struberg 
wrote:

>
>
> > Am 15.02.2018 um 07:50 schrieb Romain Manni-Bucau  >:
> >
> > Le 15 févr. 2018 01:35, "David Blevins"  a
> écrit :
> >
> > I understand there's kind of a meta conversation going on that all roads
> > and discussions need to end at there being something to put a
> > microprofile-jwt git repo.  I wave a white flag and gently request a
> > respite from that as I don't want everything I write to be read as if I'm
> > attempting to steer for or against.
> >
> > I'm 100% supportive of reuse.  And there could be something of value to
> > reuse in the end.  But at this moment if there was a microprofile-jwt
> git,
> > even if that repo was in TomEE, I'm not sold at this point there would be
> > enough code there to justify it.
>
>
> No, there is no meta discussion. This is about reusability in other
> projects. As clearly stated as that.
> I think we can easily get this done by splitting it in a core part and
> then a second part which exposes the JsonWebToken as Principal in various
> EE apis. The overall structure will become way cleaner imo as it would be
> highly modular without adding too much overhead.
>
> >
> > I'd probably lean towards getting a prototype done with the mutual
> > understanding this part of the discussion is still open.
>
> +1
>
> > Once we have code
> > in hand, we can have a more informed discussion and circle back to reuse.
>
> -1 You have to design with reuse in mind.
> I'm not talking about making it overcomplicated and unecessarily modular,
> but just address the things we know already.
>
> >
> >> On Feb 14, 2018, at 11:57 AM, Mark Struberg 
> > wrote:
> >>
> >> If you want to have JWT working for ALL EE things then it's not
> > MicroProfile-JWT anymore, isn't?
> >> It would be much more. Not bad of course, but still way beyond of what
> > MicroProfile-JWT defines.
> >
> > Chapter 7 "Mapping MP-JWT Tokens to Java EE Container APIs" defines about
> > 11 different integration points across JAX-RS, EJB, Servlets, JACC etc.
> As
> > only JAX-RS is a required part of a MicroProfile server and the other
> parts
> > are optional, at least 7 out of the 11 integration points are also
> optional.
>
> Thanks for pointing me to this.
> 'integration points'. Even the spec indicates that the EE part is merely
> integration work.
> That might be a lot of work of course. But it would be cool if getting the
> JsonWebToken would merely be one line of code which is in the mp-jwt-core
> package.
>
> >
> > There are tests for much of them in the MicroProfile JWT TCK. The tests
> are
> > also optional, but we'd definitely want to run and pass them as well as
> > contribute to them if they are incomplete.
> >
> > If the spec is incomplete and we did miss an EE integration point,
> > definitely want to update the spec to cover it.  Scott and I and the
> other
> > folks who worked on the spec did our best to try and enumerate the ones
> we
> > could think of, but we may have missed some.
> >
> >> Oh and I assume it does also include a way to _create_ JsonWebTokens,
> > right?
> >
> > The token creation would be done by an OAuth provider, which is outside
> the
> > MP JWT specification.
>
> Oki, I will start a discussion over at MicroProfile.
> Thinking about a JsonWebTokenBuilder or something.
>
> >
> > The specification does have requirements that define what the token
> should
> > look like, but they're all very minimal so that we could be as compatible
> > as possible with as many existing OAuth provider implementations as
> > possible.
> >
> > Effectively it says the JWT must be signed with an RSA private key the
> > OAuth Provider owns and assumes the MicroProfile server has been given
> the
> > public key.  How that public key is passed is also outside the
> > specification, but generally, it'll be on disk or sitting in the docker
> > image somewhere.
>
> JWT doesn't even require oauth2, isn't?
> Of course oauth2 _could_ be the payload. But that's no necessity for
> everyone.
> Most users will not need that actually. But they might be more interested
> in having a radius like single sign on via JWT.
> At least that's what I hear from my customers.
>
> >
> >
> >> * JSON-P on the json side.
> >
> > Agree.  This is definitely mandatory to implement the MP JWT spec as
> claims
> > can be injected as JsonObject, etc.
> >
> >> * crypto: Whether to use the JCE built-in crypto or an external lib
> > should be pluggable. We just need to add a smallish SPI with a few
> methods.
> >
> > Agree to disagree on this one :)  JCE is an abstraction with two well
> 

Re: Implementing Microprofile JWT

[Mark Struberg]

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


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

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

+1

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

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

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

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

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

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

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

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

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

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


> 
>> * JsonWebToken and a way to get 'the' JWT for a single Request. That
> might be a provider interface or a @RequestScoped CDI bean.
> 
> MP JWT spec requires there to be a dependent scoped producer for
> JsonWebToken.  The bean getting JsonWebToken injected must be
> RequestScoped.  Currently section 7.1.3 forbids injection into beans that
> are not @RequestScoped.
> 
> 
> Any waynto 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

Le 15 févr. 2018 01:35, "David Blevins"  a écrit :

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

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

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

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

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

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

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

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

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

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

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


> * JSON-P on the json side.

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

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

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

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

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


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

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


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


It is backed by jsonp so immutable by definition no?


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

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

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


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



-David

Re: Implementing Microprofile JWT

[David Blevins]

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

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

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

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

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

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

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

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

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

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

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


> * JSON-P on the json side.

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

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

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

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

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

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

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

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

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


-David

Re: Implementing Microprofile JWT

[David Blevins]

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

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

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

Not sure to be honest.

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

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


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

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

That's all defined in chapter 12

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


-David

Re: Implementing Microprofile JWT

[Mark Struberg]

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

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

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

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

But apart from that that's it!

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

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


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


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

wdyt?

LieGrue,
strub



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

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

Le 14 févr. 2018 19:47, "David Blevins"  a écrit :

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

There are effectively two ways to get the JsonWebToken:

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

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


If jsonp it can be @appscoped too technically


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


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



-David

Re: Implementing Microprofile JWT

[David Blevins]

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

There are effectively two ways to get the JsonWebToken:

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

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

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


-David

Re: Implementing Microprofile JWT

[David Blevins]

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

Correct.

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

We do, yes.

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

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

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

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


-David

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

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

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


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-14 17:54 GMT+01:00 Jean-Louis Monteiro :

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

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro]

Thanks David,

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

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

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

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

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








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

On Wed, Feb 14, 2018 at 5:30 PM, David Blevins 
wrote:

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

Re: Implementing Microprofile JWT

[Mark Struberg]

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

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

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

LieGrue,
strub

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


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

Re: Implementing Microprofile JWT

[David Blevins]

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

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

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

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

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

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

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

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

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

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

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

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

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

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


-David

Re: Implementing Microprofile JWT

[David Blevins]

Can you put that on the Umbrella thread?  More for clean archiving and 
collecting everything in one spot.


-David

> On Feb 13, 2018, at 8:25 AM, Mark Struberg  wrote:
> 
> Hi folks!
> 
> Mike had a grat response on the imact and potential downsides of becoming an 
> Umbrella project.
> I asked for his permisson to forward, so here we go.
> Txs Mike for the additional input!
> 
> LieGrue,
> strub
> 
> 
>> 
>> Von: Mike Kienenberger 
>> Betreff: Aw: Implementing Microprofile JWT
>> Datum: 13. Februar 2018 um 16:08:24 MEZ
>> An: bo...@apache.org
>> 
>> As the Chair of an umbrella project (MyFaces), I strongly recommend
>> against making umbrella projects.
>> 
>> Umbrella projects end up with a lot of unloved components, and this
>> happens without anyone realizing it as it is difficult to have the
>> same oversight for subprojects as there is for a TLP.
>> 
>> There is going to be some point where smaller items are too small to
>> handle individually, but you should have the mindset that whenever a
>> subproject gets enough community to support it that it should
>> immediately spin off to its own TLP.
>> 
>> Right now, MyFaces has 11 subprojects.   Only two of them are actively
>> developed.  The people working on several of these subprojects drifted
>> away and no one noticed because it wasn't important to the remaining
>> people.   Most of those who remain are, rightly so, not willing to
>> devote volunteer time to something they have little-to-no involvement
>> with.  The other PMC members will still do it grudgingly but as a
>> burden.   Even "retiring" these subprojects is not possible because no
>> one is willing to spend the time to make that happen.
>> 
>> To recap, my recommendations to the PMC of an umbrella project would be:
>> 
>> - Require subproject reports.   Have them due two weeks before the TLP
>> board report is due.   Merge them into the TLP board report.   Use
>> similar criteria to determine subproject health.  The PMC becomes "the
>> board" within their domain.
>> 
>> - Split subprojects off to TLPs immediately as soon as a sustainable
>> community develops.  This might be before code exists.
>> 
>> - Have a plan beforehand on when and how you are going to "retire"
>> subprojects which are no longer maintained.  You are going to need
>> your own attic concept.
>> 
> 

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro]

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

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

On Tue, Feb 13, 2018 at 4:58 PM, Mark Struberg 
wrote:

> Might do as well.
> But the JSON-P part is really well abstracted. So this is easy to plug-in.
>
> I'm more worried about the authorisation and authentication interface.
> Anything EE security seems way too heavyweight for me. This might work out
> for TomEE, but would kill it's use in any more lightweight approach.
> So probably introduce an own pluggable SPI for authentication and
> authorisation?
> Then it really could be done pretty much anywhere. Or do we have yet
> another 'interface area'?
>
> LieGrue,
> strub
>
>
> > Am 13.02.2018 um 16:52 schrieb Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>:
> >
> > I was also thinking about a Johnzon extension (kinda)
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg  >
> > wrote:
> >
> >> I know JWT a bit and I wonder whether doing the signing part is just a
> bit
> >> of Json (JSON-P) + commons-crypto?
> >> After all JWT is especially designed to be lightweight and straight
> >> forward.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro <
> jlmonte...@tomitribe.com
> >>> :
> >>>
>  Thanks for the feedback Jon.
> 
>  I had a couple of exchanges with Rudy which is happy to contribute
> some
>  code as well.
>  From what I have understood and seen, most of the code is integration
> >> code
>  and there is at least from my current knowledge a little bit of code
> to
> >> put
>  together in a reusable manner in a reusable library (where ever it
> >> sits).
>  I was planning to do a quick prototype and get it to work from end to
> >> end
>  into a working branch so we can move the discussion forward and see
> >> exactly
>  where we go.
> 
>  Regarding the signing library, I am kinda on the same page.
>  I don't see myself rewriting Johnzon to parse JSON and then Jose or
> >> Nimbus
>  to do signing. There is absolutely no point at least for the POC.
> Again,
>  we'll see if I get something working what we can do.
> 
> 
> 
> >>> Agreeing for a PoC but for a production ready software it is if it can
> >>> conflict or bring drawbacks to the users to import the solution. The
> json
> >>> lib should at least be pluggable - avoids to shade/rewrite anything but
> >> let
> >>> the integrator use what he already has. Side note for json: for the
> >> overall
> >>> consistency using JSON-P makes it easy to get a common API which
> doesn't
> >>> need any investment and solves that "plug your impl" smoothly. For the
> >>> signing part it is a bit different since it will easily bring a huge
> >> stack
> >>> - how many bring jackson, simple-json, ... by default and are not
> >>> pluggable. This is an issue and can even lead to not working
> >> installations.
> >>> If you doubt I have like 700 components to show you it is not a random
> or
> >>> theorical thought. Investment is also quite light so not sure it does
> >> worth
> >>> speaking about it days.
> >>>
> >>>
> 
> 
> 
>  --
>  Jean-Louis Monteiro
>  http://twitter.com/jlouismonteiro
>  http://www.tomitribe.com
> 
>  On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament <
> johndam...@apache.org>
>  wrote:
> 
> >
> >
> > On 2018/02/12 20:42:58, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com
> >
> > wrote:
> >> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> No Andy, as mentionned in the discussion Geronimo hosts the
> > microprofile
> >>> @asf. This is why jwt should probably be done in geronimo which is
>  the
> > asf
> >>> ee related project umbrella.
> >>>
> >>
> >> I don't recall that discussion. Where did it take place?
> >
> > I *think* he meant me.  The only time JWT came up on Geronimo was at
> >> [1].
> > I had mentioned bringing over an impl based on Jose4J, Romain felt
> very
> > strongly we mustn't rely on 3rd party libraries.  I'm not sure why
> that
>  is,
> > but it seemed based on the discussion we had two different aims so it
> > wasn't something I pushed forward on.  If there's interest within
> TomEE
>  to
> > get a JWT impl up and running, I'd be happy to help (though I do feel
> > strongly relying on a 3rd party lib for the actual signature
> >> validation +
> > external sig support is important; to avoid that overhead).
> >
> > RE MP @ TomEE/Geronimo.  I 

Re: Implementing Microprofile JWT

[Mark Struberg]

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

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

LieGrue,
strub


> Am 13.02.2018 um 16:52 schrieb Jean-Louis Monteiro :
> 
> I was also thinking about a Johnzon extension (kinda)
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg 
> wrote:
> 
>> I know JWT a bit and I wonder whether doing the signing part is just a bit
>> of Json (JSON-P) + commons-crypto?
>> After all JWT is especially designed to be lightweight and straight
>> forward.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau >> :
>>> 
>>> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro >> :
>>> 
 Thanks for the feedback Jon.
 
 I had a couple of exchanges with Rudy which is happy to contribute some
 code as well.
 From what I have understood and seen, most of the code is integration
>> code
 and there is at least from my current knowledge a little bit of code to
>> put
 together in a reusable manner in a reusable library (where ever it
>> sits).
 I was planning to do a quick prototype and get it to work from end to
>> end
 into a working branch so we can move the discussion forward and see
>> exactly
 where we go.
 
 Regarding the signing library, I am kinda on the same page.
 I don't see myself rewriting Johnzon to parse JSON and then Jose or
>> Nimbus
 to do signing. There is absolutely no point at least for the POC. Again,
 we'll see if I get something working what we can do.
 
 
 
>>> Agreeing for a PoC but for a production ready software it is if it can
>>> conflict or bring drawbacks to the users to import the solution. The json
>>> lib should at least be pluggable - avoids to shade/rewrite anything but
>> let
>>> the integrator use what he already has. Side note for json: for the
>> overall
>>> consistency using JSON-P makes it easy to get a common API which doesn't
>>> need any investment and solves that "plug your impl" smoothly. For the
>>> signing part it is a bit different since it will easily bring a huge
>> stack
>>> - how many bring jackson, simple-json, ... by default and are not
>>> pluggable. This is an issue and can even lead to not working
>> installations.
>>> If you doubt I have like 700 components to show you it is not a random or
>>> theorical thought. Investment is also quite light so not sure it does
>> worth
>>> speaking about it days.
>>> 
>>> 
 
 
 
 --
 Jean-Louis Monteiro
 http://twitter.com/jlouismonteiro
 http://www.tomitribe.com
 
 On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament 
 wrote:
 
> 
> 
> On 2018/02/12 20:42:58, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com
> 
> wrote:
>> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
>> wrote:
>> 
>>> No Andy, as mentionned in the discussion Geronimo hosts the
> microprofile
>>> @asf. This is why jwt should probably be done in geronimo which is
 the
> asf
>>> ee related project umbrella.
>>> 
>> 
>> I don't recall that discussion. Where did it take place?
> 
> I *think* he meant me.  The only time JWT came up on Geronimo was at
>> [1].
> I had mentioned bringing over an impl based on Jose4J, Romain felt very
> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
 is,
> but it seemed based on the discussion we had two different aims so it
> wasn't something I pushed forward on.  If there's interest within TomEE
 to
> get a JWT impl up and running, I'd be happy to help (though I do feel
> strongly relying on a 3rd party lib for the actual signature
>> validation +
> external sig support is important; to avoid that overhead).
> 
> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> about what projects are allowed to host.  For example, there's interest
> within Skywalking to host the CDI and JAX-RS extensions to support
 OpenApi;
> but this spec doesn't represent something any server vendor would
>> support
> since its really about your APM solution.  CXF happily took on the MP
 Rest
> Client when I proposed it; though I would hope TomEE relies on the CXF
> library instead of crafting their own client (selfish desires).  The
>> JWT

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro]

I was also thinking about a Johnzon extension (kinda)

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

On Tue, Feb 13, 2018 at 3:53 PM, Mark Struberg 
wrote:

> I know JWT a bit and I wonder whether doing the signing part is just a bit
> of Json (JSON-P) + commons-crypto?
> After all JWT is especially designed to be lightweight and straight
> forward.
>
> LieGrue,
> strub
>
>
>
> > Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau  >:
> >
> > 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro  >:
> >
> >> Thanks for the feedback Jon.
> >>
> >> I had a couple of exchanges with Rudy which is happy to contribute some
> >> code as well.
> >> From what I have understood and seen, most of the code is integration
> code
> >> and there is at least from my current knowledge a little bit of code to
> put
> >> together in a reusable manner in a reusable library (where ever it
> sits).
> >> I was planning to do a quick prototype and get it to work from end to
> end
> >> into a working branch so we can move the discussion forward and see
> exactly
> >> where we go.
> >>
> >> Regarding the signing library, I am kinda on the same page.
> >> I don't see myself rewriting Johnzon to parse JSON and then Jose or
> Nimbus
> >> to do signing. There is absolutely no point at least for the POC. Again,
> >> we'll see if I get something working what we can do.
> >>
> >>
> >>
> > Agreeing for a PoC but for a production ready software it is if it can
> > conflict or bring drawbacks to the users to import the solution. The json
> > lib should at least be pluggable - avoids to shade/rewrite anything but
> let
> > the integrator use what he already has. Side note for json: for the
> overall
> > consistency using JSON-P makes it easy to get a common API which doesn't
> > need any investment and solves that "plug your impl" smoothly. For the
> > signing part it is a bit different since it will easily bring a huge
> stack
> > - how many bring jackson, simple-json, ... by default and are not
> > pluggable. This is an issue and can even lead to not working
> installations.
> > If you doubt I have like 700 components to show you it is not a random or
> > theorical thought. Investment is also quite light so not sure it does
> worth
> > speaking about it days.
> >
> >
> >>
> >>
> >>
> >> --
> >> Jean-Louis Monteiro
> >> http://twitter.com/jlouismonteiro
> >> http://www.tomitribe.com
> >>
> >> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament 
> >> wrote:
> >>
> >>>
> >>>
> >>> On 2018/02/12 20:42:58, Jonathan Gallimore <
> jonathan.gallim...@gmail.com
> >>>
> >>> wrote:
>  On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>
>  wrote:
> 
> > No Andy, as mentionned in the discussion Geronimo hosts the
> >>> microprofile
> > @asf. This is why jwt should probably be done in geronimo which is
> >> the
> >>> asf
> > ee related project umbrella.
> >
> 
>  I don't recall that discussion. Where did it take place?
> >>>
> >>> I *think* he meant me.  The only time JWT came up on Geronimo was at
> [1].
> >>> I had mentioned bringing over an impl based on Jose4J, Romain felt very
> >>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
> >> is,
> >>> but it seemed based on the discussion we had two different aims so it
> >>> wasn't something I pushed forward on.  If there's interest within TomEE
> >> to
> >>> get a JWT impl up and running, I'd be happy to help (though I do feel
> >>> strongly relying on a 3rd party lib for the actual signature
> validation +
> >>> external sig support is important; to avoid that overhead).
> >>>
> >>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> >>> about what projects are allowed to host.  For example, there's interest
> >>> within Skywalking to host the CDI and JAX-RS extensions to support
> >> OpenApi;
> >>> but this spec doesn't represent something any server vendor would
> support
> >>> since its really about your APM solution.  CXF happily took on the MP
> >> Rest
> >>> Client when I proposed it; though I would hope TomEE relies on the CXF
> >>> library instead of crafting their own client (selfish desires).  The
> JWT
> >>> spec is weird, because it defined non MP runtime behavior in addition
> to
> >> MP
> >>> runtime behavior; so there may be more integration work in a fuller app
> >>> server like TomEE.
> >>>
> >>> 
> >>>
> >>> John
> >>>
> >>> [1]: https://lists.apache.org/thread.html/
> 4edc997cfe2e45aaf25bb118bc6216
> >>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >>>
> 
> 
> >
> > I understand it is not the most convenient for tomitribe which
> >> probably
> > perfers to own the full project(s) but as a foundation member I d
> >>> really
> > like to not let company details pollute projects
> 
> 
> > Also the 

Re: Implementing Microprofile JWT

[Mark Struberg]

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

LieGrue,
strub



> Am 13.02.2018 um 15:33 schrieb Romain Manni-Bucau :
> 
> 2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro :
> 
>> Thanks for the feedback Jon.
>> 
>> I had a couple of exchanges with Rudy which is happy to contribute some
>> code as well.
>> From what I have understood and seen, most of the code is integration code
>> and there is at least from my current knowledge a little bit of code to put
>> together in a reusable manner in a reusable library (where ever it sits).
>> I was planning to do a quick prototype and get it to work from end to end
>> into a working branch so we can move the discussion forward and see exactly
>> where we go.
>> 
>> Regarding the signing library, I am kinda on the same page.
>> I don't see myself rewriting Johnzon to parse JSON and then Jose or Nimbus
>> to do signing. There is absolutely no point at least for the POC. Again,
>> we'll see if I get something working what we can do.
>> 
>> 
>> 
> Agreeing for a PoC but for a production ready software it is if it can
> conflict or bring drawbacks to the users to import the solution. The json
> lib should at least be pluggable - avoids to shade/rewrite anything but let
> the integrator use what he already has. Side note for json: for the overall
> consistency using JSON-P makes it easy to get a common API which doesn't
> need any investment and solves that "plug your impl" smoothly. For the
> signing part it is a bit different since it will easily bring a huge stack
> - how many bring jackson, simple-json, ... by default and are not
> pluggable. This is an issue and can even lead to not working installations.
> If you doubt I have like 700 components to show you it is not a random or
> theorical thought. Investment is also quite light so not sure it does worth
> speaking about it days.
> 
> 
>> 
>> 
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 
>> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament 
>> wrote:
>> 
>>> 
>>> 
>>> On 2018/02/12 20:42:58, Jonathan Gallimore >> 
>>> wrote:
 On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
 wrote:
 
> No Andy, as mentionned in the discussion Geronimo hosts the
>>> microprofile
> @asf. This is why jwt should probably be done in geronimo which is
>> the
>>> asf
> ee related project umbrella.
> 
 
 I don't recall that discussion. Where did it take place?
>>> 
>>> I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
>>> I had mentioned bringing over an impl based on Jose4J, Romain felt very
>>> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
>> is,
>>> but it seemed based on the discussion we had two different aims so it
>>> wasn't something I pushed forward on.  If there's interest within TomEE
>> to
>>> get a JWT impl up and running, I'd be happy to help (though I do feel
>>> strongly relying on a 3rd party lib for the actual signature validation +
>>> external sig support is important; to avoid that overhead).
>>> 
>>> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
>>> about what projects are allowed to host.  For example, there's interest
>>> within Skywalking to host the CDI and JAX-RS extensions to support
>> OpenApi;
>>> but this spec doesn't represent something any server vendor would support
>>> since its really about your APM solution.  CXF happily took on the MP
>> Rest
>>> Client when I proposed it; though I would hope TomEE relies on the CXF
>>> library instead of crafting their own client (selfish desires).  The JWT
>>> spec is weird, because it defined non MP runtime behavior in addition to
>> MP
>>> runtime behavior; so there may be more integration work in a fuller app
>>> server like TomEE.
>>> 
>>> 
>>> 
>>> John
>>> 
>>> [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
>>> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>>> 
 
 
> 
> I understand it is not the most convenient for tomitribe which
>> probably
> perfers to own the full project(s) but as a foundation member I d
>>> really
> like to not let company details pollute projects
 
 
> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard
>>> company
> driven management making it no more in the OSS spirit.
> 
 
 I agree the discussion should happen first, and I note that the change
>>> has
 been reverted. I recall that we agreed on this list that we'd create
>> new
 git projects 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

2018-02-13 15:28 GMT+01:00 Jean-Louis Monteiro :

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


>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament 
> wrote:
>
> >
> >
> > On 2018/02/12 20:42:58, Jonathan Gallimore  >
> > wrote:
> > > On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > No Andy, as mentionned in the discussion Geronimo hosts the
> > microprofile
> > > > @asf. This is why jwt should probably be done in geronimo which is
> the
> > asf
> > > > ee related project umbrella.
> > > >
> > >
> > > I don't recall that discussion. Where did it take place?
> >
> > I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
> > I had mentioned bringing over an impl based on Jose4J, Romain felt very
> > strongly we mustn't rely on 3rd party libraries.  I'm not sure why that
> is,
> > but it seemed based on the discussion we had two different aims so it
> > wasn't something I pushed forward on.  If there's interest within TomEE
> to
> > get a JWT impl up and running, I'd be happy to help (though I do feel
> > strongly relying on a 3rd party lib for the actual signature validation +
> > external sig support is important; to avoid that overhead).
> >
> > RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> > about what projects are allowed to host.  For example, there's interest
> > within Skywalking to host the CDI and JAX-RS extensions to support
> OpenApi;
> > but this spec doesn't represent something any server vendor would support
> > since its really about your APM solution.  CXF happily took on the MP
> Rest
> > Client when I proposed it; though I would hope TomEE relies on the CXF
> > library instead of crafting their own client (selfish desires).  The JWT
> > spec is weird, because it defined non MP runtime behavior in addition to
> MP
> > runtime behavior; so there may be more integration work in a fuller app
> > server like TomEE.
> >
> > 
> >
> > John
> >
> > [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
> > 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
> >
> > >
> > >
> > > >
> > > > I understand it is not the most convenient for tomitribe which
> probably
> > > > perfers to own the full project(s) but as a foundation member I d
> > really
> > > > like to not let company details pollute projects
> > >
> > >
> > > > Also the discussion made clear to not do it in current repo whatever
> > > > project is used as umbrella so we should revert that and finish the
> > > > discussion before any action to not kill tomee project by a hard
> > company
> > > > driven management making it no more in the OSS spirit.
> > > >
> > >
> > > I agree the discussion should happen first, and I note that the change
> > has
> > > been reverted. I recall that we agreed on this list that we'd create
> new
> > > git projects for Sheldon and Chatterbox under the TomEE umbrella.
> Should
> > > other components sit under TomEE, I imagine that they would follow the
> > same
> > > pattern - i.e. discuss first, agree location, create repo or move
> things
> > > around as appropriate.
> > >
> > > I don't know what your specific issues are here, but I think you are
> > 

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro]

Thanks for the feedback Jon.

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

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





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

On Tue, Feb 13, 2018 at 12:43 PM, John D. Ament 
wrote:

>
>
> On 2018/02/12 20:42:58, Jonathan Gallimore 
> wrote:
> > On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > No Andy, as mentionned in the discussion Geronimo hosts the
> microprofile
> > > @asf. This is why jwt should probably be done in geronimo which is the
> asf
> > > ee related project umbrella.
> > >
> >
> > I don't recall that discussion. Where did it take place?
>
> I *think* he meant me.  The only time JWT came up on Geronimo was at [1].
> I had mentioned bringing over an impl based on Jose4J, Romain felt very
> strongly we mustn't rely on 3rd party libraries.  I'm not sure why that is,
> but it seemed based on the discussion we had two different aims so it
> wasn't something I pushed forward on.  If there's interest within TomEE to
> get a JWT impl up and running, I'd be happy to help (though I do feel
> strongly relying on a 3rd party lib for the actual signature validation +
> external sig support is important; to avoid that overhead).
>
> RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules
> about what projects are allowed to host.  For example, there's interest
> within Skywalking to host the CDI and JAX-RS extensions to support OpenApi;
> but this spec doesn't represent something any server vendor would support
> since its really about your APM solution.  CXF happily took on the MP Rest
> Client when I proposed it; though I would hope TomEE relies on the CXF
> library instead of crafting their own client (selfish desires).  The JWT
> spec is weird, because it defined non MP runtime behavior in addition to MP
> runtime behavior; so there may be more integration work in a fuller app
> server like TomEE.
>
> 
>
> John
>
> [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>
> >
> >
> > >
> > > I understand it is not the most convenient for tomitribe which probably
> > > perfers to own the full project(s) but as a foundation member I d
> really
> > > like to not let company details pollute projects
> >
> >
> > > Also the discussion made clear to not do it in current repo whatever
> > > project is used as umbrella so we should revert that and finish the
> > > discussion before any action to not kill tomee project by a hard
> company
> > > driven management making it no more in the OSS spirit.
> > >
> >
> > I agree the discussion should happen first, and I note that the change
> has
> > been reverted. I recall that we agreed on this list that we'd create new
> > git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> > other components sit under TomEE, I imagine that they would follow the
> same
> > pattern - i.e. discuss first, agree location, create repo or move things
> > around as appropriate.
> >
> > I don't know what your specific issues are here, but I think you are
> making
> > some assumptions that are simply not true.
> >
> > Jon
> >
> >
> >
> > >
> > > Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
> > > écrit :
> > >
> > > > "Parts of the components skeletons you just created"
> > > >
> > > > They're just logically named empty modules for pending work?
> > > >
> > > >
> > > > On 12/02/18 20:42, Mark Struberg wrote:
> > > >
> > > >> And what's that for?
> > > >>
> > > >> Is there any behind the scene stuff going on at Tomitribe or can we
> > > >> finally get back to discussing such things on the Apache lists?
> > > >>
> > > >> Before we go on I'd would first finish the discussion how we want to
> > > turn
> > > >> TomEE into an umbrella project or how the structure would be. And
> > > >> whether/how we want to integrate the modular Geronimo parts into one
> > > >> project or not.
> > > >>
> > > >> Parts of the components skeletons you just created do already exist
> at
> > > >> the ASF.
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > > >> 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

2018-02-13 12:43 GMT+01:00 John D. Ament :

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


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

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


>
> 
>
> John
>
> [1]: https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc6216
> 34c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E
>
> >
> >
> > >
> > > I understand it is not the most convenient for tomitribe which probably
> > > perfers to own the full project(s) but as a foundation member I d
> really
> > > like to not let company details pollute projects
> >
> >
> > > Also the discussion made clear to not do it in current repo whatever
> > > project is used as umbrella so we should revert that and finish the
> > > discussion before any action to not kill tomee project by a hard
> company
> > > driven management making it no more in the OSS spirit.
> > >
> >
> > I agree the discussion should happen first, and I note that the change
> has
> > been reverted. I recall that we agreed on this list that we'd create new
> > git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> > other components sit under TomEE, I imagine that they would follow the
> same
> > pattern - i.e. discuss first, agree location, create repo or move things
> > around as appropriate.
> >
> > I don't know what your specific issues are here, but I think you are
> making
> > some assumptions that are simply not true.
> >
> > Jon
> >
> >
> >
> > >
> > > Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
> > > écrit :
> > >
> > > > "Parts of the components skeletons you just created"
> > > >
> > > > They're just logically named empty modules for pending work?
> > > >
> > > >
> > > > On 12/02/18 20:42, Mark Struberg wrote:
> > > >
> > > >> And what's that for?
> > > >>
> > > >> Is there any behind the scene stuff going on at Tomitribe or can we
> > > >> finally get back to discussing such things on the Apache lists?
> > > >>
> > > >> Before we go on I'd would first finish the discussion how we want to
> > > turn
> > > >> TomEE into an umbrella project or how the structure would be. And
> > > >> whether/how we want to integrate the modular Geronimo parts into one
> > > >> project or not.
> > > >>
> > > >> Parts of the components skeletons you just created do already exist
> at
> > > >> the ASF.
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>
> > > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > > >> agumbre...@tomitribe.com> wrote:
> > > >>
> > > >>
> > > >> Added project stubs:
> > > >> 

Re: Implementing Microprofile JWT

[John D . Ament]

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

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

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



John

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

> 
> 
> >
> > I understand it is not the most convenient for tomitribe which probably
> > perfers to own the full project(s) but as a foundation member I d really
> > like to not let company details pollute projects
> 
> 
> > Also the discussion made clear to not do it in current repo whatever
> > project is used as umbrella so we should revert that and finish the
> > discussion before any action to not kill tomee project by a hard company
> > driven management making it no more in the OSS spirit.
> >
> 
> I agree the discussion should happen first, and I note that the change has
> been reverted. I recall that we agreed on this list that we'd create new
> git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> other components sit under TomEE, I imagine that they would follow the same
> pattern - i.e. discuss first, agree location, create repo or move things
> around as appropriate.
> 
> I don't know what your specific issues are here, but I think you are making
> some assumptions that are simply not true.
> 
> Jon
> 
> 
> 
> >
> > Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
> > écrit :
> >
> > > "Parts of the components skeletons you just created"
> > >
> > > They're just logically named empty modules for pending work?
> > >
> > >
> > > On 12/02/18 20:42, Mark Struberg wrote:
> > >
> > >> And what's that for?
> > >>
> > >> Is there any behind the scene stuff going on at Tomitribe or can we
> > >> finally get back to discussing such things on the Apache lists?
> > >>
> > >> Before we go on I'd would first finish the discussion how we want to
> > turn
> > >> TomEE into an umbrella project or how the structure would be. And
> > >> whether/how we want to integrate the modular Geronimo parts into one
> > >> project or not.
> > >>
> > >> Parts of the components skeletons you just created do already exist at
> > >> the ASF.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> > >> agumbre...@tomitribe.com> wrote:
> > >>
> > >>
> > >> Added project stubs:
> > >> https://github.com/apache/tomee/tree/master/microprofile
> > >>
> > >> Andy.
> > >>
> > >>
> > >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> > >> > Hi,
> > >> >
> > >> > Ok thanks guys.
> > >> > @Rudy, you are most welcome :)
> > >> >
> > >> > --
> > >> > Jean-Louis Monteiro
> > >> > http://twitter.com/jlouismonteiro
> > >> > http://www.tomitribe.com
> > >> >
> > >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> > >> rdebussc...@gmail.com >
> > >> > wrote:
> > >> >
> > >> >> I think it is a very important spec, also for non-microprofile
> > >> >> implementations as it can enhance the interoperability of all
> > servers.
> > >> >>
> > >> >> I'm also very interested in the implementation (and want to help a
> > bit
> > >> with
> > >> >> it also :) )
> > >> >>
> > >> >> regards
> > >> >> Rudy
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 2 February 2018 at 11:23, Mark Struberg  > >> >
> > >> >> wrote:
> > >> >>
> > >> >>> To clarify 

Re: Implementing Microprofile JWT

[David Blevins]

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

Thank you, Mark, for the patient response.


-David

Re: Implementing Microprofile JWT

[Mark Struberg]

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


 LieGrue,strub

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

Andy.


On 12/02/18 21:44, Mark Struberg wrote:
> Well, let's be a bit more specific.
> a.)
> No, Geronimo of course does not have have a monopoly on creating microprofile 
> implementations at the ASF. Nor does TomEE.
> Geronimo a good place for reusable JavaEE parts though. And G started to 
> implement Microprofile specifications 2 years ago already. There is already 
> quite a lot in existence over there. You really should take a look over the 
> fence.
>
> Instead of duplicating the work which is already done I would prefer if some 
> folks would help with more important tasks. E.g. finally finishing TomEE8. 
> Romain and I have so far been the ONLY ones working on that effort for the 
> whole last year.
> b.) > I understand it is not the most convenient for tomitribe which probably
>> perfers to own the full project(s) Tomitribe itself does not own TomEE nor 
>> created it, etc.The actual core part of TomEE (OpenEJB) is acually only a 
>> fraction of what the whole project is.It's an excellent aggregator project. 
>> But if you count in all the other parts which were needed to create TomEE7 
>> and 8, then the whole sum is about 20 times the size of openejb: tomcat, 
>> openwebbeans, bval, johnzon, geronimo-tx, geronimo-javamail, geronimo-specs, 
>> cxf, activemq, openjpa, MyFaces, etc etc Each of those projects has at
>
> c.) There have been a lot of talks about moving the reusable parts of 
> Geronimo under the umbrella of the TomEE project. That would be perfectly 
> fine. But I iterate it once again. There are 2 tasks to do before we can go 
> on:
> 1.) TomEE needs to become an umbrella project2.) the name of the reusable 
> components must be clearly separated from the TomEE Application 
> Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces 
> had - that people would not identify those components as being totally 
> independent of the TomEE application server and separately usable.
>
>
> LieGrue,strub
>  
>
>
>      On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau 
> wrote:
>  
>  No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> @asf. This is why jwt should probably be done in geronimo which is the asf
> ee related project umbrella.
>
> I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) but as a foundation member I d really
> like to not let company details pollute projects.
>
> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard company
> driven management making it no more in the OSS spirit.
>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
> écrit :
>
>> "Parts of the components skeletons you just created"
>>
>> They're just logically named empty modules for pending work?
>>
>>
>> On 12/02/18 20:42, Mark Struberg wrote:
>>
>>> And what's that for?
>>>
>>> Is there any behind the scene stuff going on at Tomitribe or can we
>>> finally get back to discussing such things on the Apache lists?
>>>
>>> Before we go on I'd would first finish the discussion how we want to turn
>>> TomEE into an umbrella project or how the structure would be. And
>>> whether/how we want to integrate the modular Geronimo parts into one
>>> project or not.
>>>
>>> Parts of the 

Re: Implementing Microprofile JWT

[Andy Gumbrecht]

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


Andy.


On 12/02/18 21:44, Mark Struberg wrote:

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

Instead of duplicating the work which is already done I would prefer if some 
folks would help with more important tasks. E.g. finally finishing TomEE8. 
Romain and I have so far been the ONLY ones working on that effort for the 
whole last year.
b.) > I understand it is not the most convenient for tomitribe which probably

perfers to own the full project(s) Tomitribe itself does not own TomEE nor 
created it, etc.The actual core part of TomEE (OpenEJB) is acually only a 
fraction of what the whole project is.It's an excellent aggregator project. But 
if you count in all the other parts which were needed to create TomEE7 and 8, 
then the whole sum is about 20 times the size of openejb: tomcat, openwebbeans, 
bval, johnzon, geronimo-tx, geronimo-javamail, geronimo-specs, cxf, activemq, 
openjpa, MyFaces, etc etc Each of those projects has at


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


LieGrue,strub
  



 On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau 
 wrote:
  
  No Andy, as mentionned in the discussion Geronimo hosts the microprofile

@asf. This is why jwt should probably be done in geronimo which is the asf
ee related project umbrella.

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

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

Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
écrit :


"Parts of the components skeletons you just created"

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


On 12/02/18 20:42, Mark Struberg wrote:


And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we
finally get back to discussing such things on the Apache lists?

Before we go on I'd would first finish the discussion how we want to turn
TomEE into an umbrella project or how the structure would be. And
whether/how we want to integrate the modular Geronimo parts into one
project or not.

Parts of the components skeletons you just created do already exist at
the ASF.

LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
agumbre...@tomitribe.com> wrote:


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

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:

Hi,

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

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

On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <

rdebussc...@gmail.com >

wrote:


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

Re: Implementing Microprofile JWT

[Jonathan Gallimore]

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

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

Jon

On Mon, Feb 12, 2018 at 8:44 PM, Mark Struberg 
wrote:

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


>
> c.) There have been a lot of talks about moving the reusable parts of
> Geronimo under the umbrella of the TomEE project. That would be perfectly
> fine. But I iterate it once again. There are 2 tasks to do before we can go
> on:
> 1.) TomEE needs to become an umbrella project2.) the name of the reusable
> components must be clearly separated from the TomEE Application
> Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces
> had - that people would not identify those components as being totally
> independent of the TomEE application server and separately usable.
>
>
> LieGrue,strub
>
>
>
> On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  No Andy, as mentionned in the discussion Geronimo hosts the microprofile
> @asf. This is why jwt should probably be done in geronimo which is the asf
> ee related project umbrella.
>
> I understand it is not the most convenient for tomitribe which probably
> perfers to own the full project(s) but as a foundation member I d really
> like to not let company details pollute projects.
>
> Also the discussion made clear to not do it in current repo whatever
> project is used as umbrella so we should revert that and finish the
> discussion before any action to not kill tomee project by a hard company
> driven management making it no more in the OSS spirit.
>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
> écrit :
>
> > "Parts of the components skeletons you just created"
> >
> > They're just logically named empty modules for pending work?
> >
> >
> > On 12/02/18 20:42, Mark Struberg wrote:
> >
> >> And what's that for?
> >>
> >> Is there any behind the scene stuff going on at Tomitribe or can we
> >> finally get back to discussing such things on the Apache lists?
> >>
> >> Before we go on I'd would first finish the discussion how we want to
> turn
> >> TomEE into an umbrella project or how the structure would be. And
> >> whether/how we want to integrate the modular Geronimo parts into one
> >> project or not.
> >>
> >> Parts of the components skeletons you just created do already exist at
> >> the ASF.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >> agumbre...@tomitribe.com> wrote:
> >>
> >>
> >> Added project stubs:
> >> https://github.com/apache/tomee/tree/master/microprofile
> >>
> >> Andy.
> >>
> >>
> >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >> > Hi,
> >> >
> >> > Ok thanks guys.
> >> > @Rudy, you are most welcome :)
> >> >
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >> rdebussc...@gmail.com >
> >> > wrote:
> >> >
> >> >> I think it is a very important spec, also for non-microprofile
> >> >> implementations as it can enhance the interoperability of all
> servers.
> >> >>
> >> >> I'm 

Re: Implementing Microprofile JWT

[Mark Struberg]

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

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


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


LieGrue,strub
 


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

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

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

Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
écrit :

> "Parts of the components skeletons you just created"
>
> They're just logically named empty modules for pending work?
>
>
> On 12/02/18 20:42, Mark Struberg wrote:
>
>> And what's that for?
>>
>> Is there any behind the scene stuff going on at Tomitribe or can we
>> finally get back to discussing such things on the Apache lists?
>>
>> Before we go on I'd would first finish the discussion how we want to turn
>> TomEE into an umbrella project or how the structure would be. And
>> whether/how we want to integrate the modular Geronimo parts into one
>> project or not.
>>
>> Parts of the components skeletons you just created do already exist at
>> the ASF.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
>> agumbre...@tomitribe.com> wrote:
>>
>>
>> Added project stubs:
>> https://github.com/apache/tomee/tree/master/microprofile
>>
>> Andy.
>>
>>
>> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
>> > Hi,
>> >
>> > Ok thanks guys.
>> > @Rudy, you are most welcome :)
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
>> rdebussc...@gmail.com >
>> > wrote:
>> >
>> >> I think it is a very important spec, also for non-microprofile
>> >> implementations as it can enhance the interoperability of all servers.
>> >>
>> >> I'm also very interested in the implementation (and want to help a bit
>> with
>> >> it also :) )
>> >>
>> >> regards
>> >> Rudy
>> >>
>> >>
>> >>
>> >> On 2 February 2018 at 11:23, Mark Struberg > >
>> >> wrote:
>> >>
>> >>> To clarify this even further:
>> >>> The Geronimo Server is now officially dead.
>> >>> But the Geronimo project is not. It alredy contains quite a few
>> modular
>> >>> parts which are reused in many ASF projects and also outside.
>> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>> >>> geronimo-config, xbean-finder, etc
>> >>>
>> >>> Of course it would probably make sense to fold those 2 projects
>> together,
>> >>> as already discussed in the past.
>> >>> I'm still all open to it, but I have an important criterium to fulfil:
>> >>> If we move those portable parts 

Re: Implementing Microprofile JWT

[Jonathan Gallimore]

On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau 
wrote:

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

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


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


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

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

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

Jon



>
> Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
> écrit :
>
> > "Parts of the components skeletons you just created"
> >
> > They're just logically named empty modules for pending work?
> >
> >
> > On 12/02/18 20:42, Mark Struberg wrote:
> >
> >> And what's that for?
> >>
> >> Is there any behind the scene stuff going on at Tomitribe or can we
> >> finally get back to discussing such things on the Apache lists?
> >>
> >> Before we go on I'd would first finish the discussion how we want to
> turn
> >> TomEE into an umbrella project or how the structure would be. And
> >> whether/how we want to integrate the modular Geronimo parts into one
> >> project or not.
> >>
> >> Parts of the components skeletons you just created do already exist at
> >> the ASF.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >> On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
> >> agumbre...@tomitribe.com> wrote:
> >>
> >>
> >> Added project stubs:
> >> https://github.com/apache/tomee/tree/master/microprofile
> >>
> >> Andy.
> >>
> >>
> >> On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> >> > Hi,
> >> >
> >> > Ok thanks guys.
> >> > @Rudy, you are most welcome :)
> >> >
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >> > On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <
> >> rdebussc...@gmail.com >
> >> > wrote:
> >> >
> >> >> I think it is a very important spec, also for non-microprofile
> >> >> implementations as it can enhance the interoperability of all
> servers.
> >> >>
> >> >> I'm also very interested in the implementation (and want to help a
> bit
> >> with
> >> >> it also :) )
> >> >>
> >> >> regards
> >> >> Rudy
> >> >>
> >> >>
> >> >>
> >> >> On 2 February 2018 at 11:23, Mark Struberg  >> >
> >> >> wrote:
> >> >>
> >> >>> To clarify this even further:
> >> >>> The Geronimo Server is now officially dead.
> >> >>> But the Geronimo project is not. It alredy contains quite a few
> >> modular
> >> >>> parts which are reused in many ASF projects and also outside.
> >> >>> Examples is the geronimo-transaction-manager, geronimo-javamail,
> >> >>> geronimo-config, xbean-finder, etc
> >> >>>
> >> >>> Of course it would probably make sense to fold those 2 projects
> >> together,
> >> >>> as already discussed in the past.
> >> >>> I'm still all open to it, but I have an important criterium to
> fulfil:
> >> >>> If we move those portable parts to TomEE, then this would mean that
> >> TomEE
> >> >>> would become an 'Umbrella project'.
> >> >>> And further that we would need a new name for those portable parts.
> >> >>> They would effectively be mainatained by the TomEE community (which
> >> has a
> >> >>> big overlap with Geronimo anyway) but those parts must clearly be
> >> >>> recognized separately from TomEE.
> >> >>>
> >> >>> Otherwise people will assume that those parts only work within
> TomEE -
> >> >>> where in reality they would even work on WildFly or Liberty, etc. or
> >> >> even a
> >> >>> naked Tomcat.
> >> >>> Got me?
> >> >>>
> >> >>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department'
> :)
> >> >>>
> >> >>> LieGrue,
> >> >>> strub
> >> >>>
> >> >>> PS: I'd also love to keep the org.apache.geronimo package name to
> ease
> >> >>> backward compatibility.
> >> >>>
> >> >>>
> >>  Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
> >> >> rmannibu...@gmail.com 
> >>  :
> >> 
> >>  2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
> >>  

Re: Implementing Microprofile JWT

[Andy Gumbrecht]

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



On 12/02/18 21:14, Andy Gumbrecht wrote:


"Parts of the components skeletons you just created"

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


On 12/02/18 20:42, Mark Struberg wrote:

And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we 
finally get back to discussing such things on the Apache lists?


Before we go on I'd would first finish the discussion how we want to 
turn TomEE into an umbrella project or how the structure would be. 
And whether/how we want to integrate the modular Geronimo parts into 
one project or not.


Parts of the components skeletons you just created do already exist 
at the ASF.


LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
 wrote:



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

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
>

> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a 
bit with

>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
>

>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few 
modular

>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects 
together,

>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to 
fulfil:
>>> If we move those portable parts to TomEE, then this would mean 
that TomEE

>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community 
(which has a

>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within 
TomEE -

>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts 
Department' :)

>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to 
ease

>>> backward compatibility.
>>>
>>>
 Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com 
 :

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

> Guys, I have a question:
>
> Why not a project to each implementation?
>
 this is the case but geronimo is used as an umbrella project.


> This way I can use just a specific if I want also.
>
 exactly the goal and user usage AFAIK ;)

 long story short: we learnt from the past errors and since 
always the

>>> same
 people work on these projects it is better to not split it accross N
 communities since
 it leads to a lot of efforts for these people. Having a single 
umbrella

 project with N subprojects reduces the administrative work etc and
>>> enhance
 the projects productivity.


> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com >
> wrote:
>
>> Hi JL,
>>
>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>> about it I think. Would probably saner to keep it all at the same
>> place
> for
>> the foundation.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github > rmannibucau> |
>> LinkedIn  | Book
>> > ee-8-high-performance>
>>
>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>> jlmonte...@tomitribe.com 
>> :
>>
>>> Hi all,
>>>
>>> I was wondering if we could have the Microprofile JWT 
implemented in

>> TomEE.
>>> What do you think?
>>>
>>> I was 

Re: Implementing Microprofile JWT

[Andy Gumbrecht]

Reverted.


On 12/02/18 21:14, Andy Gumbrecht wrote:


"Parts of the components skeletons you just created"

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


On 12/02/18 20:42, Mark Struberg wrote:

And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we 
finally get back to discussing such things on the Apache lists?


Before we go on I'd would first finish the discussion how we want to 
turn TomEE into an umbrella project or how the structure would be. 
And whether/how we want to integrate the modular Geronimo parts into 
one project or not.


Parts of the components skeletons you just created do already exist 
at the ASF.


LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
 wrote:



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

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
>

> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a 
bit with

>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
>

>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few 
modular

>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects 
together,

>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to 
fulfil:
>>> If we move those portable parts to TomEE, then this would mean 
that TomEE

>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community 
(which has a

>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within 
TomEE -

>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts 
Department' :)

>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to 
ease

>>> backward compatibility.
>>>
>>>
 Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com 
 :

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

> Guys, I have a question:
>
> Why not a project to each implementation?
>
 this is the case but geronimo is used as an umbrella project.


> This way I can use just a specific if I want also.
>
 exactly the goal and user usage AFAIK ;)

 long story short: we learnt from the past errors and since 
always the

>>> same
 people work on these projects it is better to not split it accross N
 communities since
 it leads to a lot of efforts for these people. Having a single 
umbrella

 project with N subprojects reduces the administrative work etc and
>>> enhance
 the projects productivity.


> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com >
> wrote:
>
>> Hi JL,
>>
>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>> about it I think. Would probably saner to keep it all at the same
>> place
> for
>> the foundation.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github > rmannibucau> |
>> LinkedIn  | Book
>> > ee-8-high-performance>
>>
>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>> jlmonte...@tomitribe.com 
>> :
>>
>>> Hi all,
>>>
>>> I was wondering if we could have the Microprofile JWT 
implemented in

>> TomEE.
>>> What do you think?
>>>
>>> I was reading the spec and I'd like to contribute that in.
>>>
>>> 

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

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

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

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

Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
écrit :

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

Re: Implementing Microprofile JWT

[Andy Gumbrecht]

"Parts of the components skeletons you just created"

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


On 12/02/18 20:42, Mark Struberg wrote:

And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we 
finally get back to discussing such things on the Apache lists?


Before we go on I'd would first finish the discussion how we want to 
turn TomEE into an umbrella project or how the structure would be. And 
whether/how we want to integrate the modular Geronimo parts into one 
project or not.


Parts of the components skeletons you just created do already exist at 
the ASF.


LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
 wrote:



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

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
>

> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a 
bit with

>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
>

>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few 
modular

>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects 
together,

>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to fulfil:
>>> If we move those portable parts to TomEE, then this would mean 
that TomEE

>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community 
(which has a

>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within TomEE -
>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>> backward compatibility.
>>>
>>>
 Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com 
 :

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

> Guys, I have a question:
>
> Why not a project to each implementation?
>
 this is the case but geronimo is used as an umbrella project.


> This way I can use just a specific if I want also.
>
 exactly the goal and user usage AFAIK ;)

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

 project with N subprojects reduces the administrative work etc and
>>> enhance
 the projects productivity.


> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com >
> wrote:
>
>> Hi JL,
>>
>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>> about it I think. Would probably saner to keep it all at the same
>> place
> for
>> the foundation.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github > rmannibucau> |
>> LinkedIn  | Book
>> > ee-8-high-performance>
>>
>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <
>>> jlmonte...@tomitribe.com 
>> :
>>
>>> Hi all,
>>>
>>> I was wondering if we could have the Microprofile JWT 
implemented in

>> TomEE.
>>> What do you think?
>>>
>>> I was reading the spec and I'd like to contribute that in.
>>>
>>> Jean-Louis
>>>
>>> --
>>> Jean-Louis Monteiro
>>> 

Re: Implementing Microprofile JWT

[Mark Struberg]

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



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

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a bit with
>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few modular
>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects together,
>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to fulfil:
>>> If we move those portable parts to TomEE, then this would mean that TomEE
>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community (which has a
>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within TomEE -
>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>> backward compatibility.
>>>
>>>
 Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
 :

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

> Guys, I have a question:
>
> Why not a project to each implementation?
>
 this is the case but geronimo is used as an umbrella project.


> This way I can use just a specific if I want also.
>
 exactly the goal and user usage AFAIK ;)

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


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

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


Ubique

  

Re: Implementing Microprofile JWT

[Andy Gumbrecht]

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


Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:

Hi,

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

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

On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
wrote:


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

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

regards
Rudy



On 2 February 2018 at 11:23, Mark Struberg 
wrote:


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

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

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

even a

naked Tomcat.
Got me?

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

LieGrue,
strub

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



Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <

rmannibu...@gmail.com

:

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


Guys, I have a question:

Why not a project to each implementation?


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



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


exactly the goal and user usage AFAIK ;)

long story short: we learnt from the past errors and since always the

same

people work on these projects it is better to not split it accross N
communities since
it leads to a lot of efforts for these people. Having a single umbrella
project with N subprojects reduces the administrative work etc and

enhance

the projects productivity.



On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Hi JL,

Microprofile apache effort is hosted in geronimo and John already

spoke

about it I think. Would probably saner to keep it all at the same

place

for

the foundation.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <

jlmonte...@tomitribe.com

:


Hi all,

I was wondering if we could have the Microprofile JWT implemented in

TomEE.

What do you think?

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

Jean-Louis

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





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


Ubique

Re: Implementing Microprofile JWT

[Jean-Louis Monteiro]

Hi,

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

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

On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
wrote:

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

Re: Implementing Microprofile JWT

[Mark Struberg]

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

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

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

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

LieGrue,
strub

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


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

Re: Implementing Microprofile JWT

[Otávio Gonçalves de Santana]

Guys, I have a question:

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

On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau 
wrote:

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

Re: Implementing Microprofile JWT

[Romain Manni-Bucau]

Hi JL,

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


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro :

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