date:20190904

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread David Blevins

> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau  wrote:
> 
> No I guess it was right, "that are" ;) = fork @G only when we need to
> change some impl/default provider.

Right.  A few things in my mind at least:

 - Industry health: we (Apache) are the only other implementations of 
Activation, JavaMail, JACC and similar "impl" specs.  If we give up on the 
impls we have, the industry collapses down to one impl and then what is the 
point of a spec?

 - Competitiveness: we have seen performance issues reported against our impls. 
 I distinctly remember one for JACC several years ago.  Where there are issues, 
there are also potential advantages.  If we can handle it, let's keep our impls 
and be competitive.

Where there is no actual impl I don't see any gain for the effort even if small.

 - Unavoidable EPL dependence: We're not likely to write a new Java compiler 
any time soon, so we're stuck with the EPL forever.

 - Likelyhood of increased EPL dependence: Given it is the default choice in 
Jakarta, more things will be created under it we may need.

 - Decreasing helping hands: Projects at Apache are switching over to the EPL 
libraries, so we will have fewer people willing to type in APIs for 
already-thin legal reasons.


-David

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread David Blevins

> On Sep 4, 2019, at 6:04 AM, Mark Struberg  wrote:
> 
> No, this is an intended situation.
> When one fully passes the TCK then you get the EFSL. This 'removes' the 
> copyleft nature of the EPL.
> The details are quite nested in the legal papers, but that's it basically.
> 
> If we just upgrade our existing API to be binary compat then we have no IP 
> issues.

I'm not sure I understand what's being said with the above.

If it is helpful I can add to the conversation:

 - The EFSL only applies to specification PDF, HTML and Javadoc.  It does not 
apply to the API jars.
 - The EFSL is not an OSI-approved license and not Approved by the Apache Board 
as safe to ship.



-David

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Romain Manni-Bucau

We cant, only impl+api are certified so no issue ;)

Le mer. 4 sept. 2019 à 17:01, Jean-Louis Monteiro 
a écrit :

> I'd like to certify some of them if possible of course.
>
> Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau 
> a écrit :
>
>> Not sure I'm following Mark, EPL is fine for us (
>> https://www.apache.org/legal/resolved.html) and G spec jars are not
>> officially certified so don't change of license anytime.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :
>>
>> > No, before that it was CDDL+GPL. It just moved to EPL, which is also
>> CatB
>> >
>> > LieGrue,
>> > strub
>> >
>> > > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> > >:
>> > >
>> > > @Mark: didn't change with jakarta donation? can you open a ticket on
>> > > jakartee tracker please?
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau  |  Blog
>> > >  | Old Blog
>> > >  | Github <
>> > https://github.com/rmannibucau> |
>> > > LinkedIn  | Book
>> > > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> > >
>> > >
>> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a
>> écrit
>> > :
>> > >
>> > >> No, this is an intended situation.
>> > >> When one fully passes the TCK then you get the EFSL. This 'removes'
>> the
>> > >> copyleft nature of the EPL.
>> > >> The details are quite nested in the legal papers, but that's it
>> > basically.
>> > >>
>> > >> If we just upgrade our existing API to be binary compat then we have
>> no
>> > IP
>> > >> issues.
>> > >>
>> > >> LieGrue,
>> > >> strub
>> > >>
>> > >>
>> > >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
>> > rmannibu...@gmail.com
>> > >>> :
>> > >>>
>> > >>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the
>> ambiguity
>> > >> for us.
>> > >>> That said it is good to reuse the same GAV for end users so we might
>> > ask
>> > >> jakarta to double license its api jars?
>> > >>>
>> > >>> Romain Manni-Bucau
>> > >>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> > >>>
>> > >>>
>> > >>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> > >> jlmonte...@tomitribe.com> a écrit :
>> > >>> Yep that was the point.
>> > >>> So I was asking if we should do the same yes or not.
>> > >>>
>> > >>> That seems to be your opinion Romain.
>> > >>> Mark on the other end is having some doubts about the license.
>> > >>> --
>> > >>> Jean-Louis Monteiro
>> > >>> http://twitter.com/jlouismonteiro
>> > >>> http://www.tomitribe.com
>> > >>>
>> > >>>
>> > >>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
>> > rmannibu...@gmail.com>
>> > >> wrote:
>> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> > >> jlmonte...@tomitribe.com>
>> > >>> a écrit :
>> > >>>
>> >  Thanks Romain. I'm fine with using Eclipse jars if from a legal
>> point
>> > >> of
>> >  view, it works.
>> >  Otherwise, I'd like to split our spec jars.
>> > 
>> >  What about MicroProfile?
>> > 
>> > >>>
>> > >>> We already agreed to not redo the API and use microprofile jars.
>> > >>>
>> > >>>
>> >  It's the same license and we are using them in our MicroProfile
>> >  implementations.
>> >  --
>> >  Jean-Louis Monteiro
>> >  http://twitter.com/jlouismonteiro
>> >  http://www.tomitribe.com
>> > 
>> > 
>> >  On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
>> > > > >>>
>> >  wrote:
>> > 
>> > > depends what their license is. EPL is (weak) copyleft. Thus I
>> would
>> > >> like
>> > > to avoid exposing it downstream as api.
>> > >
>> > > LieGrue,
>> > > strub
>> > >
>> > >
>> > >> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> > > rmannibu...@gmail.com>:
>> > >>
>> > >> If we still can't reuse jakata artifacts (their license is ok and
>> > >> there
>> > > is
>> > >> no impl reference inside so we should just use them, right?) it
>> > >> sounds
>> > >> natural
>> > >>
>> > >> Romain Manni-Bucau
>> > >> @rmannibucau  |  Blog
>> > >>  | Old Blog
>> > >>  | Github <
>> > > https://github.com/rmannibucau> |
>> > >> LinkedIn  | Book
>> > >> <
>> > >
>> > >>
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >>
>> > >>
>> > >>
>> > >> Le mar. 3 sept. 2019 à

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Jean-Louis Monteiro

