Re: TomEE8 TCK status

[Mark Struberg]

Or just compile it yourself from source:

https://svn.apache.org/repos/asf/tomee/javaee-api/trunk

LieGrue,
strub



> Am 16.02.2018 um 07:41 schrieb Mark Struberg :
> 
> I think we did, but I probably did not deploy our javaee-api yet.
> 
> Started the deploy jus tnow.
> 
> LieGrue,
> strub
> 
>> Am 16.02.2018 um 07:14 schrieb Romain Manni-Bucau :
>> 
>> Dont think our ee api has upgraded to
>> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxrs_2.1_spec/
>> yet since we didnt have cxf 3.2.
>> 
>> Le 16 févr. 2018 00:49, "Jonathan Gallimore" 
>> a écrit :
>> 
>>> Ok, locally (with the merge), I get test errors due
>>> to: java.lang.NoClassDefFoundError:
>>> javax/ws/rs/client/CompletionStageRxInvoker. Possibly a bad javaee
>>> dependency or something. I'll do a compare tomorrow and try and get that
>>> resolved, and get my changes pushed.
>>> 
>>> Jon
>>> 
>>> On Thu, Feb 15, 2018 at 6:41 PM, Mark Struberg 
>>> wrote:
>>> 
 PS: xbean-asm6 is needed for java9 support.
 Already using it in OWB and Meecrowave without any problems.
 So all should work fine.
 
 LieGrue,
 strub
 
 
> Am 15.02.2018 um 19:20 schrieb Mark Struberg  :
> 
> oki great, I've just upgraded to tomcat-9.0.5 and right now upgrading
>>> to
 xbean-asm6-shaded.
> Will ping you once done.
> 
> LieGrue,
> strub
> 
> 
>> Am 15.02.2018 um 18:27 schrieb Jonathan Gallimore <
 jonathan.gallim...@gmail.com>:
>> 
>> We definitely need a tomee-7 branch. I have done a merge of master to
 the
>> tomee8_fb branch, and I'm making sure it builds and tests pass etc,
 before
>> pushing.
>> 
>> Jon
>> 
>> On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg
 
>> wrote:
>> 
>>> probably a good idea.
>>> 
>>> A tomee7 release should still be cut. But that could be done on a
 tomee7.x
>>> branch as well
>>> 
>>> Will create a separate thread.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
 Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau <
 rmannibu...@gmail.com
 :
 
 and probably switch the branch. master doesnt get much activity and
>>> in
>>> any
 case all the activity it gets can be done on the 8 branch
 
 
 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github >> rmannibucau> |
 LinkedIn  | Book
 >> ee-8-high-performance>
 
 2018-02-15 18:05 GMT+01:00 Mark Struberg  and now we should be passing both the tck/cdi-embedded and
>>> tck/cdi-tomee!
> 
> So it's time to move forward to updating various dependencies,
 samples
>>> etc
> ;)
> 
> LieGrue,
> strub
> 
>> Am 15.02.2018 um 11:42 schrieb Mark Struberg
 > :
>> 
>> Really appreciated, thanks Jon!
>> 
>> Due to the upgrade to Tomcat-9 we also might have to fix a few
>>> other
> tests along the line.
>> I mainly focused on the CDI TCK for now as this is naturally the
 area
> where I can be of most use.
>> I'll also gonna release OWB tonight or so. Just wanted to first
>>> fix
 the
> TomEE tck to really catch all odds in OWB.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
>>> 
>>> At the risk of adding to my ever-growing task list and
>>> potentially
> becoming
>>> a bottleneck, I did some EAR / RAR related fixes in master. I'll
 port
> those
>>> forward and help look at these tests.
>>> 
>>> Jon
>>> 
>>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
> 
>>> wrote:
>>> 
 We now pass all tests in tck/cdi-embedded
 And we have only 3 failing tests in tck/cdi-tomee.
 
 
 
 
 
 Those tests are all EAR related.
 Maybe they are only Arquillian adapter issues?
 
 LieGrue,
 strub
 
 
 
> Am 08.02.2018 um 13:30 schrieb Mark Struberg
>  :
> 
> Well, 

Re: TomEE8 TCK status

[Mark Struberg]

I think we did, but I probably did not deploy our javaee-api yet.

Started the deploy jus tnow.

LieGrue,
strub

> Am 16.02.2018 um 07:14 schrieb Romain Manni-Bucau :
> 
> Dont think our ee api has upgraded to
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxrs_2.1_spec/
> yet since we didnt have cxf 3.2.
> 
> Le 16 févr. 2018 00:49, "Jonathan Gallimore" 
> a écrit :
> 
>> Ok, locally (with the merge), I get test errors due
>> to: java.lang.NoClassDefFoundError:
>> javax/ws/rs/client/CompletionStageRxInvoker. Possibly a bad javaee
>> dependency or something. I'll do a compare tomorrow and try and get that
>> resolved, and get my changes pushed.
>> 
>> Jon
>> 
>> On Thu, Feb 15, 2018 at 6:41 PM, Mark Struberg 
>> wrote:
>> 
>>> PS: xbean-asm6 is needed for java9 support.
>>> Already using it in OWB and Meecrowave without any problems.
>>> So all should work fine.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
 Am 15.02.2018 um 19:20 schrieb Mark Struberg > to
>>> xbean-asm6-shaded.
 Will ping you once done.
 
 LieGrue,
 strub
 
 
> Am 15.02.2018 um 18:27 schrieb Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com>:
> 
> We definitely need a tomee-7 branch. I have done a merge of master to
>>> the
> tomee8_fb branch, and I'm making sure it builds and tests pass etc,
>>> before
> pushing.
> 
> Jon
> 
> On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg
>>> 
> wrote:
> 
>> probably a good idea.
>> 
>> A tomee7 release should still be cut. But that could be done on a
>>> tomee7.x
>> branch as well
>> 
>> Will create a separate thread.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com
>>> :
>>> 
>>> and probably switch the branch. master doesnt get much activity and
>> in
>> any
>>> case all the activity it gets can be done on the 8 branch
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github > rmannibucau> |
>>> LinkedIn  | Book
>>> > ee-8-high-performance>
>>> 
>>> 2018-02-15 18:05 GMT+01:00 Mark Struberg >> :
>>> 
 and now we should be passing both the tck/cdi-embedded and
>> tck/cdi-tomee!
 
 So it's time to move forward to updating various dependencies,
>>> samples
>> etc
 ;)
 
 LieGrue,
 strub
 
> Am 15.02.2018 um 11:42 schrieb Mark Struberg
>>>  :
> 
> Really appreciated, thanks Jon!
> 
> Due to the upgrade to Tomcat-9 we also might have to fix a few
>> other
 tests along the line.
> I mainly focused on the CDI TCK for now as this is naturally the
>>> area
 where I can be of most use.
> I'll also gonna release OWB tonight or so. Just wanted to first
>> fix
>>> the
 TomEE tck to really catch all odds in OWB.
> 
> LieGrue,
> strub
> 
> 
>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
 jonathan.gallim...@gmail.com>:
>> 
>> At the risk of adding to my ever-growing task list and
>> potentially
 becoming
>> a bottleneck, I did some EAR / RAR related fixes in master. I'll
>>> port
 those
>> forward and help look at these tests.
>> 
>> Jon
>> 
>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
 
>> wrote:
>> 
>>> We now pass all tests in tck/cdi-embedded
>>> And we have only 3 failing tests in tck/cdi-tomee.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Those tests are all EAR related.
>>> Maybe they are only Arquillian adapter issues?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
 Am 08.02.2018 um 13:30 schrieb Mark Struberg
 >> the
>>> Servlet spec.
 
 We could easily also send a specific CDI event for it. But
>> there
>>> is
>> no
>>> such event in the CDI spec so far.
 The @Destryoed and @BeforeDestroyed are specifically for
>> _destroyal_.
 

