Re: MP.next()

[Romain Manni-Bucau]

Isnt it fb_tomee8 branch so tomee 8?

Otherwise +1

Le 17 avr. 2018 01:11, "Jean-Louis Monteiro"  a
écrit :

> Hi community,
>
> Most microprofile requires Java 8.
> Is everyone ok if we have microprofile implemented on TomEE 7.1 (Java 8)?
>
> Thanks
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

MP.next()

[Jean-Louis Monteiro]

Hi community,

Most microprofile requires Java 8.
Is everyone ok if we have microprofile implemented on TomEE 7.1 (Java 8)?

Thanks


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

Re: [RESULT] Explore creating a reusable JWT Library

[Jean-Louis Monteiro]

The PR has been merged.
Thanks everyone for voting.

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

On Thu, Apr 12, 2018 at 4:25 PM, Romain Manni-Bucau 
wrote:

> why -> for consistency accross our coupled communities
> why does it matter if it is in G for T? -> it doesn't
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-12 15:56 GMT+02:00 Matthew Broadhead  uk>:
> > we already include libraries from geronimo, e.g. javamail, so why does it
> > matter where the library resides as long as it can be included in the
> > package
> >
> >
> > On 11/04/2018 15:05, Romain Manni-Bucau wrote:
> >>
> >> Hi Matthew,
> >>
> >> No, technicall there are a lot of small things to do before it can be
> >> "included" but the main blocker for me is that the exact same project
> >> is created at geronimo (actually this code was designed to be owned by
> >> geronimo and the artifact imported in tomee).
> >> Since G will have it I would like to avoid to have to maintain 2
> >> versions of the "same" code, it already proved being a failure promise
> >> multiple times so it is more a management reason than a technical one
> >> since the spec is pretty trivial.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>
> >>
> >> 2018-04-11 14:54 GMT+02:00 Matthew Broadhead
> >> :
> >>>
> >>> Hi David,
> >>>
> >>> Thanks for the invitation to vote.  I don't want to vote because I am
> not
> >>> sure I have enough knowledge to be able to do so.
> >>>
> >>> My gut feeling would probably be to side with Mark and Romain as they
> >>> have
> >>> been very supportive with my queries about TomEE and they have shown
> >>> deep
> >>> technical knowledge about the inner workings.
> >>>
> >>> On the other hand I don't want to dismiss the excellent effort others
> are
> >>> making on the JWT issue.  However as long as the code is reusable and
> >>> finds
> >>> a home it will not be wasted.
> >>>
> >>> I am still interested to know what Mark and Romain are looking for
> before
> >>> they accept it into the project.  Does it need to have proven track
> >>> record
> >>> and reliability?  It is a security plugin after all...
> >>>
> >>> Matthew
> >>>
> >>>
> >>> On 10/04/2018 05:23, David Blevins wrote:
> 
>  Officially closing the vote.  Thanks for the patience everyone.  As
>  mentioned in the other vote, this one needed some good discussion and
> a
>  bit
>  of extra time.
> 
>  +1s
>  Andy Gumbrecht
>  David Blevins
>  Ivan Junckes Filho
>  Jean-Louis Monteiro
>  Jonathan Gallimore
>  Thiago Veronezi
> 
>  +0
>  Rudy De Busscher
> 
>  -1s
>  Mark Struberg
>  Romain Manni-Bucau
> 
>  This was intended as a non-technical vote, so I've registered Mark's
> -1
>  as
>  he intended it.  Thanks, Mark, for the clarification.  Matthew, you
>  didn't
>  vote, your participation was quite high -- thank you!  You're more
> then
>  welcome to vote, sir :)
> 
>  This was a consensus vote to see if there was will keep working on the
>  JWT
>  code here and see if it could be made reusable.  We didn't really need
>  this
>  vote to accomplish anything other than to see where people's heads are
>  at
>  and make sure we're communicating with each other clearly.
> 
>  It does seem over all that the desire is to take a couple more steps.
>  This vote did not address where the code should live in its final
> state.
>  We
>  don't really know how reusable anything will be.
> 
>  I'd probably expect us to take a few more steps, see how things look
> and
>  come back to the "where" topic.
> 
> 
>  -David
> 
> 
> > On Mar 18, 2018, at 5:02 PM, David Blevins 
> > wrote:
> >
> > The vote for merging PR 123 does not address community will on what
> to
> > do
> > with the code beyond merging it.  One can realistically vote +1 to
> > merge the
> > code, but then desire to see the code cleaned up and moved elsewhere.
> > One
> > can realistically desire seeing an attempt to clean up the code to
> find
> > what
> > is reusable and may wish to withhold a final decision until we see
> how
> > fruitful such a module would be.
> >
> > Out of respect for people who may not know exactly how they feel
> (TomEE
> > or Geronimo), this is a vote for the latter.
> >
> > Vote: Should we attempt to extract code from the JWT PR to see what
> is
> > reusable and how successful such a jar would be?
> >
> > +1 Let's give it a shot here
> > +-0
> > -1 Let's do this elsewhere
> >
> > If the vote is +1 to attempt an extraction of reusable code here,
> final
> > conclusion 