I'd like to certify some of them if possible of course.

Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau  a
écrit :

> Not sure I'm following Mark, EPL is fine for us (
> https://www.apache.org/legal/resolved.html) and G spec jars are not
> officially certified so don't change of license anytime.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :
>
> > No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB
> >
> > LieGrue,
> > strub
> >
> > > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > @Mark: didn't change with jakarta donation? can you open a ticket on
> > > jakartee tracker please?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a
> écrit
> > :
> > >
> > >> No, this is an intended situation.
> > >> When one fully passes the TCK then you get the EFSL. This 'removes'
> the
> > >> copyleft nature of the EPL.
> > >> The details are quite nested in the legal papers, but that's it
> > basically.
> > >>
> > >> If we just upgrade our existing API to be binary compat then we have
> no
> > IP
> > >> issues.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > >>> :
> > >>>
> > >>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
> > >> for us.
> > >>> That said it is good to reuse the same GAV for end users so we might
> > ask
> > >> jakarta to double license its api jars?
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > >>>
> > >>>
> > >>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> > >> jlmonte...@tomitribe.com> a écrit :
> > >>> Yep that was the point.
> > >>> So I was asking if we should do the same yes or not.
> > >>>
> > >>> That seems to be your opinion Romain.
> > >>> Mark on the other end is having some doubts about the license.
> > >>> --
> > >>> Jean-Louis Monteiro
> > >>> http://twitter.com/jlouismonteiro
> > >>> http://www.tomitribe.com
> > >>>
> > >>>
> > >>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > >> wrote:
> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> > >> jlmonte...@tomitribe.com>
> > >>> a écrit :
> > >>>
> >  Thanks Romain. I'm fine with using Eclipse jars if from a legal
> point
> > >> of
> >  view, it works.
> >  Otherwise, I'd like to split our spec jars.
> > 
> >  What about MicroProfile?
> > 
> > >>>
> > >>> We already agreed to not redo the API and use microprofile jars.
> > >>>
> > >>>
> >  It's the same license and we are using them in our MicroProfile
> >  implementations.
> >  --
> >  Jean-Louis Monteiro
> >  http://twitter.com/jlouismonteiro
> >  http://www.tomitribe.com
> > 
> > 
> >  On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
> >  > >>>
> >  wrote:
> > 
> > > depends what their license is. EPL is (weak) copyleft. Thus I would
> > >> like
> > > to avoid exposing it downstream as api.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com>:
> > >>
> > >> If we still can't reuse jakata artifacts (their license is ok and
> > >> there
> > > is
> > >> no impl reference inside so we should just use them, right?) it
> > >> sounds
> > >> natural
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau  |  Blog
> > >>  | Old Blog
> > >>  | Github <
> > > https://github.com/rmannibucau> |
> > >> LinkedIn  | Book
> > >> <
> > >
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>
> > >>
> > >>
> > >> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com>
> > >> a écrit :
> > >>
> > >>> Hi all,
> > >>>
> > >>> I was digging into some other specifications and see what would
> > >> pass
> > >>> Jakarta TCK and realized that