Re: TomEE8 TCK status

[Romain Manni-Bucau]

Dont think our ee api has upgraded to
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxrs_2.1_spec/
yet since we didnt have cxf 3.2.

Le 16 févr. 2018 00:49, "Jonathan Gallimore" 
a écrit :

> Ok, locally (with the merge), I get test errors due
> to: java.lang.NoClassDefFoundError:
> javax/ws/rs/client/CompletionStageRxInvoker. Possibly a bad javaee
> dependency or something. I'll do a compare tomorrow and try and get that
> resolved, and get my changes pushed.
>
> Jon
>
> On Thu, Feb 15, 2018 at 6:41 PM, Mark Struberg 
> wrote:
>
> > PS: xbean-asm6 is needed for java9 support.
> > Already using it in OWB and Meecrowave without any problems.
> > So all should work fine.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 15.02.2018 um 19:20 schrieb Mark Struberg  > >:
> > >
> > > oki great, I've just upgraded to tomcat-9.0.5 and right now upgrading
> to
> > xbean-asm6-shaded.
> > > Will ping you once done.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 15.02.2018 um 18:27 schrieb Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>:
> > >>
> > >> We definitely need a tomee-7 branch. I have done a merge of master to
> > the
> > >> tomee8_fb branch, and I'm making sure it builds and tests pass etc,
> > before
> > >> pushing.
> > >>
> > >> Jon
> > >>
> > >> On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg
> > 
> > >> wrote:
> > >>
> > >>> probably a good idea.
> > >>>
> > >>> A tomee7 release should still be cut. But that could be done on a
> > tomee7.x
> > >>> branch as well
> > >>>
> > >>> Will create a separate thread.
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>>
> >  Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> >  :
> > 
> >  and probably switch the branch. master doesnt get much activity and
> in
> > >>> any
> >  case all the activity it gets can be done on the 8 branch
> > 
> > 
> >  Romain Manni-Bucau
> >  @rmannibucau  |  Blog
> >   | Old Blog
> >   | Github  > >>> rmannibucau> |
> >  LinkedIn  | Book
> >   > >>> ee-8-high-performance>
> > 
> >  2018-02-15 18:05 GMT+01:00 Mark Struberg  >:
> > 
> > > and now we should be passing both the tck/cdi-embedded and
> > >>> tck/cdi-tomee!
> > >
> > > So it's time to move forward to updating various dependencies,
> > samples
> > >>> etc
> > > ;)
> > >
> > > LieGrue,
> > > strub
> > >
> > >> Am 15.02.2018 um 11:42 schrieb Mark Struberg
> >  > >> :
> > >>
> > >> Really appreciated, thanks Jon!
> > >>
> > >> Due to the upgrade to Tomcat-9 we also might have to fix a few
> other
> > > tests along the line.
> > >> I mainly focused on the CDI TCK for now as this is naturally the
> > area
> > > where I can be of most use.
> > >> I'll also gonna release OWB tonight or so. Just wanted to first
> fix
> > the
> > > TomEE tck to really catch all odds in OWB.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com>:
> > >>>
> > >>> At the risk of adding to my ever-growing task list and
> potentially
> > > becoming
> > >>> a bottleneck, I did some EAR / RAR related fixes in master. I'll
> > port
> > > those
> > >>> forward and help look at these tests.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
> > > 
> > >>> wrote:
> > >>>
> >  We now pass all tests in tck/cdi-embedded
> >  And we have only 3 failing tests in tck/cdi-tomee.
> > 
> >  
> >  
> >  
> > 
> >  Those tests are all EAR related.
> >  Maybe they are only Arquillian adapter issues?
> > 
> >  LieGrue,
> >  strub
> > 
> > 
> > 
> > > Am 08.02.2018 um 13:30 schrieb Mark Struberg
> > >  > > :
> > >
> > > Well, this is why there are passivation listeners and stuff in
> > the
> >  Servlet spec.
> > >
> > > We could easily also send a specific CDI event for it. But
> there
> > is
> > >>> no
> >  such event in the CDI spec so far.
> > > The @Destryoed and @BeforeDestroyed are specifically for
> > >>> _destroyal_.
> > >
> > > LieGrue,
> > > strub
> > >
> > >> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
> >  

Re: TomEE8 TCK status

[Jonathan Gallimore]

Ok, locally (with the merge), I get test errors due
to: java.lang.NoClassDefFoundError:
javax/ws/rs/client/CompletionStageRxInvoker. Possibly a bad javaee
dependency or something. I'll do a compare tomorrow and try and get that
resolved, and get my changes pushed.

Jon

On Thu, Feb 15, 2018 at 6:41 PM, Mark Struberg 
wrote:

> PS: xbean-asm6 is needed for java9 support.
> Already using it in OWB and Meecrowave without any problems.
> So all should work fine.
>
> LieGrue,
> strub
>
>
> > Am 15.02.2018 um 19:20 schrieb Mark Struberg  >:
> >
> > oki great, I've just upgraded to tomcat-9.0.5 and right now upgrading to
> xbean-asm6-shaded.
> > Will ping you once done.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 15.02.2018 um 18:27 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >>
> >> We definitely need a tomee-7 branch. I have done a merge of master to
> the
> >> tomee8_fb branch, and I'm making sure it builds and tests pass etc,
> before
> >> pushing.
> >>
> >> Jon
> >>
> >> On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg
> 
> >> wrote:
> >>
> >>> probably a good idea.
> >>>
> >>> A tomee7 release should still be cut. But that could be done on a
> tomee7.x
> >>> branch as well
> >>>
> >>> Will create a separate thread.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
>  Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
>  :
> 
>  and probably switch the branch. master doesnt get much activity and in
> >>> any
>  case all the activity it gets can be done on the 8 branch
> 
> 
>  Romain Manni-Bucau
>  @rmannibucau  |  Blog
>   | Old Blog
>   | Github  >>> rmannibucau> |
>  LinkedIn  | Book
>   >>> ee-8-high-performance>
> 
>  2018-02-15 18:05 GMT+01:00 Mark Struberg :
> 
> > and now we should be passing both the tck/cdi-embedded and
> >>> tck/cdi-tomee!
> >
> > So it's time to move forward to updating various dependencies,
> samples
> >>> etc
> > ;)
> >
> > LieGrue,
> > strub
> >
> >> Am 15.02.2018 um 11:42 schrieb Mark Struberg
>  >> :
> >>
> >> Really appreciated, thanks Jon!
> >>
> >> Due to the upgrade to Tomcat-9 we also might have to fix a few other
> > tests along the line.
> >> I mainly focused on the CDI TCK for now as this is naturally the
> area
> > where I can be of most use.
> >> I'll also gonna release OWB tonight or so. Just wanted to first fix
> the
> > TomEE tck to really catch all odds in OWB.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>:
> >>>
> >>> At the risk of adding to my ever-growing task list and potentially
> > becoming
> >>> a bottleneck, I did some EAR / RAR related fixes in master. I'll
> port
> > those
> >>> forward and help look at these tests.
> >>>
> >>> Jon
> >>>
> >>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
> > 
> >>> wrote:
> >>>
>  We now pass all tests in tck/cdi-embedded
>  And we have only 3 failing tests in tck/cdi-tomee.
> 
>  
>  
>  
> 
>  Those tests are all EAR related.
>  Maybe they are only Arquillian adapter issues?
> 
>  LieGrue,
>  strub
> 
> 
> 
> > Am 08.02.2018 um 13:30 schrieb Mark Struberg
> >  > :
> >
> > Well, this is why there are passivation listeners and stuff in
> the
>  Servlet spec.
> >
> > We could easily also send a specific CDI event for it. But there
> is
> >>> no
>  such event in the CDI spec so far.
> > The @Destryoed and @BeforeDestroyed are specifically for
> >>> _destroyal_.
> >
> > LieGrue,
> > strub
> >
> >> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
>  rmannibu...@gmail.com>:
> >>
> >> Hmm, it is more vicious cause if the session is not destroyed
> you
> >>> can
>  still
> >> want to trigger this event. Guess it is another case where both
> >>> cases
>  are
> >> desirable (i want to clean up related state of the session...as
> >>> well
> > as
>  I
> >> don't want to touch the session)...
> >>
> >> Since the appcontext destroy can be used as a workaround I
> think it
> > is
>  fine
> >> to challenge them now.
> >>
> 

Re: tomee git commit: Revert "Upgrade HSQLDB to 2.3.5"

[Jonathan Gallimore]

Reverting this temporarily. I created a local buildbot setup that should
fairly closely match the ASF one, and was able to reproduce the build
issue. Reverting this to see if it actually fixes the issue on the CI. If
it doesn't I'll revert the revert, if it does, we'll need to figure out how
to fix things so we can update this dependency and keep the tests working.

Jon

On Thu, Feb 15, 2018 at 9:39 PM,  wrote:

> Repository: tomee
> Updated Branches:
>   refs/heads/master eb8199f1d -> 613c847e4
>
>
> Revert "Upgrade HSQLDB to 2.3.5"
>
> This reverts commit 7b1ad5f0aedcc2cad68b67604f0ec33acd3b511d.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/613c847e
> Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/613c847e
> Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/613c847e
>
> Branch: refs/heads/master
> Commit: 613c847e436d8658db45e4013a0c699560a81579
> Parents: eb8199f
> Author: Jonathan Gallimore 
> Authored: Thu Feb 15 18:25:54 2018 +
> Committer: Jonathan Gallimore 
> Committed: Thu Feb 15 18:25:54 2018 +
>
> --
>  pom.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/613c847e/pom.xml
> --
> diff --git a/pom.xml b/pom.xml
> index 6fc6360..58581b8 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -183,7 +183,7 @@
>  1.2.17
>  2.0.1
>  4.2.0
> -2.3.5
> +2.3.2
>  1.2.20
>  2.7.2
>  4.2.18.Final
>
>

Re: TomEE8 TCK status

[Mark Struberg]

PS: xbean-asm6 is needed for java9 support. 
Already using it in OWB and Meecrowave without any problems.
So all should work fine.

LieGrue,
strub


> Am 15.02.2018 um 19:20 schrieb Mark Struberg :
> 
> oki great, I've just upgraded to tomcat-9.0.5 and right now upgrading to 
> xbean-asm6-shaded.
> Will ping you once done.
> 
> LieGrue,
> strub
> 
> 
>> Am 15.02.2018 um 18:27 schrieb Jonathan Gallimore 
>> :
>> 
>> We definitely need a tomee-7 branch. I have done a merge of master to the
>> tomee8_fb branch, and I'm making sure it builds and tests pass etc, before
>> pushing.
>> 
>> Jon
>> 
>> On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg 
>> wrote:
>> 
>>> probably a good idea.
>>> 
>>> A tomee7 release should still be cut. But that could be done on a tomee7.x
>>> branch as well
>>> 
>>> Will create a separate thread.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
 Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau >> any
 case all the activity it gets can be done on the 8 branch
 
 
 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github >> rmannibucau> |
 LinkedIn  | Book
 >> ee-8-high-performance>
 
 2018-02-15 18:05 GMT+01:00 Mark Struberg :
 
> and now we should be passing both the tck/cdi-embedded and
>>> tck/cdi-tomee!
> 
> So it's time to move forward to updating various dependencies, samples
>>> etc
> ;)
> 
> LieGrue,
> strub
> 
>> Am 15.02.2018 um 11:42 schrieb Mark Struberg > :
>> 
>> Really appreciated, thanks Jon!
>> 
>> Due to the upgrade to Tomcat-9 we also might have to fix a few other
> tests along the line.
>> I mainly focused on the CDI TCK for now as this is naturally the area
> where I can be of most use.
>> I'll also gonna release OWB tonight or so. Just wanted to first fix the
> TomEE tck to really catch all odds in OWB.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
>>> 
>>> At the risk of adding to my ever-growing task list and potentially
> becoming
>>> a bottleneck, I did some EAR / RAR related fixes in master. I'll port
> those
>>> forward and help look at these tests.
>>> 
>>> Jon
>>> 
>>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
> 
>>> wrote:
>>> 
 We now pass all tests in tck/cdi-embedded
 And we have only 3 failing tests in tck/cdi-tomee.
 
 
 
 
 
 Those tests are all EAR related.
 Maybe they are only Arquillian adapter issues?
 
 LieGrue,
 strub
 
 
 
> Am 08.02.2018 um 13:30 schrieb Mark Struberg
>  :
> 
> Well, this is why there are passivation listeners and stuff in the
 Servlet spec.
> 
> We could easily also send a specific CDI event for it. But there is
>>> no
 such event in the CDI spec so far.
> The @Destryoed and @BeforeDestroyed are specifically for
>>> _destroyal_.
> 
> LieGrue,
> strub
> 
>> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
 rmannibu...@gmail.com>:
>> 
>> Hmm, it is more vicious cause if the session is not destroyed you
>>> can
 still
>> want to trigger this event. Guess it is another case where both
>>> cases
 are
>> desirable (i want to clean up related state of the session...as
>>> well
> as
 I
>> don't want to touch the session)...
>> 
>> Since the appcontext destroy can be used as a workaround I think it
> is
 fine
>> to challenge them now.
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github  |
>> LinkedIn  | Book
>> 
>> 
>> 2018-02-08 11:37 GMT+01:00 Mark Struberg > :
>> 
>>> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
 

Re: TomEE8 TCK status

[Mark Struberg]

oki great, I've just upgraded to tomcat-9.0.5 and right now upgrading to 
xbean-asm6-shaded.
Will ping you once done.

LieGrue,
strub


> Am 15.02.2018 um 18:27 schrieb Jonathan Gallimore 
> :
> 
> We definitely need a tomee-7 branch. I have done a merge of master to the
> tomee8_fb branch, and I'm making sure it builds and tests pass etc, before
> pushing.
> 
> Jon
> 
> On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg 
> wrote:
> 
>> probably a good idea.
>> 
>> A tomee7 release should still be cut. But that could be done on a tomee7.x
>> branch as well
>> 
>> Will create a separate thread.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau >> :
>>> 
>>> and probably switch the branch. master doesnt get much activity and in
>> any
>>> case all the activity it gets can be done on the 8 branch
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github > rmannibucau> |
>>> LinkedIn  | Book
>>> > ee-8-high-performance>
>>> 
>>> 2018-02-15 18:05 GMT+01:00 Mark Struberg :
>>> 
 and now we should be passing both the tck/cdi-embedded and
>> tck/cdi-tomee!
 
 So it's time to move forward to updating various dependencies, samples
>> etc
 ;)
 
 LieGrue,
 strub
 
> Am 15.02.2018 um 11:42 schrieb Mark Struberg  :
> 
> Really appreciated, thanks Jon!
> 
> Due to the upgrade to Tomcat-9 we also might have to fix a few other
 tests along the line.
> I mainly focused on the CDI TCK for now as this is naturally the area
 where I can be of most use.
> I'll also gonna release OWB tonight or so. Just wanted to first fix the
 TomEE tck to really catch all odds in OWB.
> 
> LieGrue,
> strub
> 
> 
>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
 jonathan.gallim...@gmail.com>:
>> 
>> At the risk of adding to my ever-growing task list and potentially
 becoming
>> a bottleneck, I did some EAR / RAR related fixes in master. I'll port
 those
>> forward and help look at these tests.
>> 
>> Jon
>> 
>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
 