Re: TomEE-7.0.5 work

[Romain Manni-Bucau]

It is the fix, originally alternative=true was a very secured impl cause
even with a poorly setup test it was passing but it was wrong. Maybe it is
worth a ticket to have it in the changelog but no doubt we are good now.

Le 16 avr. 2018 07:41, "Mark Struberg"  a écrit :

> Hi jon!
>
> Most probably has to do with fixing OWB-1209.
>
> A custom Bean which is an @Alternative also must be enabled via beans.xml
> as per the spec :(
>
> I know this is not convenient, but thats what the spec says.
> From CDI-2.0 onwards one can add the Prioritized interface and add a
> priority n a programmatic way.
>
> LieGrue,
> Strub
>
> > Am 15.04.2018 um 23:36 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >
> > On the openejb-mockito test failure - forget my previous emails - setting
> > the MockBean to not be an AlternativeBean seems to do the trick. Pushed.
> > Lets see what we get from the CI now.
> >
> > Cheers
> >
> > Jon
> >
> > On Sun, Apr 15, 2018 at 9:43 PM, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >> OK, I'm not sure which commit causes that test failure, but this commit
> is
> >> ok: https://github.com/apache/openwebbeans/commit/
> >> 4b7259a1f7c8c0d65736f753df9e6a43a262ed96. Will try and pin it down.
> >>
> >> In other news - Johnzon patch submitted, and discussion opened on the
> >> Johnzon dev@ mailing list. Will keep this thread posted on progress.
> >>
> >> Jon
> >>
> >>
> >>
> >> On Sun, Apr 15, 2018 at 9:03 PM, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >>
> >>> Thanks all!
> >>>
> >>> I have looked at the test failures on the CI. The bval-embedded tests
> >>> should be ok now - the other failures were in the openejb-mockito
> module,
> >>> and I think they relate to this change in OWB:
> https://github.com/apache
> >>> /openwebbeans/commit/89c18915afc2173ec1c5478ca6dc09ecce322d2a
> >>>
> >>> To be honest, I don't know where to start looking at this one, can
> anyone
> >>> help? I'd appreciate any learning I can do in the process. In essence,
> >>> we're seeing this:
> >>>
> >>> Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: Api
> >>> type [org.apache.openejb.mockito.Hello] is not found with the
> qualifiers
> >>> Qualifiers: [@javax.enterprise.inject.Default()]
> >>> for injection into Field Injection Point, field name :  helloCdi, Bean
> >>> Owner : [Facade, WebBeansType:ENTERPRISE, Name:null, API
> >>> Types:[org.apache.openejb.mockito.Facade,java.lang.Object],
> >>> Qualifiers:[javax.enterprise.inject.Default,javax.
> enterprise.inject.Any]]
> >>> at org.apache.webbeans.util.InjectionExceptionUtil.throwUnsatis
> >>> fiedResolutionException(InjectionExceptionUtil.java:65)
> >>> at org.apache.webbeans.container.InjectionResolver.checkInjecti
> >>> onPoint(InjectionResolver.java:234)
> >>> at org.apache.webbeans.container.BeanManagerImpl.validate(BeanM
> >>> anagerImpl.java:1209)
> >>> at org.apache.webbeans.util.WebBeansUtil.validate(
> WebBeansUtil.java:1709)
> >>> at org.apache.webbeans.config.BeansDeployer.validate(BeansDeplo
> >>> yer.java:924)
> >>> at org.apache.webbeans.config.BeansDeployer.validateInjectionPo
> >>> ints(BeansDeployer.java:835)
> >>> at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeploye
> >>> r.java:318)
> >>> ... 24 more
> >>>
> >>> As far as I can see the extension adds the necessary stuff
> >>> on javax.enterprise.inject.spi.AfterBeanDiscovery here:
> >>> https://github.com/apache/tomee/blob/master/utils/
> >>> openejb-mockito/src/main/java/org/apache/openejb/mockito/
> >>> MockitoExtension.java#L53
> >>>
> >>> I'll a build without that change to a) confirm that it is that change,
> >>> and b) see if that shows any different behaviour.
> >>>
> >>>
> >>> Here's the output from the tests:
> >>>
> >>> -
> >>>
> >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_
> 141.jdk/Contents/Home/bin/java
> >>> -ea -Didea.test.cyclic.buffer.size=1048576 "-javaagent:/Applications/
> IntelliJ
> >>> IDEA.app/Contents/lib/idea_rt.jar=50678:/Applications/IntelliJ
> >>> IDEA.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> >>> "/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.
> jar:/Applications/IntelliJ
> >>> IDEA.app/Contents/plugins/junit/lib/junit-rt.jar:/
> Applications/IntelliJ
> >>> IDEA.app/Contents/plugins/junit/lib/junit5-rt.jar:/Library/
> >>> Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre/
> >>> lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.
> >>> 8.0_141.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/J
> >>> avaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre/lib/ex
> >>> t/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> >>> 141.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/
> >>> JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre/lib/
> >>> ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> >>> 141.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/
> >>>