Re: [metrics] switching SecurityValidator?

2019-09-04 Thread Romain Manni-Bucau

Hi Mark,

yes and no:


@ApplicationScoped
class MyConfig {
  void configureSecu(@Observes @Initialized(ApplicationScoped.class) final
Object whatever,
  final CdiMetricsEndpoint endpoint) {
  endpoint.setSecurityValidator();
  }
}

That said it is more intended to be configured with geronimo.metrics.*
config entries.
We can surely add more - default is for prometheus and dev envs IIRC.


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



Le mer. 4 sept. 2019 à 15:08, Mark Struberg  a écrit :

> hi folks!
>
> Right now the SecurityValidator in metrics cannot be switched easily,
> right?
> Wouldn't it be better to simply inject it? Or at least have a protected
> method getSecurityValidator() ?
>
> LieGrue,
> strub
>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Romain Manni-Bucau

Not sure I'm following Mark, EPL is fine for us (
https://www.apache.org/legal/resolved.html) and G spec jars are not
officially certified so don't change of license anytime.

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



Le mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :

> No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB
>
> LieGrue,
> strub
>
> > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau  >:
> >
> > @Mark: didn't change with jakarta donation? can you open a ticket on
> > jakartee tracker please?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit
> :
> >
> >> No, this is an intended situation.
> >> When one fully passes the TCK then you get the EFSL. This 'removes' the
> >> copyleft nature of the EPL.
> >> The details are quite nested in the legal papers, but that's it
> basically.
> >>
> >> If we just upgrade our existing API to be binary compat then we have no
> IP
> >> issues.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
> >> for us.
> >>> That said it is good to reuse the same GAV for end users so we might
> ask
> >> jakarta to double license its api jars?
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>>
> >>>
> >>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com> a écrit :
> >>> Yep that was the point.
> >>> So I was asking if we should do the same yes or not.
> >>>
> >>> That seems to be your opinion Romain.
> >>> Mark on the other end is having some doubts about the license.
> >>> --
> >>> Jean-Louis Monteiro
> >>> http://twitter.com/jlouismonteiro
> >>> http://www.tomitribe.com
> >>>
> >>>
> >>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >>> a écrit :
> >>>
>  Thanks Romain. I'm fine with using Eclipse jars if from a legal point
> >> of
>  view, it works.
>  Otherwise, I'd like to split our spec jars.
> 
>  What about MicroProfile?
> 
> >>>
> >>> We already agreed to not redo the API and use microprofile jars.
> >>>
> >>>
>  It's the same license and we are using them in our MicroProfile
>  implementations.
>  --
>  Jean-Louis Monteiro
>  http://twitter.com/jlouismonteiro
>  http://www.tomitribe.com
> 
> 
>  On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
>  >>>
>  wrote:
> 
> > depends what their license is. EPL is (weak) copyleft. Thus I would
> >> like
> > to avoid exposing it downstream as api.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com>:
> >>
> >> If we still can't reuse jakata artifacts (their license is ok and
> >> there
> > is
> >> no impl reference inside so we should just use them, right?) it
> >> sounds
> >> natural
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> > https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>
> >>
> >>
> >> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com>
> >> a écrit :
> >>
> >>> Hi all,
> >>>
> >>> I was digging into some other specifications and see what would
> >> pass
> >>> Jakarta TCK and realized that geronimo-security_1.0_spec content
> > actually
> >>> mixes 2 specifications.
> >>>
> >>> https://github.com/eclipse-ee4j/security-api
> >>>
> >>> and
> >>>
> >>> https://github.com/eclipse-ee4j/jaspic
> >>>
> >>> I thought the initial intent was to create a specific artifact per
> >>> specification.
> >>> Mixing them is a bit annoying from a certification perspective.
> >>> It's also not clean because in Tomcat for instance, there