>> wrote:
>> 
>>> We now pass all tests in tck/cdi-embedded
>>> And we have only 3 failing tests in tck/cdi-tomee.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Those tests are all EAR related.
>>> Maybe they are only Arquillian adapter issues?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
 Am 08.02.2018 um 13:30 schrieb Mark Struberg
 >> Servlet spec.
 
 We could easily also send a specific CDI event for it. But there is
>> no
>>> such event in the CDI spec so far.
 The @Destryoed and @BeforeDestroyed are specifically for
>> _destroyal_.
 
 LieGrue,
 strub
 
> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
> 
> Hmm, it is more vicious cause if the session is not destroyed you
>> can
>>> still
> want to trigger this event. Guess it is another case where both
>> cases
>>> are
> desirable (i want to clean up related state of the session...as
>> well
 as
>>> I
> don't want to touch the session)...
> 
> Since the appcontext destroy can be used as a workaround I think it
 is
>>> fine
> to challenge them now.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github >> rmannibucau> |
> LinkedIn  | Book
> >> ee-8-high-performance>
> 
> 2018-02-08 11:37 GMT+01:00 Mark Struberg  :
> 
>> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
>>> SessionScoped.class)
>> and @Destroyed(SessionScoped.class) do work.
>> The tests itself are fine, but instead of relying that the
>> sessions
 get
>> destroyed at server shutdown they could also have used
>> Session.invalidate()...
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <

Re: Let's do better

[Matthew Broadhead]

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


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


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


Andy.


On 13/02/18 10:25, Mark Struberg wrote:
It's our duty as PMC members to review committs. And of course a 
commit with the comment 'starting a thing which was decided not to be 
done' should spark EVERYONES curiosity.


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


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


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


LieGrue,
strub


Am 13.02.2018 um 09:52 schrieb Jean-Louis Monteiro 
:


Morning Mark,

I appreciate the feedback, but I disagree.

Adding an @Ignore on a test failing does not fix the issue (either 
the test

or the code)
Putting a napkin over some c... does not clean it up.

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

same position.

I do not plan to put fuel on the fire.

I'm suggesting that instead of shooting at the daughter and therefor 
not

getting any chance to know it was a present, one should first ask
questions.
"My sweet heart, why do you have the keys of the car?"
"What do you plan to do with them?"

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

her father.

You are a father, so am I.

Hope it helps.



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

On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg 


wrote:


Please all stop putting fuel into the fire.

LieGrue,
strub



Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <

jlmonte...@tomitribe.com>:
Instead of shooting to someone or start arguing. Simply asking 
would take

all misunderstand off and avoid this disgusting mess.

Le 13 févr. 2018 08:33, "Mark Struberg"  a
écrit :


+1  words - and especially brief once as emails - are just a mapping

from

the reality to some 'transport mechanism' (Claude Shannon sender

theoreme

anyone?).
And of course each 'map' is a huge simplification from the 
reality and

thus prone to be misinterpreted.

The important part here is that those clashes bring up some 
difference

in

view.
And yes, I also think this has nothing to do with immature or 
childish.

We

are all just passionate.
So the first very important step is to identify the pain point.

For Romain and me, etc is to avoid duplication of work which 
already got

done in other ASF projects.
And to not have those modules hardcoded bound to the TomEE 
Application

Server but to be reusable for other projects.
Please note that I'm talking about the Appliation Server only and 
not

about the TomEE project as governance body.

I also had an important lesson in the 90s:

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

Re: TomEE8 TCK status

[Jonathan Gallimore]

We definitely need a tomee-7 branch. I have done a merge of master to the
tomee8_fb branch, and I'm making sure it builds and tests pass etc, before
pushing.

Jon

On Thu, Feb 15, 2018 at 5:19 PM, Mark Struberg 
wrote:

> probably a good idea.
>
> A tomee7 release should still be cut. But that could be done on a tomee7.x
> branch as well
>
> Will create a separate thread.
>
> LieGrue,
> strub
>
>
>
> > Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau  >:
> >
> > and probably switch the branch. master doesnt get much activity and in
> any
> > case all the activity it gets can be done on the 8 branch
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | Book
> >  ee-8-high-performance>
> >
> > 2018-02-15 18:05 GMT+01:00 Mark Struberg :
> >
> >> and now we should be passing both the tck/cdi-embedded and
> tck/cdi-tomee!
> >>
> >> So it's time to move forward to updating various dependencies, samples
> etc
> >> ;)
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 15.02.2018 um 11:42 schrieb Mark Struberg  >>> :
> >>>
> >>> Really appreciated, thanks Jon!
> >>>
> >>> Due to the upgrade to Tomcat-9 we also might have to fix a few other
> >> tests along the line.
> >>> I mainly focused on the CDI TCK for now as this is naturally the area
> >> where I can be of most use.
> >>> I'll also gonna release OWB tonight or so. Just wanted to first fix the
> >> TomEE tck to really catch all odds in OWB.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
>  Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com>:
> 
>  At the risk of adding to my ever-growing task list and potentially
> >> becoming
>  a bottleneck, I did some EAR / RAR related fixes in master. I'll port
> >> those
>  forward and help look at these tests.
> 
>  Jon
> 
>  On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
> >> 
>  wrote:
> 
> > We now pass all tests in tck/cdi-embedded
> > And we have only 3 failing tests in tck/cdi-tomee.
> >
> > 
> > 
> > 
> >
> > Those tests are all EAR related.
> > Maybe they are only Arquillian adapter issues?
> >
> > LieGrue,
> > strub
> >
> >
> >
> >> Am 08.02.2018 um 13:30 schrieb Mark Struberg
> >>  >> :
> >>
> >> Well, this is why there are passivation listeners and stuff in the
> > Servlet spec.
> >>
> >> We could easily also send a specific CDI event for it. But there is
> no
> > such event in the CDI spec so far.
> >> The @Destryoed and @BeforeDestroyed are specifically for
> _destroyal_.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com>:
> >>>
> >>> Hmm, it is more vicious cause if the session is not destroyed you
> can
> > still
> >>> want to trigger this event. Guess it is another case where both
> cases
> > are
> >>> desirable (i want to clean up related state of the session...as
> well
> >> as
> > I
> >>> don't want to touch the session)...
> >>>
> >>> Since the appcontext destroy can be used as a workaround I think it
> >> is
> > fine
> >>> to challenge them now.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github  > rmannibucau> |
> >>> LinkedIn  | Book
> >>>  > ee-8-high-performance>
> >>>
> >>> 2018-02-08 11:37 GMT+01:00 Mark Struberg  >>> :
> >>>
>  Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
> > SessionScoped.class)
>  and @Destroyed(SessionScoped.class) do work.
>  The tests itself are fine, but instead of relying that the
> sessions
> >> get
>  destroyed at server shutdown they could also have used
>  Session.invalidate()...
> 
>  LieGrue,
>  strub
> 
> 
> > Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > :
> >
> > 2018-02-08 11:28 GMT+01:00 Mark Struberg
>  >>> :
> >
> >> All the embedded tests are now green.
> >>
> >> I'm now working on cdi-tomes (webprofile TCK).
> >> So far we have 

Re: TomEE8 TCK status

[Mark Struberg]

probably a good idea. 

A tomee7 release should still be cut. But that could be done on a tomee7.x 
branch as well

Will create a separate thread.

LieGrue,
strub



> Am 15.02.2018 um 18:11 schrieb Romain Manni-Bucau :
> 
> and probably switch the branch. master doesnt get much activity and in any
> case all the activity it gets can be done on the 8 branch
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 2018-02-15 18:05 GMT+01:00 Mark Struberg :
> 
>> and now we should be passing both the tck/cdi-embedded and tck/cdi-tomee!
>> 
>> So it's time to move forward to updating various dependencies, samples etc
>> ;)
>> 
>> LieGrue,
>> strub
>> 
>>> Am 15.02.2018 um 11:42 schrieb Mark Struberg >> :
>>> 
>>> Really appreciated, thanks Jon!
>>> 
>>> Due to the upgrade to Tomcat-9 we also might have to fix a few other
>> tests along the line.
>>> I mainly focused on the CDI TCK for now as this is naturally the area
>> where I can be of most use.
>>> I'll also gonna release OWB tonight or so. Just wanted to first fix the
>> TomEE tck to really catch all odds in OWB.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
 Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
>> jonathan.gallim...@gmail.com>:
 
 At the risk of adding to my ever-growing task list and potentially
>> becoming
 a bottleneck, I did some EAR / RAR related fixes in master. I'll port
>> those
 forward and help look at these tests.
 
 Jon
 
 On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
>> 
 wrote:
 
> We now pass all tests in tck/cdi-embedded
> And we have only 3 failing tests in tck/cdi-tomee.
> 
> 
> 
> 
> 
> Those tests are all EAR related.
> Maybe they are only Arquillian adapter issues?
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 08.02.2018 um 13:30 schrieb Mark Struberg
>> > :
>> 
>> Well, this is why there are passivation listeners and stuff in the
> Servlet spec.
>> 
>> We could easily also send a specific CDI event for it. But there is no
> such event in the CDI spec so far.
>> The @Destryoed and @BeforeDestroyed are specifically for _destroyal_.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>>> 
>>> Hmm, it is more vicious cause if the session is not destroyed you can
> still
>>> want to trigger this event. Guess it is another case where both cases
> are
>>> desirable (i want to clean up related state of the session...as well
>> as
> I
>>> don't want to touch the session)...
>>> 
>>> Since the appcontext destroy can be used as a workaround I think it
>> is
> fine
>>> to challenge them now.
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github  rmannibucau> |
>>> LinkedIn  | Book
>>>  ee-8-high-performance>
>>> 
>>> 2018-02-08 11:37 GMT+01:00 Mark Struberg >> :
>>> 
 Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
> SessionScoped.class)
 and @Destroyed(SessionScoped.class) do work.
 The tests itself are fine, but instead of relying that the sessions
>> get
 destroyed at server shutdown they could also have used
 Session.invalidate()...
 
 LieGrue,
 strub
 
 
> Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> :
> 
> 2018-02-08 11:28 GMT+01:00 Mark Struberg >> :
> 
>> All the embedded tests are now green.
>> 
>> I'm now working on cdi-tomes (webprofile TCK).
>> So far we have 10 errors, but a few TCK tests are broken because
>> they
>> wrongly assume that a container stop also kills the Session.
>> 
> 
> We can make them passing. We already did this kind of hack but
>> since
> all
> container have pluggability here - for good reasons - I agree they
> shouldn't be in the TCK.
> 
> 
>> I've challenged those tests. Still have to review every red
>> test...
>> 
>> LieGrue,
>> strub
>> 

Re: TomEE8 TCK status

[Romain Manni-Bucau]

and probably switch the branch. master doesnt get much activity and in any
case all the activity it gets can be done on the 8 branch


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


2018-02-15 18:05 GMT+01:00 Mark Struberg :

> and now we should be passing both the tck/cdi-embedded and tck/cdi-tomee!
>
> So it's time to move forward to updating various dependencies, samples etc
> ;)
>
> LieGrue,
> strub
>
> > Am 15.02.2018 um 11:42 schrieb Mark Struberg  >:
> >
> > Really appreciated, thanks Jon!
> >
> > Due to the upgrade to Tomcat-9 we also might have to fix a few other
> tests along the line.
> > I mainly focused on the CDI TCK for now as this is naturally the area
> where I can be of most use.
> > I'll also gonna release OWB tonight or so. Just wanted to first fix the
> TomEE tck to really catch all odds in OWB.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >>
> >> At the risk of adding to my ever-growing task list and potentially
> becoming
> >> a bottleneck, I did some EAR / RAR related fixes in master. I'll port
> those
> >> forward and help look at these tests.
> >>
> >> Jon
> >>
> >> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg
> 
> >> wrote:
> >>
> >>> We now pass all tests in tck/cdi-embedded
> >>> And we have only 3 failing tests in tck/cdi-tomee.
> >>>
> >>> 
> >>> 
> >>> 
> >>>
> >>> Those tests are all EAR related.
> >>> Maybe they are only Arquillian adapter issues?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
>  Am 08.02.2018 um 13:30 schrieb Mark Struberg
>   :
> 
>  Well, this is why there are passivation listeners and stuff in the
> >>> Servlet spec.
> 
>  We could easily also send a specific CDI event for it. But there is no
> >>> such event in the CDI spec so far.
>  The @Destryoed and @BeforeDestroyed are specifically for _destroyal_.
> 
>  LieGrue,
>  strub
> 
> > Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>:
> >
> > Hmm, it is more vicious cause if the session is not destroyed you can
> >>> still
> > want to trigger this event. Guess it is another case where both cases
> >>> are
> > desirable (i want to clean up related state of the session...as well
> as
> >>> I
> > don't want to touch the session)...
> >
> > Since the appcontext destroy can be used as a workaround I think it
> is
> >>> fine
> > to challenge them now.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  >>> rmannibucau> |
> > LinkedIn  | Book
> >  >>> ee-8-high-performance>
> >
> > 2018-02-08 11:37 GMT+01:00 Mark Struberg  >:
> >
> >> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
> >>> SessionScoped.class)
> >> and @Destroyed(SessionScoped.class) do work.
> >> The tests itself are fine, but instead of relying that the sessions
> get
> >> destroyed at server shutdown they could also have used
> >> Session.invalidate()...
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
> >>> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 2018-02-08 11:28 GMT+01:00 Mark Struberg  >:
> >>>
>  All the embedded tests are now green.
> 
>  I'm now working on cdi-tomes (webprofile TCK).
>  So far we have 10 errors, but a few TCK tests are broken because
> they
>  wrongly assume that a container stop also kills the Session.
> 
> >>>
> >>> We can make them passing. We already did this kind of hack but
> since
> >>> all
> >>> container have pluggability here - for good reasons - I agree they
> >>> shouldn't be in the TCK.
> >>>
> >>>
>  I've challenged those tests. Still have to review every red
> test...
> 
>  LieGrue,
>  strub
> 
> 
> > Am 08.02.2018 um 11:19 schrieb Matthew Broadhead <
>  matthew.broadh...@nbmlaw.co.uk>:
> >
> > nearly there!
> >
> > On 07/02/2018 11:57, Mark Struberg wrote:
> >> [ERROR] Failures:
> >> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >> 

Re: TomEE8 TCK status

[Mark Struberg]

and now we should be passing both the tck/cdi-embedded and tck/cdi-tomee!

So it's time to move forward to updating various dependencies, samples etc ;)

LieGrue,
strub

> Am 15.02.2018 um 11:42 schrieb Mark Struberg :
> 
> Really appreciated, thanks Jon!
> 
> Due to the upgrade to Tomcat-9 we also might have to fix a few other tests 
> along the line. 
> I mainly focused on the CDI TCK for now as this is naturally the area where I 
> can be of most use.
> I'll also gonna release OWB tonight or so. Just wanted to first fix the TomEE 
> tck to really catch all odds in OWB.
> 
> LieGrue,
> strub
> 
> 
>> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore 
>> :
>> 
>> At the risk of adding to my ever-growing task list and potentially becoming
>> a bottleneck, I did some EAR / RAR related fixes in master. I'll port those
>> forward and help look at these tests.
>> 
>> Jon
>> 
>> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg 
>> wrote:
>> 
>>> We now pass all tests in tck/cdi-embedded
>>> And we have only 3 failing tests in tck/cdi-tomee.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Those tests are all EAR related.
>>> Maybe they are only Arquillian adapter issues?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
 Am 08.02.2018 um 13:30 schrieb Mark Struberg >> Servlet spec.
 
 We could easily also send a specific CDI event for it. But there is no