[metrics] switching SecurityValidator?

2019-09-04 Thread Mark Struberg

hi folks!

Right now the SecurityValidator in metrics cannot be switched easily, right?
Wouldn't it be better to simply inject it? Or at least have a protected method 
getSecurityValidator() ?

LieGrue,
strub

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Mark Struberg

No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB

LieGrue,
strub

> Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau :
> 
> @Mark: didn't change with jakarta donation? can you open a ticket on
> jakartee tracker please?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :
> 
>> No, this is an intended situation.
>> When one fully passes the TCK then you get the EFSL. This 'removes' the
>> copyleft nature of the EPL.
>> The details are quite nested in the legal papers, but that's it basically.
>> 
>> If we just upgrade our existing API to be binary compat then we have no IP
>> issues.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau >> :
>>> 
>>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
>> for us.
>>> That said it is good to reuse the same GAV for end users so we might ask
>> jakarta to double license its api jars?
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> 
>>> 
>>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> a écrit :
>>> Yep that was the point.
>>> So I was asking if we should do the same yes or not.
>>> 
>>> That seems to be your opinion Romain.
>>> Mark on the other end is having some doubts about the license.
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
>>> 
>>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>>> a écrit :
>>> 
 Thanks Romain. I'm fine with using Eclipse jars if from a legal point
>> of
 view, it works.
 Otherwise, I'd like to split our spec jars.
 
 What about MicroProfile?
 
>>> 
>>> We already agreed to not redo the API and use microprofile jars.
>>> 
>>> 
 It's the same license and we are using them in our MicroProfile
 implementations.
 --
 Jean-Louis Monteiro
 http://twitter.com/jlouismonteiro
 http://www.tomitribe.com
 
 
 On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg >> 
 wrote:
 
> depends what their license is. EPL is (weak) copyleft. Thus I would
>> like
> to avoid exposing it downstream as api.
> 
> LieGrue,
> strub
> 
> 
>> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>> 
>> If we still can't reuse jakata artifacts (their license is ok and
>> there
> is
>> no impl reference inside so we should just use them, right?) it
>> sounds
>> natural
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> 
>> 
>> 
>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
>> a écrit :
>> 
>>> Hi all,
>>> 
>>> I was digging into some other specifications and see what would
>> pass
>>> Jakarta TCK and realized that geronimo-security_1.0_spec content
> actually
>>> mixes 2 specifications.
>>> 
>>> https://github.com/eclipse-ee4j/security-api
>>> 
>>> and
>>> 
>>> https://github.com/eclipse-ee4j/jaspic
>>> 
>>> I thought the initial intent was to create a specific artifact per
>>> specification.
>>> Mixing them is a bit annoying from a certification perspective.
>>> It's also not clean because in Tomcat for instance, there is
>> already
>>> jaspic API so it becomes a duplicate.
>>> 
>>> Would it be possible to split them up in 2 artifacts?
>>> 
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
> 
> 
>> 
>>

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Romain Manni-Bucau

@Mark: didn't change with jakarta donation? can you open a ticket on
jakartee tracker please?

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



Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :

> No, this is an intended situation.
> When one fully passes the TCK then you get the EFSL. This 'removes' the
> copyleft nature of the EPL.
> The details are quite nested in the legal papers, but that's it basically.
>
> If we just upgrade our existing API to be binary compat then we have no IP
> issues.
>
> LieGrue,
> strub
>
>
> > Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau  >:
> >
> > MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
> for us.
> > That said it is good to reuse the same GAV for end users so we might ask
> jakarta to double license its api jars?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> a écrit :
> > Yep that was the point.
> > So I was asking if we should do the same yes or not.
> >
> > That seems to be your opinion Romain.
> > Mark on the other end is having some doubts about the license.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
> wrote:
> > Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> > a écrit :
> >
> > > Thanks Romain. I'm fine with using Eclipse jars if from a legal point
> of
> > > view, it works.
> > > Otherwise, I'd like to split our spec jars.
> > >
> > > What about MicroProfile?
> > >
> >
> > We already agreed to not redo the API and use microprofile jars.
> >
> >
> > > It's the same license and we are using them in our MicroProfile
> > > implementations.
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg  >
> > > wrote:
> > >
> > >> depends what their license is. EPL is (weak) copyleft. Thus I would
> like
> > >> to avoid exposing it downstream as api.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>:
> > >> >
> > >> > If we still can't reuse jakata artifacts (their license is ok and
> there
> > >> is
> > >> > no impl reference inside so we should just use them, right?) it
> sounds
> > >> > natural
> > >> >
> > >> > Romain Manni-Bucau
> > >> > @rmannibucau  |  Blog
> > >> >  | Old Blog
> > >> >  | Github <
> > >> https://github.com/rmannibucau> |
> > >> > LinkedIn  | Book
> > >> > <
> > >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > >> jlmonte...@tomitribe.com>
> > >> > a écrit :
> > >> >
> > >> >> Hi all,
> > >> >>
> > >> >> I was digging into some other specifications and see what would
> pass
> > >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> > >> actually
> > >> >> mixes 2 specifications.
> > >> >>
> > >> >> https://github.com/eclipse-ee4j/security-api
> > >> >>
> > >> >> and
> > >> >>
> > >> >> https://github.com/eclipse-ee4j/jaspic
> > >> >>
> > >> >> I thought the initial intent was to create a specific artifact per
> > >> >> specification.
> > >> >> Mixing them is a bit annoying from a certification perspective.
> > >> >> It's also not clean because in Tomcat for instance, there is
> already
> > >> >> jaspic API so it becomes a duplicate.
> > >> >>
> > >> >> Would it be possible to split them up in 2 artifacts?
> > >> >>
> > >> >> --
> > >> >> Jean-Louis Monteiro
> > >> >> http://twitter.com/jlouismonteiro
> > >> >> http://www.tomitribe.com
> > >> >>
> > >>
> > >>
>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Mark Struberg

No, this is an intended situation.
When one fully passes the TCK then you get the EFSL. This 'removes' the 
copyleft nature of the EPL.
The details are quite nested in the legal papers, but that's it basically.

If we just upgrade our existing API to be binary compat then we have no IP 
issues.

LieGrue,
strub


> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau :
> 
> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for us.
> That said it is good to reuse the same GAV for end users so we might ask 
> jakarta to double license its api jars?
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro  
> a écrit :
> Yep that was the point.
> So I was asking if we should do the same yes or not. 
> 
> That seems to be your opinion Romain.
> Mark on the other end is having some doubts about the license.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau  
> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro 
> a écrit :
> 
> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
> > view, it works.
> > Otherwise, I'd like to split our spec jars.
> >
> > What about MicroProfile?
> >
> 
> We already agreed to not redo the API and use microprofile jars.
> 
> 
> > It's the same license and we are using them in our MicroProfile
> > implementations.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
> > wrote:
> >
> >> depends what their license is. EPL is (weak) copyleft. Thus I would like
> >> to avoid exposing it downstream as api.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >> >
> >> > If we still can't reuse jakata artifacts (their license is ok and there
> >> is
> >> > no impl reference inside so we should just use them, right?) it sounds
> >> > natural
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau  |  Blog
> >> >  | Old Blog
> >> >  | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn  | Book
> >> > <
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> > a écrit :
> >> >
> >> >> Hi all,
> >> >>
> >> >> I was digging into some other specifications and see what would pass
> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> >> actually
> >> >> mixes 2 specifications.
> >> >>
> >> >> https://github.com/eclipse-ee4j/security-api
> >> >>
> >> >> and
> >> >>
> >> >> https://github.com/eclipse-ee4j/jaspic
> >> >>
> >> >> I thought the initial intent was to create a specific artifact per
> >> >> specification.
> >> >> Mixing them is a bit annoying from a certification perspective.
> >> >> It's also not clean because in Tomcat for instance, there is already
> >> >> jaspic API so it becomes a duplicate.
> >> >>
> >> >> Would it be possible to split them up in 2 artifacts?
> >> >>
> >> >> --
> >> >> Jean-Louis Monteiro
> >> >> http://twitter.com/jlouismonteiro
> >> >> http://www.tomitribe.com
> >> >>
> >>
> >>

Re: Java EE 8 versions of APIs

2019-09-04 Thread Jean-Louis Monteiro

Security and annotations are up for vote.
I have JavaMail 1.6 created and almost ready for VOTE.

We don't have standalone TCK to run for those, but when they are released,
I'll get them all integrated and I'll push a TCK build on TomEE so we have
a view on what we need to fix.

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


On Tue, Sep 3, 2019 at 6:16 PM David Blevins 
wrote:

> See this note on our activation thread.  Long story short, our version 1.1
> is legitimate and the exact version expected for Java EE 8 on Java 8.
>
>  -
> https://lists.apache.org/thread.html/89f81b0584dffca7d979a4fdedc6fe7b4f3c547848b0159b1702857e@
> 
>
> On JavaMail, my recommendation would be to update asap, but not hold up
> the TomEE 8.0.0 final release.
>
> IMHO, we should try to be vote-ready on Friday.  If we can get it done in
> that time, cool.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Sep 3, 2019, at 8:48 AM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> >
> > Trying to pull this message up in the list.
> >
> > If we want to release Apache TomEE 8.0.0 before CodeOne, we need
> JavaMail,
> > Activation and some others.
> > For the others, I think I managed to get them up for vote and ready.
> >
> > For Activation and JavaMail it's also an implementation so there is more
> > work involved and I am not sure we can get it done by CodeOne.
> > Of course it's not a good reason, but I still want to revive this topic
> so
> > we can decide all together how we want to proceed.
> >
> > Do we update/create our specs in Geronimo?
> > Do we use the eclipse jars?
> >
> > thoughts
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, Aug 15, 2019 at 5:53 AM David Blevins 
> > wrote:
> >
> >>> On Aug 14, 2019, at 2:05 AM, Alex The Rocker 
> >> wrote:
> >>>
> >>> Okay; for EDL I see it's compatible with Apache licensing, but
> >>> strangely, JAXB license does not look like an EDL:
> >>> https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md
> >>>
> >>> Am I mistaking or this is actually "cheesy" ?
> >>
> >> I pulled down the official text here and did a quick reformat to match
> it
> >> to the LICENSE.md
> >>
> >> - https://www.eclipse.org/org/documents/edl-v10.php
> >>
> >> Sans the copyright statement, both came out identical in a diff, so we
> >> appear good.
> >>
> >> We will want to make sure our NOTICE file does contain the copyright
> >> statement, so that is a definitely good catch.
> >>
> >>
> >> -David
> >>
> >>> Le mer. 14 août 2019 à 10:37, David Blevins  a
> >> écrit :
> 
> > On Aug 14, 2019, at 1:23 AM, Alex The Rocker 
> >> wrote:
> >
> > Hello,
> >
> > How about JAXB which is not EPL but EDL 1.0 ?
> > (see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)
> 
>  EDL is an approved license.  Here's the complete naughty and nice list
> >> as it where :)
> 
>  - https://apache.org/legal/resolved.html
> 
>  The interesting thing about jaxb-api is there is only one
> >> implementation in the world and it is also EDL and no longer included in
> >> the JVM.  If we typed in the API, 98% of the other JAXB code we ship
> would
> >> still be EDL.
> 
> 
>  -David
> 
> > Le mer. 14 août 2019 à 10:16, David Blevins  >
> >> a écrit :
> >>
> >> This is really the better thread to talk about how to handle the
> gaps
> >> in our Java EE 8 APIs and support.
> >>
> >> As noted, there is not license victory to be won.  We have had EPL
> >> and CDDL dependencies since v1.0 in 2011.
> >>
> >> From a Geronimo perspective, we typed in the APIs and created all
> >> those spec jars because there were no open source options that weren't
> the
> >> JBoss GPL versions.  GlassFish didn't exist yet.  When GlassFish came
> >> about, we kept up the practice largely out of habit.  We did have an
> >> unavoidable CDDL via the xml schemas and JAXB RI, so our licensing
> victory
> >> wasn't quite there.
> >>
> >> This is really a resources and timeline issue.
> >>
> >> Some of these specs are actually implementations, specifically:
> >>
> >> - JavaMail 1.6
> >> - JACC 1.6
> >> - Activation 1.2
> >>
> >> If we decide we want the Geronimo versions to be upgraded
> >> (implemented) and this is important for TomEE 8, we should expect that
> to
> >> ship sometime 2020.
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On Aug 13, 2019, at 12:10 AM, David Blevins <
> david.blev...@gmail.com>
> >> wrote:
> >>>
> >>> I did a small gap-analysis of where we're still short on Java EE 8
> >> APIs from the perspective of our javaee-api jar:
> >>>
> >>> - https://issues.apache.org/jira/browse/TOMEE-2620
> >>>
> >>> Specific callouts are

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Romain Manni-Bucau