>>> such event in the CDI spec so far.
 The @Destryoed and @BeforeDestroyed are specifically for _destroyal_.
 
 LieGrue,
 strub
 
> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
> 
> Hmm, it is more vicious cause if the session is not destroyed you can
>>> still
> want to trigger this event. Guess it is another case where both cases
>>> are
> desirable (i want to clean up related state of the session...as well as
>>> I
> don't want to touch the session)...
> 
> Since the appcontext destroy can be used as a workaround I think it is
>>> fine
> to challenge them now.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github >> rmannibucau> |
> LinkedIn  | Book
> >> ee-8-high-performance>
> 
> 2018-02-08 11:37 GMT+01:00 Mark Struberg :
> 
>> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
>>> SessionScoped.class)
>> and @Destroyed(SessionScoped.class) do work.
>> The tests itself are fine, but instead of relying that the sessions get
>> destroyed at server shutdown they could also have used
>> Session.invalidate()...
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com
>>> :
>>> 
>>> 2018-02-08 11:28 GMT+01:00 Mark Struberg :
>>> 
 All the embedded tests are now green.
 
 I'm now working on cdi-tomes (webprofile TCK).
 So far we have 10 errors, but a few TCK tests are broken because they
 wrongly assume that a container stop also kills the Session.
 
>>> 
>>> We can make them passing. We already did this kind of hack but since
>>> all
>>> container have pluggability here - for good reasons - I agree they
>>> shouldn't be in the TCK.
>>> 
>>> 
 I've challenged those tests. Still have to review every red test...
 
 LieGrue,
 strub
 
 
> Am 08.02.2018 um 11:19 schrieb Matthew Broadhead <
 matthew.broadh...@nbmlaw.co.uk>:
> 
> nearly there!
> 
> On 07/02/2018 11:57, Mark Struberg wrote:
>> [ERROR] Failures:
>> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
>> arquillianBeforeClass:109
 » Deployment
>> [INFO]
>> [ERROR] Tests run: 1567, Failures: 1, Errors: 0, Skipped: 5
>> 
>> 
>> Wohuuu, 1 to go!
>> 
>> LieGrue,
>> strub
>> 
>>> Am 02.02.2018 um 21:54 schrieb Mark Struberg
>>  :
>>> 
>>> And the last status:
>>> 
>>> [ERROR] Failures:
>>> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
>> arquillianBeforeClass:109
 » Deployment
>>> [ERROR]   ContainerLifeCycleEventRuntime
>>> InvocationTest>Arquillian.
>> arquillianBeforeClass:109
 » Deployment
>>> [ERROR]   BuiltinMetadataEEBeanTest>Arquillian.run:164->
 

Re: Revert ActiveMQ version change (was Re: tomee git commit: upgrating amq from 5.14.5 to 5.15.2)

[Thiago Veronezi]

Np. Tx bud.
[],
Thiago


On Feb 15, 2018 10:27, "Jonathan Gallimore" 
wrote:

> Hey Thiago
>
> Looks like the new version is Java 8, so I'm going to revert it. We should
> definitely go for 5.15.x in the EE8 branch though.
>
> Please let me know if that is an issue.
>
> Jon
>
> On Wed, Feb 14, 2018 at 11:17 AM,  wrote:
>
> > Repository: tomee
> > Updated Branches:
> >   refs/heads/master 0a0ddab90 -> a049ad484
> >
> >
> > upgrating amq from 5.14.5 to 5.15.2
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/a049ad48
> > Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/a049ad48
> > Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/a049ad48
> >
> > Branch: refs/heads/master
> > Commit: a049ad484eb061884d0c4a0c85bbe4b250a390ff
> > Parents: 0a0ddab
> > Author: Thiago Veronezi 
> > Authored: Wed Feb 14 09:14:49 2018 -0200
> > Committer: Thiago Veronezi 
> > Committed: Wed Feb 14 09:14:49 2018 -0200
> >
> > --
> >  pom.xml | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/tomee/blob/a049ad48/pom.xml
> > --
> > diff --git a/pom.xml b/pom.xml
> > index 6fc6360..0670dd2 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -169,7 +169,7 @@
> >  3.3
> >
> >  1.1.2
> > -5.14.5
> > +5.15.2
> >  3.1.4.RELEASE > springframework.version>
> >  4.12
> >  1.4.1
> >
> >
>

Re: Revert ActiveMQ version change (was Re: tomee git commit: upgrating amq from 5.14.5 to 5.15.2)

[Romain Manni-Bucau]

sounds good to me


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


2018-02-15 14:24 GMT+01:00 Mark Struberg :

> We could do that but that but we should at least raise the minor version.
> That would be TomEE-7.1.0 in that case.
>
> LieGrue,
> strub
>
> > Am 15.02.2018 um 14:17 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >
> > I'm happy to vote on it. Providing that requiring Java 8 for EE7 is ok,
> I'd
> > be in favour of it. A vote is the right step in my view, so its a
> conscious
> > decision rather than happening accidentally with dependencies slipping
> in.
> >
> > Jon
> >
> > On Thu, Feb 15, 2018 at 1:13 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Do we want to vote to move tomee7 to java 8? There is no more blocker
> today
> >> I think.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github  >> rmannibucau> |
> >> LinkedIn  | Book
> >>  >> ee-8-high-performance>
> >>
> >> 2018-02-15 13:27 GMT+01:00 Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com>
> >> :
> >>
> >>> Hey Thiago
> >>>
> >>> Looks like the new version is Java 8, so I'm going to revert it. We
> >> should
> >>> definitely go for 5.15.x in the EE8 branch though.
> >>>
> >>> Please let me know if that is an issue.
> >>>
> >>> Jon
> >>>
> >>> On Wed, Feb 14, 2018 at 11:17 AM,  wrote:
> >>>
>  Repository: tomee
>  Updated Branches:
>   refs/heads/master 0a0ddab90 -> a049ad484
> 
> 
>  upgrating amq from 5.14.5 to 5.15.2
> 
> 
>  Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
>  Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/a049ad48
>  Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/a049ad48
>  Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/a049ad48
> 
>  Branch: refs/heads/master
>  Commit: a049ad484eb061884d0c4a0c85bbe4b250a390ff
>  Parents: 0a0ddab
>  Author: Thiago Veronezi 
>  Authored: Wed Feb 14 09:14:49 2018 -0200
>  Committer: Thiago Veronezi 
>  Committed: Wed Feb 14 09:14:49 2018 -0200
> 
>  
> --
>  pom.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  
> --
> 
> 
>  http://git-wip-us.apache.org/repos/asf/tomee/blob/a049ad48/pom.xml
>  
> --
>  diff --git a/pom.xml b/pom.xml
>  index 6fc6360..0670dd2 100644
>  --- a/pom.xml
>  +++ b/pom.xml
>  @@ -169,7 +169,7 @@
>  3.3
> 
>  1.1.2
>  -5.14.5 version>
>  +5.15.2 version>
>  3.1.4.RELEASE  springframework.version>
>  4.12
>  1.4.1
> 
> 
> >>>
> >>
>
>

Re: Revert ActiveMQ version change (was Re: tomee git commit: upgrating amq from 5.14.5 to 5.15.2)

[Mark Struberg]

We could do that but that but we should at least raise the minor version. 
That would be TomEE-7.1.0 in that case.

LieGrue,
strub

> Am 15.02.2018 um 14:17 schrieb Jonathan Gallimore 
> :
> 
> I'm happy to vote on it. Providing that requiring Java 8 for EE7 is ok, I'd
> be in favour of it. A vote is the right step in my view, so its a conscious
> decision rather than happening accidentally with dependencies slipping in.
> 
> Jon
> 
> On Thu, Feb 15, 2018 at 1:13 PM, Romain Manni-Bucau 
> wrote:
> 
>> Do we want to vote to move tomee7 to java 8? There is no more blocker today
>> I think.
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github > rmannibucau> |
>> LinkedIn  | Book
>> > ee-8-high-performance>
>> 
>> 2018-02-15 13:27 GMT+01:00 Jonathan Gallimore <
>> jonathan.gallim...@gmail.com>
>> :
>> 
>>> Hey Thiago
>>> 
>>> Looks like the new version is Java 8, so I'm going to revert it. We
>> should
>>> definitely go for 5.15.x in the EE8 branch though.
>>> 
>>> Please let me know if that is an issue.
>>> 
>>> Jon
>>> 
>>> On Wed, Feb 14, 2018 at 11:17 AM,  wrote:
>>> 
 Repository: tomee
 Updated Branches:
  refs/heads/master 0a0ddab90 -> a049ad484
 
 
 upgrating amq from 5.14.5 to 5.15.2
 
 
 Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
 Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/a049ad48
 Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/a049ad48
 Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/a049ad48
 
 Branch: refs/heads/master
 Commit: a049ad484eb061884d0c4a0c85bbe4b250a390ff
 Parents: 0a0ddab
 Author: Thiago Veronezi 
 Authored: Wed Feb 14 09:14:49 2018 -0200
 Committer: Thiago Veronezi 
 Committed: Wed Feb 14 09:14:49 2018 -0200
 
 --
 pom.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 --
 
 
 http://git-wip-us.apache.org/repos/asf/tomee/blob/a049ad48/pom.xml
 --
 diff --git a/pom.xml b/pom.xml
 index 6fc6360..0670dd2 100644
 --- a/pom.xml
 +++ b/pom.xml
 @@ -169,7 +169,7 @@
 3.3
 
 1.1.2
 -5.14.5
 +5.15.2
 3.1.4.RELEASE>>> springframework.version>
 4.12
 1.4.1
 
 
>>> 
>> 

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: Revert ActiveMQ version change (was Re: tomee git commit: upgrating amq from 5.14.5 to 5.15.2)

[Jonathan Gallimore]

I'm happy to vote on it. Providing that requiring Java 8 for EE7 is ok, I'd
be in favour of it. A vote is the right step in my view, so its a conscious
decision rather than happening accidentally with dependencies slipping in.

Jon

On Thu, Feb 15, 2018 at 1:13 PM, Romain Manni-Bucau 
wrote:

> Do we want to vote to move tomee7 to java 8? There is no more blocker today
> I think.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
> 2018-02-15 13:27 GMT+01:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> :
>
> > Hey Thiago
> >
> > Looks like the new version is Java 8, so I'm going to revert it. We
> should
> > definitely go for 5.15.x in the EE8 branch though.
> >
> > Please let me know if that is an issue.
> >
> > Jon
> >
> > On Wed, Feb 14, 2018 at 11:17 AM,  wrote:
> >
> > > Repository: tomee
> > > Updated Branches:
> > >   refs/heads/master 0a0ddab90 -> a049ad484
> > >
> > >
> > > upgrating amq from 5.14.5 to 5.15.2
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/a049ad48
> > > Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/a049ad48
> > > Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/a049ad48
> > >
> > > Branch: refs/heads/master
> > > Commit: a049ad484eb061884d0c4a0c85bbe4b250a390ff
> > > Parents: 0a0ddab
> > > Author: Thiago Veronezi 
> > > Authored: Wed Feb 14 09:14:49 2018 -0200
> > > Committer: Thiago Veronezi 
> > > Committed: Wed Feb 14 09:14:49 2018 -0200
> > >
> > > --
> > >  pom.xml | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > --
> > >
> > >
> > > http://git-wip-us.apache.org/repos/asf/tomee/blob/a049ad48/pom.xml
> > > --
> > > diff --git a/pom.xml b/pom.xml
> > > index 6fc6360..0670dd2 100644
> > > --- a/pom.xml
> > > +++ b/pom.xml
> > > @@ -169,7 +169,7 @@
> > >  3.3
> > >
> > >  1.1.2
> > > -5.14.5
> > > +5.15.2
> > >  3.1.4.RELEASE > > springframework.version>
> > >  4.12
> > >  1.4.1
> > >
> > >
> >
>

Re: Revert ActiveMQ version change (was Re: tomee git commit: upgrating amq from 5.14.5 to 5.15.2)

[Romain Manni-Bucau]

Do we want to vote to move tomee7 to java 8? There is no more blocker today
I think.


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


2018-02-15 13:27 GMT+01:00 Jonathan Gallimore 
:

> Hey Thiago
>
> Looks like the new version is Java 8, so I'm going to revert it. We should
> definitely go for 5.15.x in the EE8 branch though.
>
> Please let me know if that is an issue.
>
> Jon
>
> On Wed, Feb 14, 2018 at 11:17 AM,  wrote:
>
> > Repository: tomee
> > Updated Branches:
> >   refs/heads/master 0a0ddab90 -> a049ad484
> >
> >
> > upgrating amq from 5.14.5 to 5.15.2
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/a049ad48
> > Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/a049ad48
> > Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/a049ad48
> >
> > Branch: refs/heads/master
> > Commit: a049ad484eb061884d0c4a0c85bbe4b250a390ff
> > Parents: 0a0ddab
> > Author: Thiago Veronezi 
> > Authored: Wed Feb 14 09:14:49 2018 -0200
> > Committer: Thiago Veronezi 
> > Committed: Wed Feb 14 09:14:49 2018 -0200
> >
> > --
> >  pom.xml | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/tomee/blob/a049ad48/pom.xml
> > --
> > diff --git a/pom.xml b/pom.xml
> > index 6fc6360..0670dd2 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -169,7 +169,7 @@
> >  3.3
> >
> >  1.1.2
> > -5.14.5
> > +5.15.2
> >  3.1.4.RELEASE > springframework.version>
> >  4.12
> >  1.4.1
> >
> >
>

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
> 

Revert ActiveMQ version change (was Re: tomee git commit: upgrating amq from 5.14.5 to 5.15.2)

[Jonathan Gallimore]

Hey Thiago

Looks like the new version is Java 8, so I'm going to revert it. We should
definitely go for 5.15.x in the EE8 branch though.

Please let me know if that is an issue.

Jon

On Wed, Feb 14, 2018 at 11:17 AM,  wrote:

> Repository: tomee
> Updated Branches:
>   refs/heads/master 0a0ddab90 -> a049ad484
>
>
> upgrating amq from 5.14.5 to 5.15.2
>
>
> Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/a049ad48
> Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/a049ad48
> Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/a049ad48
>
> Branch: refs/heads/master
> Commit: a049ad484eb061884d0c4a0c85bbe4b250a390ff
> Parents: 0a0ddab
> Author: Thiago Veronezi 
> Authored: Wed Feb 14 09:14:49 2018 -0200
> Committer: Thiago Veronezi 
> Committed: Wed Feb 14 09:14:49 2018 -0200
>
> --
>  pom.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/a049ad48/pom.xml
> --
> diff --git a/pom.xml b/pom.xml
> index 6fc6360..0670dd2 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -169,7 +169,7 @@
>  3.3
>
>  1.1.2
> -5.14.5
> +5.15.2
>  3.1.4.RELEASE springframework.version>
>  4.12
>  1.4.1
>
>

Re: TomEE8 TCK status

[Mark Struberg]

Really appreciated, thanks Jon!

Due to the upgrade to Tomcat-9 we also might have to fix a few other tests 
along the line. 
I mainly focused on the CDI TCK for now as this is naturally the area where I 
can be of most use.
I'll also gonna release OWB tonight or so. Just wanted to first fix the TomEE 
tck to really catch all odds in OWB.

LieGrue,
strub