exactly.
Main ambiguity is for API using a provider as only impl dependency like
jsonp/jsonb (
https://github.com/apache/geronimo-specs/blob/trunk/geronimo-jsonb_1.0_spec/src/main/java/javax/json/bind/spi/JsonbProvider.java#L30
).
Think it makes sense to keep it hosted to change this value even if system
props/SPI enable to switch it since it enables to make fatjars smooths
without configs and to ensure we load the right default but it is really a
single string so can be discussed.

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



Le mer. 4 sept. 2019 à 11:16, Jean-Louis Monteiro 
a écrit :

> so for instance activation and javamail would stay in Geronimo Specs and
> let's say @Inject would be Eclipse?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau 
> wrote:
>
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > > This is my current thinking as well; maintain apis that are impls, use
>> > the EPL version otherwise.
>> > I believe you meant "that are not impls ..."
>> >
>> > I'll make the changes on the javaee-api jar
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
>> > wrote:
>> >
>> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> >> wrote:
>> >> >
>> >> > If we still can't reuse jakata artifacts (their license is ok and
>> there
>> >> is no impl reference inside so we should just use them, right?) it
>> sounds
>> >> natural
>> >>
>> >> This is my current thinking as well; maintain apis that are impls, use
>> >> the EPL version otherwise.
>> >>
>> >> We do have a handful of EPL dependencies, such as ECJ which Tomcat
>> itself
>> >> uses.  Also as more projects like CXF switch over using the Jakarta
>> >> versions, our excludes just get harder to manage.
>> >>
>> >>
>> >> -David
>> >>
>> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com> a écrit :
>> >> > Hi all,
>> >> >
>> >> > I was digging into some other specifications and see what would pass
>> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> actually
>> >> mixes 2 specifications.
>> >> >
>> >> > https://github.com/eclipse-ee4j/security-api
>> >> >
>> >> > and
>> >> >
>> >> > https://github.com/eclipse-ee4j/jaspic
>> >> >
>> >> > I thought the initial intent was to create a specific artifact per
>> >> specification.
>> >> > Mixing them is a bit annoying from a certification perspective.
>> >> > It's also not clean because in Tomcat for instance, there is already
>> >> jaspic API so it becomes a duplicate.
>> >> >
>> >> > Would it be possible to split them up in 2 artifacts?
>> >> >
>> >> > --
>> >> > Jean-Louis Monteiro
>> >> > http://twitter.com/jlouismonteiro
>> >> > http://www.tomitribe.com
>> >>
>> >>
>>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Jean-Louis Monteiro

so for instance activation and javamail would stay in Geronimo Specs and
let's say @Inject would be Eclipse?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau 
wrote:

> No I guess it was right, "that are" ;) = fork @G only when we need to
> change some impl/default provider.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> a écrit :
>
> > > This is my current thinking as well; maintain apis that are impls, use
> > the EPL version otherwise.
> > I believe you meant "that are not impls ..."
> >
> > I'll make the changes on the javaee-api jar
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
> > wrote:
> >
> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau  >
> >> wrote:
> >> >
> >> > If we still can't reuse jakata artifacts (their license is ok and
> there
> >> is no impl reference inside so we should just use them, right?) it
> sounds
> >> natural
> >>
> >> This is my current thinking as well; maintain apis that are impls, use
> >> the EPL version otherwise.
> >>
> >> We do have a handful of EPL dependencies, such as ECJ which Tomcat
> itself
> >> uses.  Also as more projects like CXF switch over using the Jakarta
> >> versions, our excludes just get harder to manage.
> >>
> >>
> >> -David
> >>
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com> a écrit :
> >> > Hi all,
> >> >
> >> > I was digging into some other specifications and see what would pass
> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> actually
> >> mixes 2 specifications.
> >> >
> >> > https://github.com/eclipse-ee4j/security-api
> >> >
> >> > and
> >> >
> >> > https://github.com/eclipse-ee4j/jaspic
> >> >
> >> > I thought the initial intent was to create a specific artifact per
> >> specification.
> >> > Mixing them is a bit annoying from a certification perspective.
> >> > It's also not clean because in Tomcat for instance, there is already
> >> jaspic API so it becomes a duplicate.
> >> >
> >> > Would it be possible to split them up in 2 artifacts?
> >> >
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >>
> >>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Romain Manni-Bucau

No I guess it was right, "that are" ;) = fork @G only when we need to
change some impl/default provider.


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



Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro 
a écrit :

> > This is my current thinking as well; maintain apis that are impls, use
> the EPL version otherwise.
> I believe you meant "that are not impls ..."
>
> I'll make the changes on the javaee-api jar
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
> wrote:
>
>> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau 
>> wrote:
>> >
>> > If we still can't reuse jakata artifacts (their license is ok and there
>> is no impl reference inside so we should just use them, right?) it sounds
>> natural
>>
>> This is my current thinking as well; maintain apis that are impls, use
>> the EPL version otherwise.
>>
>> We do have a handful of EPL dependencies, such as ECJ which Tomcat itself
>> uses.  Also as more projects like CXF switch over using the Jakarta
>> versions, our excludes just get harder to manage.
>>
>>
>> -David
>>
>> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> a écrit :
>> > Hi all,
>> >
>> > I was digging into some other specifications and see what would pass
>> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
>> mixes 2 specifications.
>> >
>> > https://github.com/eclipse-ee4j/security-api
>> >
>> > and
>> >
>> > https://github.com/eclipse-ee4j/jaspic
>> >
>> > I thought the initial intent was to create a specific artifact per
>> specification.
>> > Mixing them is a bit annoying from a certification perspective.
>> > It's also not clean because in Tomcat for instance, there is already
>> jaspic API so it becomes a duplicate.
>> >
>> > Would it be possible to split them up in 2 artifacts?
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>>
>>

Re: DISCUSS geronimo-security_1.0_spec content unclear

2019-09-04 Thread Jean-Louis Monteiro

> This is my current thinking as well; maintain apis that are impls, use
the EPL version otherwise.
I believe you meant "that are not impls ..."

I'll make the changes on the javaee-api jar

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


On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
wrote:

> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau 
> wrote:
> >
> > If we still can't reuse jakata artifacts (their license is ok and there
> is no impl reference inside so we should just use them, right?) it sounds
> natural
>
> This is my current thinking as well; maintain apis that are impls, use the
> EPL version otherwise.
>
> We do have a handful of EPL dependencies, such as ECJ which Tomcat itself
> uses.  Also as more projects like CXF switch over using the Jakarta
> versions, our excludes just get harder to manage.
>
>
> -David
>
> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> a écrit :
> > Hi all,
> >
> > I was digging into some other specifications and see what would pass
> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
> mixes 2 specifications.
> >
> > https://github.com/eclipse-ee4j/security-api
> >
> > and
> >
> > https://github.com/eclipse-ee4j/jaspic
> >
> > I thought the initial intent was to create a specific artifact per
> specification.
> > Mixing them is a bit annoying from a certification perspective.
> > It's also not clean because in Tomcat for instance, there is already
> jaspic API so it becomes a duplicate.
> >
> > Would it be possible to split them up in 2 artifacts?
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: [metrics] switching SecurityValidator?

Re: DISCUSS geronimo-security_1.0_spec content unclear

[metrics] switching SecurityValidator?

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: Java EE 8 versions of APIs

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

Re: DISCUSS geronimo-security_1.0_spec content unclear

15 matches

Site Navigation

Mail list logo

Footer information