> Am 15.02.2018 um 11:06 schrieb Jonathan Gallimore 
> :
> 
> At the risk of adding to my ever-growing task list and potentially becoming
> a bottleneck, I did some EAR / RAR related fixes in master. I'll port those
> forward and help look at these tests.
> 
> Jon
> 
> On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg 
> wrote:
> 
>> We now pass all tests in tck/cdi-embedded
>> And we have only 3 failing tests in tck/cdi-tomee.
>> 
>> 
>> 
>> 
>> 
>> Those tests are all EAR related.
>> Maybe they are only Arquillian adapter issues?
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 08.02.2018 um 13:30 schrieb Mark Struberg >> :
>>> 
>>> Well, this is why there are passivation listeners and stuff in the
>> Servlet spec.
>>> 
>>> We could easily also send a specific CDI event for it. But there is no
>> such event in the CDI spec so far.
>>> The @Destryoed and @BeforeDestroyed are specifically for _destroyal_.
>>> 
>>> LieGrue,
>>> strub
>>> 
 Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
 
 Hmm, it is more vicious cause if the session is not destroyed you can
>> still
 want to trigger this event. Guess it is another case where both cases
>> are
 desirable (i want to clean up related state of the session...as well as
>> I
 don't want to touch the session)...
 
 Since the appcontext destroy can be used as a workaround I think it is
>> fine
 to challenge them now.
 
 
 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github > rmannibucau> |
 LinkedIn  | Book
 > ee-8-high-performance>
 
 2018-02-08 11:37 GMT+01:00 Mark Struberg :
 
> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
>> SessionScoped.class)
> and @Destroyed(SessionScoped.class) do work.
> The tests itself are fine, but instead of relying that the sessions get
> destroyed at server shutdown they could also have used
> Session.invalidate()...
> 
> LieGrue,
> strub
> 
> 
>> Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> :
>> 
>> 2018-02-08 11:28 GMT+01:00 Mark Struberg :
>> 
>>> All the embedded tests are now green.
>>> 
>>> I'm now working on cdi-tomes (webprofile TCK).
>>> So far we have 10 errors, but a few TCK tests are broken because they
>>> wrongly assume that a container stop also kills the Session.
>>> 
>> 
>> We can make them passing. We already did this kind of hack but since
>> all
>> container have pluggability here - for good reasons - I agree they
>> shouldn't be in the TCK.
>> 
>> 
>>> I've challenged those tests. Still have to review every red test...
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
 Am 08.02.2018 um 11:19 schrieb Matthew Broadhead <
>>> matthew.broadh...@nbmlaw.co.uk>:
 
 nearly there!
 
 On 07/02/2018 11:57, Mark Struberg wrote:
> [ERROR] Failures:
> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> arquillianBeforeClass:109
>>> » Deployment
> [INFO]
> [ERROR] Tests run: 1567, Failures: 1, Errors: 0, Skipped: 5
> 
> 
> Wohuuu, 1 to go!
> 
> LieGrue,
> strub
> 
>> Am 02.02.2018 um 21:54 schrieb Mark Struberg
> > 
>> And the last status:
>> 
>> [ERROR] Failures:
>> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> arquillianBeforeClass:109
>>> » Deployment
>> [ERROR]   ContainerLifeCycleEventRuntime
>> InvocationTest>Arquillian.
> arquillianBeforeClass:109
>>> » Deployment
>> [ERROR]   BuiltinMetadataEEBeanTest>Arquillian.run:164->
>>> interceptedBeanForEEComponentIsNullInInterceptor:61 expected [true]
>> but
>>> found [false]
>> [INFO]
>> [ERROR] Tests run: 1570, Failures: 3, Errors: 0, Skipped: 22
>> 
>> Reminder: this is for cdi-embedded only for now.
>> But once we are through that the rest is usually much easier.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 

Re: TomEE8 TCK status

[Jonathan Gallimore]

At the risk of adding to my ever-growing task list and potentially becoming
a bottleneck, I did some EAR / RAR related fixes in master. I'll port those
forward and help look at these tests.

Jon

On Wed, Feb 14, 2018 at 10:28 PM, Mark Struberg 
wrote:

> We now pass all tests in tck/cdi-embedded
> And we have only 3 failing tests in tck/cdi-tomee.
>
> 
> 
> 
>
> Those tests are all EAR related.
> Maybe they are only Arquillian adapter issues?
>
> LieGrue,
> strub
>
>
>
> > Am 08.02.2018 um 13:30 schrieb Mark Struberg  >:
> >
> > Well, this is why there are passivation listeners and stuff in the
> Servlet spec.
> >
> > We could easily also send a specific CDI event for it. But there is no
> such event in the CDI spec so far.
> > The @Destryoed and @BeforeDestroyed are specifically for _destroyal_.
> >
> > LieGrue,
> > strub
> >
> >> Am 08.02.2018 um 12:12 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
> >>
> >> Hmm, it is more vicious cause if the session is not destroyed you can
> still
> >> want to trigger this event. Guess it is another case where both cases
> are
> >> desirable (i want to clean up related state of the session...as well as
> I
> >> don't want to touch the session)...
> >>
> >> Since the appcontext destroy can be used as a workaround I think it is
> fine
> >> to challenge them now.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github  rmannibucau> |
> >> LinkedIn  | Book
> >>  ee-8-high-performance>
> >>
> >> 2018-02-08 11:37 GMT+01:00 Mark Struberg :
> >>
> >>> Yea, it's mainly testing whether the @Observes @BeforeDestroyed(
> SessionScoped.class)
> >>> and @Destroyed(SessionScoped.class) do work.
> >>> The tests itself are fine, but instead of relying that the sessions get
> >>> destroyed at server shutdown they could also have used
> >>> Session.invalidate()...
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
>  Am 08.02.2018 um 11:30 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
>  :
> 
>  2018-02-08 11:28 GMT+01:00 Mark Struberg :
> 
> > All the embedded tests are now green.
> >
> > I'm now working on cdi-tomes (webprofile TCK).
> > So far we have 10 errors, but a few TCK tests are broken because they
> > wrongly assume that a container stop also kills the Session.
> >
> 
>  We can make them passing. We already did this kind of hack but since
> all
>  container have pluggability here - for good reasons - I agree they
>  shouldn't be in the TCK.
> 
> 
> > I've challenged those tests. Still have to review every red test...
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 08.02.2018 um 11:19 schrieb Matthew Broadhead <
> > matthew.broadh...@nbmlaw.co.uk>:
> >>
> >> nearly there!
> >>
> >> On 07/02/2018 11:57, Mark Struberg wrote:
> >>> [ERROR] Failures:
> >>> [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
> >>> [INFO]
> >>> [ERROR] Tests run: 1567, Failures: 1, Errors: 0, Skipped: 5
> >>>
> >>>
> >>> Wohuuu, 1 to go!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
>  Am 02.02.2018 um 21:54 schrieb Mark Struberg
> >>>  >> :
> 
>  And the last status:
> 
>  [ERROR] Failures:
>  [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
>  [ERROR]   ContainerLifeCycleEventRuntime
> InvocationTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
>  [ERROR]   BuiltinMetadataEEBeanTest>Arquillian.run:164->
> > interceptedBeanForEEComponentIsNullInInterceptor:61 expected [true]
> but
> > found [false]
>  [INFO]
>  [ERROR] Tests run: 1570, Failures: 3, Errors: 0, Skipped: 22
> 
>  Reminder: this is for cdi-embedded only for now.
>  But once we are through that the rest is usually much easier.
> 
>  LieGrue,
>  strub
> 
> 
> 
> > Am 01.02.2018 um 23:18 schrieb Mark Struberg  >:
> >
> > We are moving...
> >
> > [ERROR] Failures:
> > [ERROR]   EnterpriseDefaultBeanDiscoveryModeTest>Arquillian.
> >>> arquillianBeforeClass:109
> > » Deployment
> > [ERROR]   ObserverMethodInvocationContex
> tTest>Arquillian.run:164->
> > testTransactionalObserverMethod:55 » EJB
> > [ERROR]   SessionBeanObserverMethodInvoc
> >>> ationContextTest>Arquillian.
> > 

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