Re: starting with the 7.0.5 release steps.

[Romain Manni-Bucau]

Dropping the example will require to move their tests in the main chain
since they are part of our coverage.

Also note you probably dont want to use release plugin cause running the
test (with -Pall-adapters if you respect the plugin philosophy) is quite
long (should be ~3h x2). Just tag and deploy manually from a green build on
the CI, this is more reliable for tomee.

Le mer. 20 juin 2018 00:14, Jonathan Gallimore 
a écrit :

> Sure, I'll take a look tomorrow morning.
>
> On Tue, 19 Jun 2018, 21:57 Mark Struberg, 
> wrote:
>
> >  it's license is ALv2, so not a biggie.
> > Do you put it onto your list, Jon?
> > txs and LieGrue,strub
> >
> > On Tuesday, 19 June 2018, 22:11:23 CEST, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >  Definitely a left over, they should be self contained.
> >
> > Jon
> >
> > On Tue, 19 Jun 2018, 21:04 Mark Struberg, 
> > wrote:
> >
> > >  while fixing the versions of almost all our examples I found the
> > > following parent pom
> > > 
> > >  org.tomitribe
> > >  oss-parent
> > >  2
> > > 
> > >
> > >
> > > do we really want this?I thought our examples should be self-contained,
> > > isn't?
> > > Guess that's just an oversight and a leftover from a code donation?
> > > txs and LieGrue,strub
> > >
> > >On Tuesday, 19 June 2018, 21:49:40 CEST, Mark Struberg
> > >  wrote:
> > >
> > >  And blowing up badly :(
> > >
> > >
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare
> (default-cli)
> > > on project tomee-project: The version could not be updated:
> > > ${tomee.version} -> [Help 1]
> > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute
> > > goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare
> > > (default-cli) on project tomee-project: The version could not be
> updated:
> > > ${tomee.version}
> > >
> > >
> > >
> > >On Tuesday, 19 June 2018, 21:15:06 CEST, Mark Struberg
> > >  wrote:
> > >
> > >  Rolling a 7.0.5 release now.
> > >
> > > Doing this on my linux box, so I hope I didn't forget to setup
> anything.
> > > LieGrue,strub
> > >
> >
>

Fwd: [2/2] tomee git commit: add testng runner files for tests which are under development.

[Romain Manni-Bucau]

FYI we already have these files in src/test/resources ;)

-- Forwarded message -
From: 
Date: mar. 19 juin 2018 21:12
Subject: [2/2] tomee git commit: add testng runner files for tests which
are under development.
To: 


add testng runner files for tests which are under development.

Just change those files as needed. But please don't check all changes in...


Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/344cc5cd
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/344cc5cd
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/344cc5cd

Branch: refs/heads/master
Commit: 344cc5cd52f43eab3d13ce39f3b308582350af45
Parents: 1e0438f
Author: Mark Struberg 
Authored: Tue Jun 19 21:11:32 2018 +0200
Committer: Mark Struberg 
Committed: Tue Jun 19 21:11:32 2018 +0200

--
 tck/cdi-embedded/dev-tests.xml | 60 +++
 tck/cdi-tomee/dev-tests.xml| 62 +
 2 files changed, 122 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/tomee/blob/344cc5cd/tck/cdi-embedded/dev-tests.xml
--
diff --git a/tck/cdi-embedded/dev-tests.xml b/tck/cdi-embedded/dev-tests.xml
new file mode 100644
index 000..52e88d3
--- /dev/null
+++ b/tck/cdi-embedded/dev-tests.xml
@@ -0,0 +1,60 @@
+
+
+http://testng.org/testng-1.0.dtd; >
+
+  
+
+
+
+
+
+
+
+
+
+  
+
+  
+
+
+
+  
+  
+
+  
+
+
+  
+
+

http://git-wip-us.apache.org/repos/asf/tomee/blob/344cc5cd/tck/cdi-tomee/dev-tests.xml
--
diff --git a/tck/cdi-tomee/dev-tests.xml b/tck/cdi-tomee/dev-tests.xml
new file mode 100644
index 000..f42d9a0
--- /dev/null
+++ b/tck/cdi-tomee/dev-tests.xml
@@ -0,0 +1,62 @@
+
+
+http://testng.org/testng-1.0.dtd; >
+
+  
+
+
+
+
+
+
+
+
+
+  
+
+  
+
+
+
+  
+
+
+
+  
+
+

Re: TomEE-7.0.5 work

[Romain Manni-Bucau]

from memory this one was using a short timing (like 2s instead of 10s) to
avoid a too long build, we can increase it a lot (like x2 or x3 scale) to
make it stable now it is in openejb-core (originally it was an external
module and slowing down the build too much being another module). Feel free
to test that scale change but don't change the ratio please.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 18 juin 2018 à 19:31, Mark Struberg  a
écrit :

> dumdidum, the following still fails on OSX from time to time
>
> ManagedScheduledExecutorServiceTest.triggerRunnableSchedule:124
>
>
> LieGrue,
> strub
>
>
> > Am 18.06.2018 um 12:23 schrieb Mark Struberg  >:
> >
> > FOUND IT.
> >
> > hack, that was nasty ;)
> >
> > In ArchivingTest#watch() we start a new thread to observe the changes on
> a WatchKey.
> > Too bad we do not stop it after the test.
> >
> > So when we test the parameterised gzip as 2nd run (zip is first run), we
> now have 2 thread open.
> > And both write to the same lastEvent() variable...
> >
> > I now kill the old thread if running.
> > I'm a bit exhausted now, so would prefer if someone could check my
> changes.
> >
> > txs and LieGrue,
> > strub
> >
> > PS: will also pull it over to fb_tomee8 now, but master has the changes.
> >
> >> Am 18.06.2018 um 12:09 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >>
> >> It passed on my Ubuntu box last night too. I have both Windows and OSX
> >> boxes. Currently travelling, but I'll kick off a build on both in the
> next
> >> hour.
> >>
> >> Jon
> >>
> >> On Mon, 18 Jun 2018, 10:03 Mark Struberg, 
> wrote:
> >>
> >>> I now tried it on my Fedora box and it also works.So the problem only
> >>> seems to persist on OSX.I've not yet tested on Windows. Anyone has a
> Win
> >>> box around?
> >>> Right now waiting for my MSDN license...
> >>> LieGrue,strub
> >>>
> >>>   On Sunday, 17 June 2018, 22:14:04 CEST, Romain Manni-Bucau <
> >>> rmannibu...@gmail.com> wrote:
> >>>
> >>> If true a sleep would workaround it. That said i dont reproduce it on
> >>> ubuntu, even on very fast machines so not sure. Maybe local setup
> related?
> >>>
> >>> Le dim. 17 juin 2018 21:49, Mark Struberg 
> a
> >>> écrit :
> >>>
> >>>> Just looked what we do in fb_tomee8. And found the following:
> >>>>
> >>>> @Ignore //X TODO see TOMEE-2139 currently broken due to
> #f24c42e2212c575
> >>>> We cannot release with this test.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>> Am 17.06.2018 um 14:03 schrieb Romain Manni-Bucau <
> >>> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> Can need a clean to pass IIRC. Code is unrelated to tomcat actually
> >>>>>
> >>>>> Le dim. 17 juin 2018 12:16, Mark Struberg  >
> >>> a
> >>>>> écrit :
> >>>>>
> >>>>>> That rotating test seems to stick.
> >>>>>>
> >>>>>> Might have to do with a minor tomcat behaviour change.
> >>>>>> Something which is at least not behaving stochastic and we can work
> on
> >>>> it.
> >>>>>> Will try to tackle it tonight.
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>> Am 17.06.2018 um 11:50 schrieb Mark Struberg
> >>>  >>>>>>> :
> >>>>>>>
> >>>>>>> That's the goal :D
> >>>>>>>
> >>>>>>> I will be offline this afternoon, just like to providing feedback
> and
> >>>>>> pick up in the evening again.
> >>>>>>> Those are all stochastic failures. Once you resume from there they
> >>> will
> >>>>>> likely work fine again :(
> >>>>>>> Of course that's fru

Re: TomEE-7.0.5 work

[Romain Manni-Bucau]

t;>>> Am 05.06.2018 um 17:45 schrieb Jonathan Gallimore <
> >>> jonathan.gallim...@gmail.com>:
> >>>>>>
> >>>>>> I think we're still looking for an OpenJPA release (unless I missed
> >>> it).
> >>>>>>
> >>>>>> Jon
> >>>>>>
> >>>>>> On Tue, 5 Jun 2018, 14:03 Alex The Rocker, 
> >>> wrote:
> >>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I TomEE 7.0.5 finally ready to be released?
> >>>>>>> (I don't see new activity for 1 month on this intention to release,
> >>>>>>> what's blocking?)
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Alexandre
> >>>>>>>
> >>>>>>>
> >>>>>>> 2018-05-05 10:53 GMT+02:00 Mark Struberg  >:
> >>>>>>>> btw, link to the buildbot is here
> >>>>>>>> https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/920
> >>>>>>>>
> >>>>>>>> LieGrue,
> >>>>>>>> strub
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Am 05.05.2018 um 10:49 schrieb Mark Struberg
> >>>  >>>>>>>> :
> >>>>>>>>>
> >>>>>>>>> master build is broken since a while!
> >>>>>>>>>
> >>>>>>>>> [ERROR] Failed to execute goal
> >>>>>>> org.apache.maven.plugins:maven-surefire-plugin:2.20:test
> >>>>>>> (test-tomee-remote) on project arquillian-tomee-webprofile-tests:
> >>> There are
> >>>>>>> test failures.
> >>>>>>>>> [ERROR]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The rest seems to work fine.
> >>>>>>>>> So I gonna push forward with the Johnzon-1.0.1 release
> >>>>>>>>>
> >>>>>>>>> Can anybody have a look at it?
> >>>>>>>>>
> >>>>>>>>> txs and LieGrue,
> >>>>>>>>> strub
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Am 04.05.2018 um 22:05 schrieb Mark Struberg
> >>>  >>>>>>>> :
> >>>>>>>>>>
> >>>>>>>>>> I've now also deployed fresh snapshots and will update in master
> >>>>>>>>>>
> >>>>>>>>>> LieGrue,
> >>>>>>>>>> strub
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Am 04.05.2018 um 21:53 schrieb Mark Struberg
> >>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, working on it.
> >>>>>>>>>>>
> >>>>>>>>>>> But I only see 2 bugs reported for this release.
> >>>>>>>>>>>
> >>>>>>>>>>>
> https://issues.apache.org/jira/projects/JOHNZON/versions/12340497
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> JOHNZON-160 org.apache.johnzon.mapper.MapperException:
> >>>>>>> ObjectConverters are only supported for Classes not Types
> >>> Unassigned
> >>>>>>> Resolved
> >>>>>>>>>>> JOHNZON-101 JsonObject#getJson* must not throw
> >>> NullPointerException
> >>>>>>> Reinhard Sandtner   Closed
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I now applied the patch - thanks again to Jon for doing all
> the
> >>> work!
> >>>>>>>>>>>
> >>>>>>>>>>> I've also went through the changes (hack, that was a lot!) and
> >>> tried
> >>>>>>> to extract the ticket numbers:
> >>>>>>>>>>>
&g

Re: TomEE-7.0.5 work

[Romain Manni-Bucau]

t;>>>>>> Am 04.05.2018 um 21:53 schrieb Mark Struberg
> >>>> :
> >>>>>>>>
> >>>>>>>> Yes, working on it.
> >>>>>>>>
> >>>>>>>> But I only see 2 bugs reported for this release.
> >>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/projects/JOHNZON/versions/12340497
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> JOHNZON-160 org.apache.johnzon.mapper.MapperException:
> >>>> ObjectConverters are only supported for Classes not Types
> Unassigned
> >>>> Resolved
> >>>>>>>> JOHNZON-101 JsonObject#getJson* must not throw
> NullPointerException
> >>>> Reinhard Sandtner   Closed
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I now applied the patch - thanks again to Jon for doing all  the
> work!
> >>>>>>>>
> >>>>>>>> I've also went through the changes (hack, that was a lot!) and
> tried
> >>>> to extract the ticket numbers:
> >>>>>>>>
> >>>>
> https://issues.apache.org/jira/projects/JOHNZON/versions/12340497#release-report-tab-body
> >>>>>>>>
> >>>>>>>> So I'm ready to roll the Johnzon-1.0.1 release ^^
> >>>>>>>>
> >>>>>>>> Will keep you updated.
> >>>>>>>>
> >>>>>>>> LieGrue,
> >>>>>>>> strub
> >>>>>>>>
> >>>>>>>>> Am 02.05.2018 um 22:45 schrieb Alex The Rocker <
> alex.m3...@gmail.com
> >>>>> :
> >>>>>>>>>
> >>>>>>>>> Hello,
> >>>>>>>>>
> >>>>>>>>> Now that OWB-1.7.5 vote passed, how about Johnzon 1.0.1 for
> upcoming
> >>>>>>>>> TomEE 7.0.5?
> >>>>>>>>> Shouldn't there be a vote to officialize Johnzon 1.0.1?
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> Alexandre
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2018-04-29 13:04 GMT+02:00 Mark Struberg
>  >>>>> :
> >>>>>>>>>> The OWB-1.7.5 vote is on the list now.
> >>>>>>>>>>
> >>>>>>>>>> LieGrue,
> >>>>>>>>>> strub
> >>>>>>>>>>
> >>>>>>>>>>> Am 27.04.2018 um 15:16 schrieb Romain Manni-Bucau <
> >>>> rmannibu...@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>> We are working with Mark on a release train soon, johnzon
> would be
> >>>> part of
> >>>>>>>>>>> it probably.
> >>>>>>>>>>> An OWB release is needed too AFAIK and is on its way.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>> https://github.com/rmannibucau> |
> >>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>>>>>>>> <
> >>>>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 2018-04-27 14:43 GMT+02:00 Alex The Rocker <
> alex.m3...@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hello TomEE developers,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was away for a while, and I'm a bit lost on the TomEE 7.0.5
> >>>> upcoming
> >>>>>>>>>>>> release plans:
> >>>>>&g

Re: Alias file from META-INF/org.apache.openejb.resource.jdbc.PasswordCipher not found

[Romain Manni-Bucau]

Hi, your SPI file is wrong:

META-INF/org.apache.openejb.cipher.PasswordCipher/reverse

see
https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/resources/META-INF/org.apache.openejb.cipher.PasswordCipher/reverse
for example

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 12 juin 2018 à 14:35, naina  a écrit :

> Hi,
> I am trying to plug my own algorithm to extend Apache OpenEJB built in
> ones.
> I am giving an entry with PasswordCipher property set to alias name reverse
> like:
> PasswordCipher reverse
> and reverse(alias) file is kept in
> META-INF/org.apache.openejb.resource.jdbc.PasswordCipher with the below
> content:
> packageName$
> for eg.
> abc.xyz$MyAlgo
>
> MyAlgo file then implements the Password Cipher and overrrides the encrypt
> and decrypt function respectively.
>
>
> Doing all this gives me below error:
>
> Class not found for reverse(alias) file.
> Have also tried by setting thevalue of PasswordCipher to path of my
> implemetation class i.e abc.xyz.MyAlgo as per above example .
>
> Please suggest where am i going wrong.
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: broken SubjectServiceTomEETest in fb_tomee8

[Romain Manni-Bucau]

Hmm, if that's a regression due to openejb.scan.webapp.container change we
should fix it otherwise we'll break a lot of users.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 9 juin 2018 à 18:48, Mark Struberg  a
écrit :

> It also picks it up as 2 deplorable a...
>
> Mit autocorrect gesendet
>
> > Am 09.06.2018 um 18:02 schrieb Romain Manni-Bucau  >:
> >
> > What is suspicious is that:
> > 1. was working well for years
> > 2. it is already isolated in tomee since we scan the deployable and not
> the
> > classpath for that reason
> >
> > maybe the default scanning of the container change?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le sam. 9 juin 2018 à 16:20, Mark Struberg  a
> > écrit :
> >
> >> commenting out adding the persistence.xml to the arquillian test makes
> it
> >> pass:
> >> @Deployment
> >> public static WebArchive archive() {
> >>return new WebModule(SubjectServiceTomEETest.class).getArchive()
> >>.addClass(VoteCounter.class)
> >>.addPackage(Subject.class.getPackage()) // domain
> >>//X .addAsWebInfResource(new
> >> ClassLoaderAsset("META-INF/persistence.xml"), "persistence.xml")
> >>
> >> We had such problems in OpenWebBeans as well. There we opted to isolate
> >> the app away completely.That's one of the shortcomings of Arquilian in
> >> practice. It sadly makes a difference whether you run it embedded vs
> >> in-container vs remote-container :(
> >> LieGrue,strub
> >>
> >>On Saturday, 9 June 2018, 16:13:52 CEST, Mark Struberg
> >>  wrote:
> >>
> >>  It seems like one is coming from
> >>
> file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#pollingthe
> >> other from
> >>
> >>
> file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling
> >>
> >>
> >> As if it would be an Arquillian setup issue.I compared fb8 with master
> but
> >> could not find any differences though.
> >> LieGrue,strub
> >>On Saturday, 9 June 2018, 14:28:38 CEST, Romain Manni-Bucau <
> >> rmannibu...@gmail.com> wrote:
> >>
> >> Can be a classloader change with a recent upgrade.
> >>
> >> Le sam. 9 juin 2018 13:23, Mark Struberg  a
> >> écrit :
> >>
> >>>
> >>> I get a duplicate unit exception in
> >>> jug.rest.arquillian.SubjectServiceTomEETest which is in
> polling-web.This
> >>> happens in the fb_tomee8 branch.
> >>>
> >>> 0 = {TreeMap$Entry@5654}
> >>>
> >>
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client1"
> >>> ->
> >>> 1 = {TreeMap$Entry@5655}
> >>>
> >>
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client2"
> >>> ->
> >>> 2 = {TreeMap$Entry@5656}
> >>>
> >>
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling"
> >>> ->
> >>> 3 = {TreeMap$Entry@5657}
> >>>
> >>
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client1"
> >>> ->
> >>> 4 = {TreeMap$Entry@5658}
> >>>
> >>
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client2"
> >>> ->
> >>> 5 = {TreeMap$Entry@5659}
> >>>
> >>
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#polling"
> >>> ->
> >>>
> >>>
> >>> Anyone has an idea why?
> >>> txs and LieGrue,strub
> >>>
>
>

Re: broken SubjectServiceTomEETest in fb_tomee8

[Romain Manni-Bucau]

What is suspicious is that:
1. was working well for years
2. it is already isolated in tomee since we scan the deployable and not the
classpath for that reason

maybe the default scanning of the container change?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 9 juin 2018 à 16:20, Mark Struberg  a
écrit :

>  commenting out adding the persistence.xml to the arquillian test makes it
> pass:
> @Deployment
> public static WebArchive archive() {
> return new WebModule(SubjectServiceTomEETest.class).getArchive()
> .addClass(VoteCounter.class)
> .addPackage(Subject.class.getPackage()) // domain
> //X .addAsWebInfResource(new
> ClassLoaderAsset("META-INF/persistence.xml"), "persistence.xml")
>
> We had such problems in OpenWebBeans as well. There we opted to isolate
> the app away completely.That's one of the shortcomings of Arquilian in
> practice. It sadly makes a difference whether you run it embedded vs
> in-container vs remote-container :(
> LieGrue,strub
>
> On Saturday, 9 June 2018, 16:13:52 CEST, Mark Struberg
>  wrote:
>
>   It seems like one is coming from
> file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#pollingthe
> other from
>
> file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling
>
>
> As if it would be an Arquillian setup issue.I compared fb8 with master but
> could not find any differences though.
> LieGrue,strub
> On Saturday, 9 June 2018, 14:28:38 CEST, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Can be a classloader change with a recent upgrade.
>
> Le sam. 9 juin 2018 13:23, Mark Struberg  a
> écrit :
>
> >
> > I get a duplicate unit exception in
> > jug.rest.arquillian.SubjectServiceTomEETest which is in polling-web.This
> > happens in the fb_tomee8 branch.
> >
> > 0 = {TreeMap$Entry@5654}
> >
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client1"
> > ->
> > 1 = {TreeMap$Entry@5655}
> >
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client2"
> > ->
> > 2 = {TreeMap$Entry@5656}
> >
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling"
> > ->
> > 3 = {TreeMap$Entry@5657}
> >
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client1"
> > ->
> > 4 = {TreeMap$Entry@5658}
> >
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client2"
> > ->
> > 5 = {TreeMap$Entry@5659}
> >
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#polling"
> > ->
> >
> >
> > Anyone has an idea why?
> > txs and LieGrue,strub
> >

Re: broken SubjectServiceTomEETest in fb_tomee8

[Romain Manni-Bucau]

Can be a classloader change with a recent upgrade.

Le sam. 9 juin 2018 13:23, Mark Struberg  a
écrit :

>
> I get a duplicate unit exception in
> jug.rest.arquillian.SubjectServiceTomEETest which is in polling-web.This
> happens in the fb_tomee8 branch.
>
> 0 = {TreeMap$Entry@5654}
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client1"
> ->
> 1 = {TreeMap$Entry@5655}
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#client2"
> ->
> 2 = {TreeMap$Entry@5656}
> "file:/home/struberg/.m2/repository/jug/polling-domain/1.1.0-SNAPSHOT/polling-domain-1.1.0-SNAPSHOT.jar#polling"
> ->
> 3 = {TreeMap$Entry@5657}
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client1"
> ->
> 4 = {TreeMap$Entry@5658}
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#client2"
> ->
> 5 = {TreeMap$Entry@5659}
> "file:/tmp/arquillian-tomee-app-working-dir/0/SubjectServiceTomEETest/#polling"
> ->
>
>
> Anyone has an idea why?
> txs and LieGrue,strub
>

Re: Linkage Error

[Romain Manni-Bucau]

if jackson changed something about its lifecycle@classloader usage then it
can lead to that if part of the app overlapp between the lib part of the
ear and the webapps. In TomEE the webapp tries to load from the parent
first.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 6 juin 2018 à 10:44, Dignesh  a écrit :

> Hello Romain,
>
> I have deployed an ear , which in turn contains multiple wars.
> I have jackson libraries in my webapp.
> I have recently upgraded the jackson to jackson 2.9.5 libraries and with
> that change I am seeing this issue.
> When I revert back to the older version jackson 2.6.6 libraries , i dont
> see
> the linkage error. I removed the older libraries and replaced with the
> newer
> one again and i dont see the issue.
> This behaviour is something i am not seeing it consistently.
>
> Just curious to understand how it was working earlier when i had jackson in
> webapps and now it is throwing the error.
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Linkage Error

[Romain Manni-Bucau]

Hi Dignesh,

can you check 7.0.5 out before digging further?
Also do you deploy an ear or war? If an ear maybe ensure there is no
jackson in the webapps.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 6 juin 2018 à 10:19, Dignesh  a écrit :

> Any Ideas on below error
>
> Caused by: java.lang.LinkageError: loader constraint violation: loader
> (instance of org/apache/openejb/util/classloader/URLClassLoaderFirst)
> previously initiated loading for a different type with name
> "com/fasterxml/jackson/databind/ObjectMapper"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at
>
> org.apache.openejb.util.classloader.URLClassLoaderFirst.loadInternal(URLClassLoaderFirst.java:173)
> at
>
> org.apache.openejb.util.classloader.URLClassLoaderFirst.loadClass(URLClassLoaderFirst.java:121)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
>
> I am using 7.0.2 Version of TomEE.
>
> Thank you,
> Dignesh
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Annotation EJB classes are not recognized if package name does not include "superbiz"

[Romain Manni-Bucau]

Hi

Maybe start in debug mode but superbiz is clearly not hardcoded and we have
tests and users relying on a lot of different names.

Le sam. 26 mai 2018 14:43, sudhakarvm  a écrit :

> I have simple JAX-RS service invoking an annotation based EJB. But my TomEE
> 7.0.3 never recognizes this EJB if it's package name does not include
> "superbiz". Based on the log OpenWebBeans container is started. I have
> empty
> ejb-jar.xml file also. I am not sure whether my TomEE
> conf/system.properties
> file is being read or not, I tried some properties here following with no
> luck:
>
>
> openejb.deployments.classpath.include="file:///C:/installed/apache-tomee-plume-7.0.3/webapps/tomee-jersey-eclipselink/WEB-INF/classes/"
>
> tomee.remote.support = true
> tomee.serialization.class.blacklist = -
> tomee.serialization.class.whitelist = *
> openejb.system.apps = true
> openejb.servicemanager.enabled = true
> openejb.deployments.package.include = .*
>
> Thanks in advance
> Sudhakar
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: completely weird unit test failure

[Romain Manni-Bucau]

https://gitbox.apache.org/repos/asf/commons-weaver.git ;)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 17 mai 2018 à 14:08, Matthew Broadhead <
matthew.broadh...@nbmlaw.co.uk> a écrit :

> i cloned and installed.  but then i thought maybe i should switch to bv2
> branch.
>
> that branch doesn't install
>
> [ERROR] Plugin
> org.apache.commons:commons-weaver-maven-plugin:1.4-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.apache.commons:commons-weaver-maven-plugin:jar:1.4-SNAPSHOT -> [Help 1]
>
>
> On 17/05/18 13:18, Romain Manni-Bucau wrote:
> > We are on git: https://git-wip-us.apache.org/repos/asf/bval.git
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 17 mai 2018 à 12:12, Matthew Broadhead <
> > matthew.broadh...@nbmlaw.co.uk> a écrit :
> >
> >> oh yes sorry.  that won't be pushed to maven central.  is it only
> >> available from svn repo https://svn.apache.org/repos/asf/bval/trunk/ or
> >> is it mirrored on git?
> >>
> >>
> >> On 17/05/18 07:23, Romain Manni-Bucau wrote:
> >>> Did you rebuild bval 2 too?
> >>>
> >>> Le jeu. 17 mai 2018 00:39, Matthew Broadhead <
> >> matthew.broadh...@nbmlaw.co.uk>
> >>> a écrit :
> >>>
> >>>> i pulled and it is still failing one
> >>>>
> >>>> INFO - Deployed
> >>>>
> >>>>
> >>
> Application(path=/home/matthew/git/tomee/server/openejb-cxf-rs/ProviderWithoutAnnotationTest)
> >>>> WARNING - Interceptor for
> >>>> {http://rs.cxf.server.openejb.apache.org/}Endpoint has thrown
> >> exception,
> >>>> unwinding now
> >>>> java.util.MissingFormatArgumentException: Format specifier '%s'
> >>>>at java.util.Formatter.format(Formatter.java:2519)
> >>>>at java.util.Formatter.format(Formatter.java:2455)
> >>>>at java.lang.String.format(String.java:2940)
> >>>>at
> >> org.apache.bval.util.Exceptions.lambda$create$0(Exceptions.java:44)
> >>>>at org.apache.bval.util.Exceptions.create(Exceptions.java:53)
> >>>>at org.apache.bval.util.Exceptions.create(Exceptions.java:44)
> >>>>at org.apache.bval.util.Exceptions.raise(Exceptions.java:63)
> >>>>    at org.apache.bval.util.Exceptions.raiseIf(Exceptions.java:69)
> >>>>at
> org.apache.bval.util.Exceptions.raiseUnless(Exceptions.java:75)
> >>>>at org.apache.bval.util.Validate.isTrue(Validate.java:43)
> >>>>
> >>>> [INFO] OpenEJB :: Server :: CXF RS  FAILURE
> >>>> [02:17 min]
> >>>>
> >>>>
> >>>>
> >>>> On 16/05/18 23:15, Romain Manni-Bucau wrote:
> >>>>> fixed (the message issue, the underlying bval@getter issue + the cxf
> >>>>> validation issue), you need bval  (bval2 branch) snapshot and tomee
> >>>>> fb_tomee8 branch snapshot to get it
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>> <http://rmannibucau.wordpress.com> | Github <
> >>>> https://github.com/rmannibucau> |
> >>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>>
> >>>>> Le mer. 16 mai 2018 à 20:07, Matthew Broadhead <
> >>>>> matthew.broadh...@nbmlaw.co.uk> a écrit :
> >>>>>
> >>>>>> [INFO] Op

Re: completely weird unit test failure

[Romain Manni-Bucau]

We are on git: https://git-wip-us.apache.org/repos/asf/bval.git

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 17 mai 2018 à 12:12, Matthew Broadhead <
matthew.broadh...@nbmlaw.co.uk> a écrit :

> oh yes sorry.  that won't be pushed to maven central.  is it only
> available from svn repo https://svn.apache.org/repos/asf/bval/trunk/ or
> is it mirrored on git?
>
>
> On 17/05/18 07:23, Romain Manni-Bucau wrote:
> > Did you rebuild bval 2 too?
> >
> > Le jeu. 17 mai 2018 00:39, Matthew Broadhead <
> matthew.broadh...@nbmlaw.co.uk>
> > a écrit :
> >
> >> i pulled and it is still failing one
> >>
> >> INFO - Deployed
> >>
> >>
> Application(path=/home/matthew/git/tomee/server/openejb-cxf-rs/ProviderWithoutAnnotationTest)
> >> WARNING - Interceptor for
> >> {http://rs.cxf.server.openejb.apache.org/}Endpoint has thrown
> exception,
> >> unwinding now
> >> java.util.MissingFormatArgumentException: Format specifier '%s'
> >>   at java.util.Formatter.format(Formatter.java:2519)
> >>   at java.util.Formatter.format(Formatter.java:2455)
> >>   at java.lang.String.format(String.java:2940)
> >>   at
> org.apache.bval.util.Exceptions.lambda$create$0(Exceptions.java:44)
> >>   at org.apache.bval.util.Exceptions.create(Exceptions.java:53)
> >>   at org.apache.bval.util.Exceptions.create(Exceptions.java:44)
> >>   at org.apache.bval.util.Exceptions.raise(Exceptions.java:63)
> >>   at org.apache.bval.util.Exceptions.raiseIf(Exceptions.java:69)
> >>   at org.apache.bval.util.Exceptions.raiseUnless(Exceptions.java:75)
> >>   at org.apache.bval.util.Validate.isTrue(Validate.java:43)
> >>
> >> [INFO] OpenEJB :: Server :: CXF RS .... FAILURE
> >> [02:17 min]
> >>
> >>
> >>
> >> On 16/05/18 23:15, Romain Manni-Bucau wrote:
> >>> fixed (the message issue, the underlying bval@getter issue + the cxf
> >>> validation issue), you need bval  (bval2 branch) snapshot and tomee
> >>> fb_tomee8 branch snapshot to get it
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>> Le mer. 16 mai 2018 à 20:07, Matthew Broadhead <
> >>> matthew.broadh...@nbmlaw.co.uk> a écrit :
> >>>
> >>>> [INFO] OpenEJB :: Server :: CXF RS
> >>>>
> >>>> WARNING - Interceptor for
> >>>> {http://johnzon.rs.cxf.server.openejb.apache.org/}Endpoint has thrown
> >>>> exception, unwinding now
> >>>> java.util.MissingFormatArgumentException: Format specifier '%s'
> >>>>
> >>>> SEVERE - can't instantiate
> >>>> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$Writer
> >>>> java.lang.InstantiationException:
> >>>> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$Writer
> >>>>
> >>>> SEVERE - EjbTransactionUtil.handleSystemException: null
> >>>>
> org.apache.openejb.server.cxf.rs.CustomExceptionMapperTest$FooException
> >>>>
> >>>> WARNING - Interceptor for {
> http://rs.cxf.server.openejb.apache.org/}En
> >>>> has thrown exception, unwinding now
> >>>> java.lang.IllegalArgumentException:
> >>>> org.apache.openejb.server.cxf.rs.JSonStreamingOutputTest$En$1@3b4ce8d6
> >>>> is not an instance of class javax.ws.rs.core.Response
> >>>>at
> >>>>
> >>>>
> >>
> org.apache.bval.jsr.job.ValidateReturnValue.(ValidateReturnValue.java:123)
> >>>> these are some of the fails i get on mvn clean install.  although my
> >>>> terminal cuts off output over a certain level
> >>>>
&

Re: completely weird unit test failure

[Romain Manni-Bucau]

Did you rebuild bval 2 too?

Le jeu. 17 mai 2018 00:39, Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk>
a écrit :

> i pulled and it is still failing one
>
> INFO - Deployed
>
> Application(path=/home/matthew/git/tomee/server/openejb-cxf-rs/ProviderWithoutAnnotationTest)
> WARNING - Interceptor for
> {http://rs.cxf.server.openejb.apache.org/}Endpoint has thrown exception,
> unwinding now
> java.util.MissingFormatArgumentException: Format specifier '%s'
>  at java.util.Formatter.format(Formatter.java:2519)
>  at java.util.Formatter.format(Formatter.java:2455)
>  at java.lang.String.format(String.java:2940)
>  at org.apache.bval.util.Exceptions.lambda$create$0(Exceptions.java:44)
>  at org.apache.bval.util.Exceptions.create(Exceptions.java:53)
>  at org.apache.bval.util.Exceptions.create(Exceptions.java:44)
>  at org.apache.bval.util.Exceptions.raise(Exceptions.java:63)
>  at org.apache.bval.util.Exceptions.raiseIf(Exceptions.java:69)
>  at org.apache.bval.util.Exceptions.raiseUnless(Exceptions.java:75)
>  at org.apache.bval.util.Validate.isTrue(Validate.java:43)
>
> [INFO] OpenEJB :: Server :: CXF RS ........ FAILURE
> [02:17 min]
>
>
>
> On 16/05/18 23:15, Romain Manni-Bucau wrote:
> > fixed (the message issue, the underlying bval@getter issue + the cxf
> > validation issue), you need bval  (bval2 branch) snapshot and tomee
> > fb_tomee8 branch snapshot to get it
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 16 mai 2018 à 20:07, Matthew Broadhead <
> > matthew.broadh...@nbmlaw.co.uk> a écrit :
> >
> >> [INFO] OpenEJB :: Server :: CXF RS
> >>
> >> WARNING - Interceptor for
> >> {http://johnzon.rs.cxf.server.openejb.apache.org/}Endpoint has thrown
> >> exception, unwinding now
> >> java.util.MissingFormatArgumentException: Format specifier '%s'
> >>
> >> SEVERE - can't instantiate
> >> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$Writer
> >> java.lang.InstantiationException:
> >> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$Writer
> >>
> >> SEVERE - EjbTransactionUtil.handleSystemException: null
> >> org.apache.openejb.server.cxf.rs.CustomExceptionMapperTest$FooException
> >>
> >> WARNING - Interceptor for {http://rs.cxf.server.openejb.apache.org/}En
> >> has thrown exception, unwinding now
> >> java.lang.IllegalArgumentException:
> >> org.apache.openejb.server.cxf.rs.JSonStreamingOutputTest$En$1@3b4ce8d6
> >> is not an instance of class javax.ws.rs.core.Response
> >>   at
> >>
> >>
> org.apache.bval.jsr.job.ValidateReturnValue.(ValidateReturnValue.java:123)
> >>
> >> these are some of the fails i get on mvn clean install.  although my
> >> terminal cuts off output over a certain level
> >>
> >> On 16/05/18 17:35, Mark Struberg wrote:
> >>> In which module do you get the error?
> >>> Will try to later share my build results.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>> Am 16.05.2018 um 13:51 schrieb Matthew Broadhead <
> >> matthew.broadh...@nbmlaw.co.uk>:
> >>>> if i try to compile fb_tomee8 i get
> >>>>
> >>>> WARNING - Interceptor for {
> http://rs.cxf.server.openejb.apache.org/}En
> >> has thrown exception, unwinding now
> >>>> java.lang.IllegalArgumentException:
> >> org.apache.openejb.server.cxf.rs.JSonStreamingOutputTest$En$1@69762669
> is
> >> not an instance of class javax.ws.rs.core.Response
> >>>>   at
> >>
> org.apache.bval.jsr.job.ValidateReturnValue.(ValidateReturnValue.java:123)
> >>>>
> >>>> On 15/05/18 23:16, Mark Struberg wrote:
> >>>>>fb_tomee8
> >>>>> I've fixed this now by fixing the broken bean. Wonder how this could
> >> have ever worked.Might also be partly random due to different build
> order?
> >>>>> But now I'm off to the next bug.
> >>>>> EarModuleNamesTest
> >>>>> This one also scans for a resource due to haing

Re: Example request

[Romain Manni-Bucau]

Hi

Add a conf/exclusions.list file with this content (assuming tibco- is a
common prefix of tibco jars):

default-list
tibco-

Le jeu. 17 mai 2018 02:41, Lakshmikanth W  a écrit :

> Are there any particular settings to integrate tibco with tomee plus?
> I am seeing below error while tomee starting. I have added necessary
> tibco jars to lib folder.
>
> java.lang.Exception: Could not load com.tibco.security.ssl.String.class
> at
> org.apache.openejb.util.AnnotationFinder.readClassDef(AnnotationFinder.java:305)
> at
> org.apache.openejb.util.AnnotationFinder.find(AnnotationFinder.java:164)
> at
> org.apache.openejb.config.DeploymentLoader.checkAnnotations(DeploymentLoader.java:2088)
> at
> org.apache.openejb.config.DeploymentLoader.discoverModuleType(DeploymentLoader.java:1971)
> at
> org.apache.openejb.config.DeploymentsResolver.processUrls(DeploymentsResolver.java:361)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:257)
> at
> org.apache.openejb.config.DeploymentsResolver.loadFromClasspath(DeploymentsResolver.java:322)
> at
> org.apache.openejb.config.DeploymentLoader.createAppModule(DeploymentLoader.java:648)
> at
> org.apache.openejb.config.DeploymentLoader.load(DeploymentLoader.java:168)
> at
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:855)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:547)
> at
> org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguration(ConfigurationFactory.java:634)
> at
> org.apache.openejb.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:507)
> at
> org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:486)
> at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:150)
> at org.apache.openejb.OpenEJB.init(OpenEJB.java:307)
> at
> org.apache.tomee.catalina.TomcatLoader.initialize(TomcatLoader.java:247)
> at
> org.apache.tomee.catalina.ServerListener.lifecycleEvent(ServerListener.java:168)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:395)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:108)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>
> Thanks,
> Laks
>

Re: completely weird unit test failure

[Romain Manni-Bucau]

fixed (the message issue, the underlying bval@getter issue + the cxf
validation issue), you need bval  (bval2 branch) snapshot and tomee
fb_tomee8 branch snapshot to get it

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 16 mai 2018 à 20:07, Matthew Broadhead <
matthew.broadh...@nbmlaw.co.uk> a écrit :

> [INFO] OpenEJB :: Server :: CXF RS
>
> WARNING - Interceptor for
> {http://johnzon.rs.cxf.server.openejb.apache.org/}Endpoint has thrown
> exception, unwinding now
> java.util.MissingFormatArgumentException: Format specifier '%s'
>
> SEVERE - can't instantiate
> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$Writer
> java.lang.InstantiationException:
> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$Writer
>
> SEVERE - EjbTransactionUtil.handleSystemException: null
> org.apache.openejb.server.cxf.rs.CustomExceptionMapperTest$FooException
>
> WARNING - Interceptor for {http://rs.cxf.server.openejb.apache.org/}En
> has thrown exception, unwinding now
> java.lang.IllegalArgumentException:
> org.apache.openejb.server.cxf.rs.JSonStreamingOutputTest$En$1@3b4ce8d6
> is not an instance of class javax.ws.rs.core.Response
>  at
>
> org.apache.bval.jsr.job.ValidateReturnValue.(ValidateReturnValue.java:123)
>
> these are some of the fails i get on mvn clean install.  although my
> terminal cuts off output over a certain level
>
> On 16/05/18 17:35, Mark Struberg wrote:
> > In which module do you get the error?
> > Will try to later share my build results.
> >
> > LieGrue,
> > strub
> >
> >> Am 16.05.2018 um 13:51 schrieb Matthew Broadhead <
> matthew.broadh...@nbmlaw.co.uk>:
> >>
> >> if i try to compile fb_tomee8 i get
> >>
> >> WARNING - Interceptor for {http://rs.cxf.server.openejb.apache.org/}En
> has thrown exception, unwinding now
> >> java.lang.IllegalArgumentException:
> org.apache.openejb.server.cxf.rs.JSonStreamingOutputTest$En$1@69762669 is
> not an instance of class javax.ws.rs.core.Response
> >>  at
> org.apache.bval.jsr.job.ValidateReturnValue.(ValidateReturnValue.java:123)
> >>
> >>
> >> On 15/05/18 23:16, Mark Struberg wrote:
> >>>   fb_tomee8
> >>> I've fixed this now by fixing the broken bean. Wonder how this could
> have ever worked.Might also be partly random due to different build order?
> >>>
> >>> But now I'm off to the next bug.
> >>> EarModuleNamesTest
> >>> This one also scans for a resource due to haing the
> openejb-itests-beans on the classpath.But since the config is done manually
> it misses the TxMgr setup, which is null.
> >>> I exclude this test for now and want to see how far I come with the
> other tests.
> >>> LieGrue,strub
> >>>
> >>>  On Tuesday, 15 May 2018, 22:03:03 CEST, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >>> Which branch?
> >>>
> >>> Jon
> >>>
> >>> On Tue, May 15, 2018 at 9:51 PM, Mark Struberg
> <strub...@yahoo.de.invalid>
> >>> wrote:
> >>>
> >>>>Well, this looks weird anyhow
> >>>> @Stateless
> >>>> public class AnnotatedFieldInjectionStatefulBean {
> >>>>
> >>>> compare the name and the annotation
> >>>> And the additional error messages
> are:org.apache.openejb.config.ValidationWarning:
> >>>> @Init is ignored for beans of type Stateless.  Class:
> >>>> org.apache.openejb.test.stateful.AnnotatedFieldInjectionStatefulBean
> >>>> Method: create"
> >>>> "org.apache.openejb.config.ValidationWarning: @Remove is ignored for
> >>>> beans of type Stateless.  Class: org.apache.openejb.test.stateful.
> >>>> AnnotatedFieldInjectionStatefulBean Method: remove""
> >>>>
> >>>> Well, yes, true!
> >>>> Is this a negative test bean? ^^
> >>>>
> >>>>  On Tuesday, 15 May 2018, 21:48:26 CEST, Mark Struberg
> >>>> <strub...@yahoo.de.INVALID> wrote:
> >>>>
> >>>>hi folks!
> >>>> I get 2 unit test failures which look completely weird to me.Plus they
> >>>> pa

Re: completely weird unit test failure

[Romain Manni-Bucau]

seems due to our exclusion changes, will try to fix it now

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 16 mai 2018 à 08:44, Mark Struberg <strub...@yahoo.de.invalid> a
écrit :

> Can you probably take a look? This is clearly beyond my foo.
>
> LieGrue,
> strub
>
>
> > Am 16.05.2018 um 07:51 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > That was the trick with link(), if you have the child in classloader C
> and
> > the parent in C.parent then you get the parent included. This is why i
> > think something can have been broken.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 16 mai 2018 à 07:43, Mark Struberg <strub...@yahoo.de.invalid> a
> > écrit :
> >
> >> Yes, but the weird thing is that it comes from the parent CL, so the
> >> scanner has not too much to do with it.
> >> Btw, by excluding the Earname test I came a bit further.
> >>
> >> Now the following are failing in the RS module
> >> [ERROR] Errors:
> >> [ERROR]   ApplicationStarTest.checkStarIsNotAnIssue:43 »
> >> InternalServerError HTTP 500 In...
> >> [ERROR]   DisableTomEEJohnzonTest.client:71 » InternalServerError HTTP
> 500
> >> Internal Serv...
> >> [ERROR]   DisableTomEEJohnzonTest.server:66 » IO Server returned HTTP
> >> response code: 500...
> >> [ERROR]   JSonStreamingOutputTest.run:51 » InternalServerError HTTP 500
> >> Internal Server ...
> >> [ERROR]   ProviderWithoutAnnotationTest.run:62 » InternalServerError
> HTTP
> >> 500 Internal S...
> >> [ERROR]   TomEEConfigurableJohnzonTest.run:91 » IO Server returned HTTP
> >> response code: 5...
> >> [INFO]
> >>
> >>
> >>
> >> But this is likely to a glitch in new bval.Or due to me being de_AT
> >> located... ;)
> >> LieGrue,strub
> >>
> >>On Wednesday, 16 May 2018, 06:51:59 CEST, Romain Manni-Bucau <
> >> rmannibu...@gmail.com> wrote:
> >>
> >> Mark
> >>
> >> Previous test issue can be due to xbean upgrades or scanning changes,
> did
> >> you check that? We tend to link implicitly the finder for these tests
> but
> >> can have been broken at some point.
> >>
> >> Le mar. 15 mai 2018 23:16, Mark Struberg <strub...@yahoo.de.invalid> a
> >> écrit :
> >>
> >>> fb_tomee8
> >>> I've fixed this now by fixing the broken bean. Wonder how this could
> have
> >>> ever worked.Might also be partly random due to different build order?
> >>>
> >>> But now I'm off to the next bug.
> >>> EarModuleNamesTest
> >>> This one also scans for a resource due to haing the
> openejb-itests-beans
> >>> on the classpath.But since the config is done manually it misses the
> >> TxMgr
> >>> setup, which is null.
> >>> I exclude this test for now and want to see how far I come with the
> other
> >>> tests.
> >>> LieGrue,strub
> >>>
> >>>   On Tuesday, 15 May 2018, 22:03:03 CEST, Jonathan Gallimore <
> >>> jonathan.gallim...@gmail.com> wrote:
> >>>
> >>> Which branch?
> >>>
> >>> Jon
> >>>
> >>> On Tue, May 15, 2018 at 9:51 PM, Mark Struberg
> <strub...@yahoo.de.invalid
> >>>
> >>> wrote:
> >>>
> >>>> Well, this looks weird anyhow
> >>>> @Stateless
> >>>> public class AnnotatedFieldInjectionStatefulBean {
> >>>>
> >>>> compare the name and the annotation
> >>>> And the additional error messages
> >>> are:org.apache.openejb.config.ValidationWarning:
> >>>> @Init is ignored for beans of type Stateless.  Class:
> >>&

Re: completely weird unit test failure

[Romain Manni-Bucau]

That was the trick with link(), if you have the child in classloader C and
the parent in C.parent then you get the parent included. This is why i
think something can have been broken.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 16 mai 2018 à 07:43, Mark Struberg <strub...@yahoo.de.invalid> a
écrit :

>  Yes, but the weird thing is that it comes from the parent CL, so the
> scanner has not too much to do with it.
> Btw, by excluding the Earname test I came a bit further.
>
> Now the following are failing in the RS module
> [ERROR] Errors:
> [ERROR]   ApplicationStarTest.checkStarIsNotAnIssue:43 »
> InternalServerError HTTP 500 In...
> [ERROR]   DisableTomEEJohnzonTest.client:71 » InternalServerError HTTP 500
> Internal Serv...
> [ERROR]   DisableTomEEJohnzonTest.server:66 » IO Server returned HTTP
> response code: 500...
> [ERROR]   JSonStreamingOutputTest.run:51 » InternalServerError HTTP 500
> Internal Server ...
> [ERROR]   ProviderWithoutAnnotationTest.run:62 » InternalServerError HTTP
> 500 Internal S...
> [ERROR]   TomEEConfigurableJohnzonTest.run:91 » IO Server returned HTTP
> response code: 5...
> [INFO]
>
>
>
> But this is likely to a glitch in new bval.Or due to me being de_AT
> located... ;)
> LieGrue,strub
>
> On Wednesday, 16 May 2018, 06:51:59 CEST, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Mark
>
> Previous test issue can be due to xbean upgrades or scanning changes, did
> you check that? We tend to link implicitly the finder for these tests but
> can have been broken at some point.
>
> Le mar. 15 mai 2018 23:16, Mark Struberg <strub...@yahoo.de.invalid> a
> écrit :
>
> >  fb_tomee8
> > I've fixed this now by fixing the broken bean. Wonder how this could have
> > ever worked.Might also be partly random due to different build order?
> >
> > But now I'm off to the next bug.
> > EarModuleNamesTest
> > This one also scans for a resource due to haing the openejb-itests-beans
> > on the classpath.But since the config is done manually it misses the
> TxMgr
> > setup, which is null.
> > I exclude this test for now and want to see how far I come with the other
> > tests.
> > LieGrue,strub
> >
> >On Tuesday, 15 May 2018, 22:03:03 CEST, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >  Which branch?
> >
> > Jon
> >
> > On Tue, May 15, 2018 at 9:51 PM, Mark Struberg <strub...@yahoo.de.invalid
> >
> > wrote:
> >
> > >  Well, this looks weird anyhow
> > > @Stateless
> > > public class AnnotatedFieldInjectionStatefulBean {
> > >
> > > compare the name and the annotation
> > > And the additional error messages
> > are:org.apache.openejb.config.ValidationWarning:
> > > @Init is ignored for beans of type Stateless.  Class:
> > > org.apache.openejb.test.stateful.AnnotatedFieldInjectionStatefulBean
> > > Method: create"
> > > "org.apache.openejb.config.ValidationWarning: @Remove is ignored for
> > > beans of type Stateless.  Class: org.apache.openejb.test.stateful.
> > > AnnotatedFieldInjectionStatefulBean Method: remove""
> > >
> > > Well, yes, true!
> > > Is this a negative test bean? ^^
> > >
> > >On Tuesday, 15 May 2018, 21:48:26 CEST, Mark Struberg
> > > <strub...@yahoo.de.INVALID> wrote:
> > >
> > >  hi folks!
> > > I get 2 unit test failures which look completely weird to me.Plus they
> > > pass in the IDE but fail in mvn.
> > > ERROR] Failures:
> > > [ERROR]  CheckDescriptorLocationTest.testWarWithDescriptorInMetaInf
> Keys
> > > do not match expected:<...or.incorrectLocation[]> but
> > > was:<...or.incorrectLocation[
> > > ignoredMethodAnnotation
> > > ignoredMethodAnnotation]>
> > > [ERROR]  CheckDescriptorLocationTest.testWarWithDescriptorInRoot Keys
> do
> > > not match expected:<...or.incorrectLocation[]> but
> > > was:<...or.incorrectLocation[
> > > ignoredMethodAnnotation
> > > ignoredMethodAnnotation]>
> > >
> > >
> > > The unit test in question is
> > > org.apache.openejb.config.CheckDescriptorLocationTest#
> > > testWarWithDescriptorInRoot
> > > This bundles a single FooBean.class with a single error.We get this
> > error,
> > > but also a few other test failures which apparently should not happen.
> > > Those come from beans in transitive dependency projects like
> > > openejb-itests-beans.
> > > It passes in my IDE since there the classpath is different...
> > > Any idea what happened?
> > > LieGrue,strub
> > >
> >

Re: completely weird unit test failure

[Romain Manni-Bucau]

Mark

Previous test issue can be due to xbean upgrades or scanning changes, did
you check that? We tend to link implicitly the finder for these tests but
can have been broken at some point.

Le mar. 15 mai 2018 23:16, Mark Struberg  a
écrit :

>  fb_tomee8
> I've fixed this now by fixing the broken bean. Wonder how this could have
> ever worked.Might also be partly random due to different build order?
>
> But now I'm off to the next bug.
> EarModuleNamesTest
> This one also scans for a resource due to haing the openejb-itests-beans
> on the classpath.But since the config is done manually it misses the TxMgr
> setup, which is null.
> I exclude this test for now and want to see how far I come with the other
> tests.
> LieGrue,strub
>
> On Tuesday, 15 May 2018, 22:03:03 CEST, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>  Which branch?
>
> Jon
>
> On Tue, May 15, 2018 at 9:51 PM, Mark Struberg 
> wrote:
>
> >  Well, this looks weird anyhow
> > @Stateless
> > public class AnnotatedFieldInjectionStatefulBean {
> >
> > compare the name and the annotation
> > And the additional error messages
> are:org.apache.openejb.config.ValidationWarning:
> > @Init is ignored for beans of type Stateless.  Class:
> > org.apache.openejb.test.stateful.AnnotatedFieldInjectionStatefulBean
> > Method: create"
> > "org.apache.openejb.config.ValidationWarning: @Remove is ignored for
> > beans of type Stateless.  Class: org.apache.openejb.test.stateful.
> > AnnotatedFieldInjectionStatefulBean Method: remove""
> >
> > Well, yes, true!
> > Is this a negative test bean? ^^
> >
> >On Tuesday, 15 May 2018, 21:48:26 CEST, Mark Struberg
> >  wrote:
> >
> >  hi folks!
> > I get 2 unit test failures which look completely weird to me.Plus they
> > pass in the IDE but fail in mvn.
> > ERROR] Failures:
> > [ERROR]  CheckDescriptorLocationTest.testWarWithDescriptorInMetaInf Keys
> > do not match expected:<...or.incorrectLocation[]> but
> > was:<...or.incorrectLocation[
> > ignoredMethodAnnotation
> > ignoredMethodAnnotation]>
> > [ERROR]  CheckDescriptorLocationTest.testWarWithDescriptorInRoot Keys do
> > not match expected:<...or.incorrectLocation[]> but
> > was:<...or.incorrectLocation[
> > ignoredMethodAnnotation
> > ignoredMethodAnnotation]>
> >
> >
> > The unit test in question is
> > org.apache.openejb.config.CheckDescriptorLocationTest#
> > testWarWithDescriptorInRoot
> > This bundles a single FooBean.class with a single error.We get this
> error,
> > but also a few other test failures which apparently should not happen.
> > Those come from beans in transitive dependency projects like
> > openejb-itests-beans.
> > It passes in my IDE since there the classpath is different...
> > Any idea what happened?
> > LieGrue,strub
> >
>

Re: Status of TomEE 8

[Romain Manni-Bucau]

It is in since yesterday

Le 5 mai 2018 15:53, "Matthew Broadhead" <matthew.broadh...@nbmlaw.co.uk> a
écrit :

> i saw MyFaces 2.3.1 was released.  will that get update in 8.0?
>
>
> On 05/05/18 14:18, Romain Manni-Bucau wrote:
>
>> We didnt upgrade the api yet and still uses validation 1.1
>>
>> Le 5 mai 2018 13:03, "cocorossello" <cocorosse...@gmail.com> a écrit :
>>
>> Hi,
>>>
>>> I just noticed that javax.validation.ClockProvider and some methods
>>> related
>>> to bean validation api 2.0 are missing in javaee-api-8.0-SNAPSHOT  (I'm
>>> using it with hibernate-validator 6.0).
>>>
>>> Is it an error?
>>>
>>> Thanks,
>>> Vicente.
>>>
>>>
>>>
>>> --
>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
>>> f982480.html
>>>
>>>
>

Re: Status of TomEE 8

[Romain Manni-Bucau]

We didnt upgrade the api yet and still uses validation 1.1

Le 5 mai 2018 13:03, "cocorossello"  a écrit :

> Hi,
>
> I just noticed that javax.validation.ClockProvider and some methods related
> to bean validation api 2.0 are missing in javaee-api-8.0-SNAPSHOT  (I'm
> using it with hibernate-validator 6.0).
>
> Is it an error?
>
> Thanks,
> Vicente.
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> f982480.html
>

Re: TomEE 7.1.x with Microprofile

[Romain Manni-Bucau]

guess we can just use the master release note since the last release and
drop the spec N+1 items no?
+1 to get it merged (I'd appreciate if Mark can give a shot before since it
is a big one but looked ok and well working on my side)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-05-04 12:11 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> I took the approach Romain suggested, but I completely agree with the JIRA
> for release notes, so I'll get those sorted out. Thanks Mark!
>
> Jon
>
> On Fri, May 4, 2018 at 11:06 AM, Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
>
> > Hell yes, this damn GitHub PRs. Totally splits the communities.
> > Either it spams us or we loose information :(
> >
> > I'm all for keeping our stuff on JIRA and our own mailing lists.
> >
> > Will look at it and apply it.
> > We need JIRA tickets nonetheless. Otherwise we cannot craft any release
> > notes.
> >
> > What I did for OWB-1.7.5 is to just add this version to the original
> > tickets.
> > So if you only backported existing JIRA tickets, then please do me a
> > favour and add the 1.0.1 version to them.
> >
> > txs and LieGure,
> > strub
> >
> > > Am 04.05.2018 um 12:02 schrieb Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>:
> > >
> > > Here's the PR for reference: https://github.com/apache/johnzon/pull/21
> > >
> > > Romain gave it a thumbs-up. I'll try and get those JIRA references
> today.
> > >
> > > Jon
> > >
> > > On Fri, May 4, 2018 at 11:00 AM, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > >> I submitted a PR for Johnzon, and owe some JIRA references. I don't
> > think
> > >> it has been merged yet. I'm definitely not expecting you or Romain to
> do
> > >> the work alone. Thanks for the OWB releases!
> > >>
> > >> Jon
> > >>
> > >> On Fri, May 4, 2018 at 10:43 AM, Mark Struberg
> > <strub...@yahoo.de.invalid>
> > >> wrote:
> > >>
> > >>> Folks, can we FIRST focus on getting TomEE-7.0.5 done?
> > >>>
> > >>> We agreed that we FIRST do 7.0.5, and only THEN ship TomEE-7.1 in a
> > >>> branch and move TomEE8 to master.
> > >>>
> > >>> I've now released OWB-1.7.5, next up is Johnzon-1.0.1.
> > >>> Are all the fixes for Johnzon already applied and all the patches
> > >>> shipped? I've not seen them yet. And Romain and I cannot do all the
> > work
> > >>> alone. Or rather it will take a bit time then.
> > >>> And the last puzzle part is OpenJPA-2.4.3 and 3.0.0.
> > >>>
> > >>> So please less talking, more hacking.
> > >>>
> > >>> txs and LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>>On Wednesday, 2 May 2018, 07:07:54 CEST, Romain Manni-Bucau <
> > >>> rmannibu...@gmail.com> wrote:
> > >>>
> > >>> Just take this one:
> > >>>
> > >>> "
> > >>> Of course having a TomEE-7.1 which bumps the requirement to java8 is
> > cool.
> > >>> And I fully support that.
> > >>> "
> > >>>
> > >>> Not at all "I fully support TomEE 7.1 for MP".
> > >>>
> > >>> Don't get me wrong, I'm not against 7.1, I even proposed something
> very
> > >>> closed months ago (before we got the 8 branch) but I'm against
> > creating a
> > >>> branch and play with the versioning policy until we can justify it by
> > >>> something affecting users+being justified technically.
> > >>> I don't think we got here yet.
> > >>> Take it as "how would it affect users?"+"how does it affects us?".
> > First
> > >>> answer is clearly "no impact" - we  are already in prod with j8 - and
> > last
> > >>> one is pretty much the same technically AFAIK.
> > >>>
> > >>>
> > >>>
> > >>> Romain Manni-Bucau
> > >>>

Re: [RESULTS] Merge Pull Request 123 - MicroProfile JWT support

[Romain Manni-Bucau]

http://tomee.apache.org/community/sources.html

side note: github is just a proxy for us until we migrate to gitbox which
is ~basically an asf repo on github.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-05-02 15:20 GMT+02:00 Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk
>:

> sorry for the newb question but are there instructions on how to build
> 7.0.5? (mainly repo root location).  there is this
> http://tomee.apache.org/dev/building-from-source.html but we are using
> github now?
>
>
>
> On 22/04/18 20:50, Romain Manni-Bucau wrote:
>
>> Hi guys,
>>
>> We didn't discuss much the PR technically because there were more
>> important
>> topic to discuss and we therefore never hit the technical point but
>> since it has been merged 7 days ago there is no activity at all on that
>> code and it has a few blockers/downsides:
>>
>> 1. we don't build anymore because code uses java 8 and master (coming
>> 7.0.5) must still be java 7 from what we discussed - so we don't have
>> snapshots anymore
>> 2. we don't build anymore because the merged PR is wrongly setup (copy
>> paste from bval tck module for the suite which leads to a failing surefire
>> launching)
>> 3. the mp-jwt module is not setup to be tested (linked to 2) so we
>> actually
>> don't have any coverage for that which doesn't enable us to release it yet
>> 4. (this one is not blocking) the code is not fully ready to be released
>> (the config is hardcoded in
>> https://github.com/apache/tomee/blob/master/mp-jwt/src/main/
>> java/org/apache/tomee/microprofile/jwt/config/JWTAuthContext
>> InfoProvider.java#L33),
>> some @WebFilter should be removed to avoid to have twice the same filter
>> etc...
>>
>> Personally I'm quite keen to drop it from master and keep the work on
>> fb_tomee8 to be able to release a 8.0.0 ASAP. It drops the java 8 issue
>> and
>> the maven toolchain setup requirement.
>> Then we have two options:
>>
>> A. drop that code and use geronimo-jwt-auth-impl
>> B. make this code release ready (integrated to tomee config probably +
>> cleaned up)
>>
>> I indeed prefer A for consistency but you can go B if you want, most
>> important is to fix 1.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-
>> high-performance>
>>
>>
>> 2018-04-10 14:41 GMT+02:00 Richard Monson-Haefel <monsonhae...@gmail.com
>> >:
>>
>> Good to see the process work!
>>>
>>> On Mon, Apr 9, 2018 at 9:12 PM David Blevins <david.blev...@gmail.com>
>>> wrote:
>>>
>>> Officially closing the vote.  Thanks for the patience everyone.  This one
>>>> needed some good discussion and a bit of extra time.
>>>>
>>>> +1s
>>>> Andy Gumbrecht
>>>> Bruno Baptista
>>>> David Blevins
>>>> Gurkan Erdogdu
>>>> Ivan Junckes Filho
>>>> Jean-Louis Monteiro
>>>> Jonathan Gallimore
>>>> Otávio Gonçalves de Santana
>>>> Richard Monson-Haefel
>>>> Rudy De Busscher
>>>> Thiago Veronezi
>>>>
>>>> 0s
>>>> Matthew Broadhead
>>>>
>>>> -1s
>>>> Romain Manni-Bucau
>>>>
>>>> Vote passes with eleven +1s, one 0, and one -1.  Though this is a
>>>> technical vote and a -1 would normally veto, after long discussion here
>>>>
>>> and
>>>
>>>> a short follow up with the board, all involved agree the -1 is not a
>>>> true
>>>> technical veto and not binding.  Guidance from the board was to use a -0
>>>>
>>> on
>>>
>>>> technical votes if the intent is not to veto.  I think it would be good
>>>>
>>> for
>>>
>>>> us to be extra clear if a vote is a technical vote vs consensus.
>>>>
>>>> Though it to

Re: TomEE 7.1.x with Microprofile

[Romain Manni-Bucau]

Just take this one:

"
Of course having a TomEE-7.1 which bumps the requirement to java8 is cool.
And I fully support that.
"

Not at all "I fully support TomEE 7.1 for MP".

Don't get me wrong, I'm not against 7.1, I even proposed something very
closed months ago (before we got the 8 branch) but I'm against creating a
branch and play with the versioning policy until we can justify it by
something affecting users+being justified technically.
I don't think we got here yet.
Take it as "how would it affect users?"+"how does it affects us?". First
answer is clearly "no impact" - we  are already in prod with j8 - and last
one is pretty much the same technically AFAIK.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-05-02 0:42 GMT+02:00 David Blevins <david.blev...@gmail.com>:

> Could I ask for an off-topic personal favor?  Sometimes your email replies
> come with no quoting at all and the only way to find your words is to read
> both the old and new emails and do a mental diff.
>
> I've been tested a few times for dyslexia and don't have it, but my
> reading speed is very impaired regardless.  If you can help me by taking
> care to ensure there is proper quoting, I'd be deeply appreciative.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On May 1, 2018, at 2:37 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> >
> > Le 1 mai 2018 23:08, "David Blevins" <david.blev...@gmail.com> a écrit :
> >
> > We can certainly continue discussing, but there have been 7.1 discussions
> > including people like Rudy, Jean-Louis and Jonathan volunteering on list
> to
> > work on a 7.1.  Mark raising some questions and chiming in with "I fully
> > support that."
> >
> >
> > This is likely reading only the part you wanted ;). Mark always put some
> > conditions to that, JL doesnt care much from what i read and to play the
> > same "finger in the wind" game I think Rudy - correct me if Im wrong -
> > would support any technical solution leading to a mp distro.
> >
> >
> > This is finger-in-the-wind observation of positive response and certainly
> > there is still room for other feedback.
> >
> > What would you recommend we do from here?
> >
> >
> > First we need to clearly state what is the difference between a 7.1 and
> 8.
> > All i read was a half baked 8 (so 8 from our last months discussions) or
> a
> > 7+mp which doesnt work if we want to do a 7+some ee 8. MP not driving
> tomee
> > by design (and it is good), it shouldnt imply any versioning to stay
> > consistent for end users.
> >
> > Technically we can do a mp distro on tomee 7.0 (using toolchain) and/or
> > tomee 8.0 (natively).
> >
> > Keep in mind it is as minor for the project as the plume distro - we can
> > even do a "all permutations distro" update on 7.0 and 8.0. It is far to
> > modify the project nature, goal or codebase.
> >
> > Once we know what we want to bring then we can go through the standard
> > process of a vote if people disagree or just move forward.
> >
> >
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> >> On May 1, 2018, at 1:04 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> > wrote:
> >>
> >> Which leads to the same David, no?
> >> There is no decision taken and no real argument - before your mail -
> for a
> >> 7.1.
> >> Either there are too much off list discussions or we should better
> handle
> >> thread outcomes cause ATM, if you follow the list, discussions and acts
> > are
> >> not consistent :(.
> >>
> >> Le 1 mai 2018 21:24, "David Blevins" <david.blev...@gmail.com> a écrit
> :
> >>
> >> I've only ever seen feedback of the nature that if people were willing
> to
> >> do the extra 7.1 work in addition to the TomEE 8 work, it wasn't a
> > problem.
> >>
> >> Note, just got off the MicroProfile hangout and there we've proposed to
> >> doing both a MicroProfile 1.4 and MicroProfile 2.0 release on June 6th.
> >> The release contents would be the same with the exception of the minim

Re: TomEE 7.1.x with Microprofile

[Romain Manni-Bucau]

Which leads to the same David, no?
There is no decision taken and no real argument - before your mail - for a
7.1.
Either there are too much off list discussions or we should better handle
thread outcomes cause ATM, if you follow the list, discussions and acts are
not consistent :(.

Le 1 mai 2018 21:24, "David Blevins" <david.blev...@gmail.com> a écrit :

I've only ever seen feedback of the nature that if people were willing to
do the extra 7.1 work in addition to the TomEE 8 work, it wasn't a problem.

Note, just got off the MicroProfile hangout and there we've proposed to
doing both a MicroProfile 1.4 and MicroProfile 2.0 release on June 6th.
The release contents would be the same with the exception of the minimum
Java EE version; 1.4 will remain at Java EE 7 and MicroProfile 2.0 will be
Java EE 8.  Work would probably shift to MicroProfile 2.x afterwards,
though future MicroProfile 1.x releases could happen if component specs
want to continue to cater to Java EE 7 or don't have any Java EE dependency
at all.  That means MicroProfile will officially have two streams:

 - MicroProfile 1.x, Java EE 7, (potential TomEE 7.1)
 - MicroProfile 2.x, Java EE 8/Jakarta EE 8, TomEE 8


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Apr 30, 2018, at 7:55 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> Hmm, can have missed something but didnt the outcome of the thread have
> been to work in tomee 8 branch (always better to avoid merges ;))?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
ee-8-high-performance>
>
> 2018-04-30 16:34 GMT+02:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:
>
>> Hi community,
>>
>> I have created a branch based on current master (aka TomEE 7.0.x) as
>> discussed a while back.
>>
>> I have backported the microprofile JWT work from TomEE 8 branch.
>> The branch is https://github.com/jeanouii/tomee/tree/microprofile_
backport
>> I have pushed what I have currently in there. I'll need to test more
>> deeply.
>>
>> JLouis
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>

Re: TomEE 7.1.x with Microprofile

[Romain Manni-Bucau]

Hmm, can have missed something but didnt the outcome of the thread have
been to work in tomee 8 branch (always better to avoid merges ;))?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-30 16:34 GMT+02:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:

> Hi community,
>
> I have created a branch based on current master (aka TomEE 7.0.x) as
> discussed a while back.
>
> I have backported the microprofile JWT work from TomEE 8 branch.
> The branch is https://github.com/jeanouii/tomee/tree/microprofile_backport
> I have pushed what I have currently in there. I'll need to test more
> deeply.
>
> JLouis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: [VOTE] Release Apache OpenWebBeans-1.7.5

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-28 15:30 GMT+02:00 Daniel Cunha <daniels...@apache.org>:

> +1
>
> 2018-04-28 9:10 GMT-03:00 Mark Struberg <strub...@yahoo.de.invalid>:
>
> > Hi folks!
> >
> > I did run all required tasks for shipping an OWB-1.7.5 release.
> > This version targets CDI-1.2 / EE7 and would fit for the TomEE-7.x line.
> >
> > The following tickets got resolved
> >
> > Bug
> >
> > • [OWB-1197] - OwbSWClassLoader creates wrong URL
> > • [OWB-1205] - We should not fire ProcessInjectionPoint for CDI
> > Extension Observers
> > • [OWB-1209] - Custom bean with isAlternative()=true should not
> be
> > automatically enabled
> > • [OWB-1213] - producer of URI or other classes with private ct
> > blow up with a NPE
> > • [OWB-1222] - subclass proxy fails with Java9
> >
> > Improvement
> >
> > • [OWB-1218] - improve toString of producer beans to also log
> > owner class
> > Task
> >
> > • [OWB-1239] - update owb-1.7.x to java7
> > • [OWB-1240] - Non-static inner classes should not get picked up
> > as CDI Beans
> >
> > Dependency upgrade
> >
> > • [OWB-1236] - Update to XBean Asm 6 Shaded 4.7
> > • [OWB-1237] - upgrade to xbean-4.8
> >
> > The source tag is -r1830409
> > https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.7.5/
> >
> >
> > The release staging repository can be found here:
> >
> > https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1040/
> >
> > The source binary is in
> > https://repository.apache.org/content/repositories/
> > orgapacheopenwebbeans-1040/org/apache/openwebbeans/openwebbeans/1.7.5/
> > It's sha1 is ddcf865490468e4e782fd596b815be9824ffe232
> >
> > I've used my standard sig and key.
> >
> >
> > Please VOTE:
> >
> > [+1] let's ship it
> > [+0] meh, don't care
> > [-1] stop there is a ${showstopper}
> >
> > The VOTE is open for 72h.
> >
> > txs and LieGrue,
> > strub
> >
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: tomee site slogan

[Romain Manni-Bucau]

"The swiss knife server"?

We should probably avoid "enterprise tomcat" since it means something else
in the industry - but we can say "enterprised server" if we want to play on
words :).

You are right, speaking of embedded/remote/standalone doesnt make much
sense here.

Le 27 avr. 2018 23:02, "David Jencks"  a écrit :

> I agree with Ivan.
>
> David Jencks
>
> > On Apr 27, 2018, at 1:59 PM, Ivan Junckes Filho 
> wrote:
> >
> > I agree with Mark and +1 to Dani's description.
> >
> > On Fri, Apr 27, 2018 at 5:34 PM, Mark Struberg  >
> > wrote:
> >
> >> Also fine.
> >> It's just the 'Remote EE Server' which is kind of weird ;)
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 27.04.2018 um 22:32 schrieb Daniel Cunha :
> >>>
> >>> I'll prefer something like:
> >>> "The Embedded or Standalone Enterprise Tomcat Server"
> >>>
> >>> 2018-04-27 17:19 GMT-03:00 Mark Struberg :
> >>>
>  Hi folks!
> 
>  I really like the new TomEE site.
> 
>  Just one thing which we might want to improve:
>  The main slogan currently says
>  "The Embedded or Remote EE Application Server"
> 
>  Trust me, reading "Remote EE Application Server" doesn't give people a
>  good feeling ;)
>  This reminds me a bit too much about Remote EJBs...
> 
> 
>  What about the following:
>  "The Embedded or Standalone Tomcat Server on Enterprise Stereoides"
> 
>  ?
> 
>  LieGrue,
>  strub
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Daniel "soro" Cunha
> >>> https://twitter.com/dvlc_
> >>
> >>
>
>

Re: TomEE-7.0.5 work

[Romain Manni-Bucau]

We are working with Mark on a release train soon, johnzon would be part of
it probably.
An OWB release is needed too AFAIK and is on its way.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-27 14:43 GMT+02:00 Alex The Rocker <alex.m3...@gmail.com>:

> Hello TomEE developers,
>
> I was away for a while, and I'm a bit lost on the TomEE 7.0.5 upcoming
> release plans:
> - Jon did a great job with PR for upcoming Johnzon 1.0.1, but as far
> as I see, Johnzon 1.0.1 is still not released
> - What else would prevent TomEE 7.0.5 from being released?
>
> As usual I volunteer for running heavy tests on any preview...
>
> Best regards,
> Alexandre
>
>
> 2018-04-16 8:25 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > 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" <strub...@yahoo.de.invalid> 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.uti

Re: Issue with local lookups between 2 different ears deployed in same TomEE instance

[Romain Manni-Bucau]

Hi Dignesh

Normally if you dont have a local (or local bean) interface we
automatically do a "classloader copy" which means if the same api classes
are in both ears it should work.



Le 23 avr. 2018 06:44, "Dignesh"  a écrit :

Hi,

I am using 7.0.2 TomEE. I have 2 ears (A.ear and B.ear) .As both apps share
the same jvm, I am doing a local look up of bean deployed in EAR B from Ear
A .I am seeing the class cast exceptions.
Remote look ups work fine. Just to avoid the RMI overhead , I dont want to
use Remote lookup. Is there any configuration setting through which we can
enable the local lookups between 2 ears deployed in same jvm /tomee
instance.

Thank you.
Dignesh



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: [RESULTS] Merge Pull Request 123 - MicroProfile JWT support

[Romain Manni-Bucau]

Hi guys,

We didn't discuss much the PR technically because there were more important
topic to discuss and we therefore never hit the technical point but
since it has been merged 7 days ago there is no activity at all on that
code and it has a few blockers/downsides:

1. we don't build anymore because code uses java 8 and master (coming
7.0.5) must still be java 7 from what we discussed - so we don't have
snapshots anymore
2. we don't build anymore because the merged PR is wrongly setup (copy
paste from bval tck module for the suite which leads to a failing surefire
launching)
3. the mp-jwt module is not setup to be tested (linked to 2) so we actually
don't have any coverage for that which doesn't enable us to release it yet
4. (this one is not blocking) the code is not fully ready to be released
(the config is hardcoded in
https://github.com/apache/tomee/blob/master/mp-jwt/src/main/java/org/apache/tomee/microprofile/jwt/config/JWTAuthContextInfoProvider.java#L33),
some @WebFilter should be removed to avoid to have twice the same filter
etc...

Personally I'm quite keen to drop it from master and keep the work on
fb_tomee8 to be able to release a 8.0.0 ASAP. It drops the java 8 issue and
the maven toolchain setup requirement.
Then we have two options:

A. drop that code and use geronimo-jwt-auth-impl
B. make this code release ready (integrated to tomee config probably +
cleaned up)

I indeed prefer A for consistency but you can go B if you want, most
important is to fix 1.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-10 14:41 GMT+02:00 Richard Monson-Haefel <monsonhae...@gmail.com>:

> Good to see the process work!
>
> On Mon, Apr 9, 2018 at 9:12 PM David Blevins <david.blev...@gmail.com>
> wrote:
>
> > Officially closing the vote.  Thanks for the patience everyone.  This one
> > needed some good discussion and a bit of extra time.
> >
> > +1s
> > Andy Gumbrecht
> > Bruno Baptista
> > David Blevins
> > Gurkan Erdogdu
> > Ivan Junckes Filho
> > Jean-Louis Monteiro
> > Jonathan Gallimore
> > Otávio Gonçalves de Santana
> > Richard Monson-Haefel
> > Rudy De Busscher
> > Thiago Veronezi
> >
> > 0s
> > Matthew Broadhead
> >
> > -1s
> > Romain Manni-Bucau
> >
> > Vote passes with eleven +1s, one 0, and one -1.  Though this is a
> > technical vote and a -1 would normally veto, after long discussion here
> and
> > a short follow up with the board, all involved agree the -1 is not a true
> > technical veto and not binding.  Guidance from the board was to use a -0
> on
> > technical votes if the intent is not to veto.  I think it would be good
> for
> > us to be extra clear if a vote is a technical vote vs consensus.
> >
> > Though it took a while to talk this one out and the vote is not
> unanimous,
> > it is good to see the discussion and high turnout.  I think this reflects
> > us using muscles we haven't used in a while and is an overall incredibly
> > positive thing.
> >
> > Thanks to everyone who voted and participated in the community
> discussion!
> >
> >
> > -David
> >
> > > On Mar 18, 2018, at 5:02 PM, David Blevins <david.blev...@gmail.com>
> > wrote:
> > >
> > > Jean-Louis has put a PR up for discussion for JWT Support in TomEE.
> > >
> > > - https://github.com/apache/tomee/pull/123
> > >
> > > There are 35 commits spanning 27 days of work.  It's been reviewed by
> > Andy and Rudy.  One a committer and one a contributor, which is great for
> > us.
> > >
> > > There's an open question as to where the code should live in its final
> > state: TomEE or Geronimo.  This conversation doesn't seem conclusive
> after
> > 12 days.  It's ok for us not to agree, but we should have more votes so
> > there is a clear outcome and we are acting as a community to our best
> > ability.
> > >
> > > Vote: Merge Pull Request 123?
> > >
> > > +1  Yes, let's do it
> > > +-0 Abstain
> > > -1  No, don't put this code in TomEE
> > >
> > >
> > > Out of respect for the conversation, this is not a vote of where the
> > code will live in its final state.  This is just a decision to merge or
> > not.  It would give the users something they can try, which can be
> updated
> > by a future PR if the code does eventually move.
> > >
> > >
> > > -David
> > >
> >
> >
>

Re: MP.next()

[Romain Manni-Bucau]

Le 19 avr. 2018 20:47, "Mark Struberg"  a écrit :

Heh that was nicely put and I do certainly agree with your finding ;)

@Romain, the 7.1 was just 7.0.x + java8 bump and MP.


I got that but not its need.


Of course I have no clue who will use EE7 with MP, if he can have EE8 as
well...
All I wanted is to make a clear disctinction between TomEE with Java7 and
TomEE which requires Java8 - thus the required bump to 7.1.x.


Hmm, technically we know how to do a 7.0 with a mp distro (all but mp on
java 7).


Im not against a 7.1 but if it only brings 10% of a MP distro im not
convinced it is wise to do it. Writing I even wonder if MP justifies a
minor bump.

Our online versioning policy references minor as a feature level marker. MP
distro doesnt bring any feature to most tomee users - as well as just a
java min version bump - so arent we too enthusiast here?

The important thing to keep in mind is users, not tech choices.

Just my 2cts indeed


LieGrue,
strub


> Am 19.04.2018 um 13:23 schrieb Rudy De Busscher :
>
> If needed, I can lend a hand in updating TomEE 7.1
>
> But I agree, certification becomes less an issue.I have the impression
> that  even Big vendors don't set it as a priority.
>
> Rudy
>
> On 19 April 2018 at 11:24, Mark Struberg 
wrote:
>
>> Of course having a TomEE-7.1 which bumps the requirement to java8 is
cool.
>> And I fully support that.
>> But right now let's please focus on shipping TomEE-7.0.5 first.
>> Most probably 7.1 could be done almost in parallel.
>> But we do not have endless resources. At least I don't.
>>
>> LieGrue,
>> strub
>>
>>> Am 19.04.2018 um 05:25 schrieb David Blevins :
>>>
>>>
 On Apr 18, 2018, at 4:08 AM, Mark Struberg 
>> wrote:

 There was a discussion about this a few weeks ago where we agreed to
>> ship TomEE-7.0.5 and only then switch to a branch.

 That's the reason why we backported tons of stuff in Johnzon, OWB and
>> OpenJPA.
 Just waiting for feedback whether it now works fine or if there is
>> still something broken.

 So my suggestion is to apply this to the TomEE8 branch and wait with
>> the other PR until TomEE-7.0.5 is released.
>>>
>>> Kicked off a proper "Status of TomEE 8" thread so we can have a full
>> conversation on what to do with TomEE 8.
>>>
>>> If people were willing to put the effort into a TomEE 7.1 in addition to
>> whatever is decided in that thread, would you be ok with a TomEE 7.1 as
>> well?
>>>
>>> For context: I know Jean-Louis is heading off to Brazil in May to do a
>> TomEE talk that shows his JWT work.  Ideally he's not showing a snapshot
>> and people could leave with something they can try.  He's doing that talk
>> again in June.
>>>
>>> My personal perspective is if the decision was made to release TomEE 8
>> now, I'd still see value in a 7.1 release with MicroProfile as then the
>> users would have the choice.  Some may not want to do a Java EE 7 to Java
>> EE 8 upgrade, but still want to enjoy some MicroProfile technologies.
>>>
>>>
>>> -David
>>>
>>>
>>>
>>
>>

Re: Status of TomEE 8

[Romain Manni-Bucau]

+1 for a next week release, no need of M1 or whatever marker in the name,
just 8.0.0 is fine IMHO.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-19 12:35 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> How about an April release of a TomEE 8 Milestone 1?
>
> Jon
>
> On Thu, Apr 19, 2018 at 4:10 AM, David Blevins <david.blev...@gmail.com>
> wrote:
>
> > > On Apr 17, 2018, at 9:57 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> > >
> > > What is blocking to release tomee 8? Nothing ;)
> >
> > Moving this over as it's probably a good "top level" topic to discuss.
> > This will probably come to do "do we care about certification anymore"
> and
> > that will probably involve us asking users for their opinions.
> >
> > Here's the status I'm aware of from my involvement in Jakarta EE / EE4J
> > PMC.
> >
> >   - TCKs are due to show up in the May, June timeframe.  Once they show
> > up, we will be able to legally run them.  I.e. after 5 years our TCK
> access
> > will finally be restored.
> >
> >   - Jakarta EE 8 TCK will be an functionally identical copy of the Java
> EE
> > 8 TCK.  This is intentional so being Jakarta EE 8 certified can be
> implied
> > to be Java EE 8 certified.
> >
> >   - As this one will be open source, we will all be able to work on it
> > together, openly without special paperwork.  We will also be able to
> openly
> > share the results and talk about how close or far we are and do we want
> to
> > release then or wait.
> >
> > So I see three options:
> >
> >  a) April - Release TomEE 8.x now with unknown compliance
> >  b) July - Run the Jakarta EE 8.x TCK, potentially release with known
> > non-compliance and information on what isn't compliant
> >  c) September - Time-box closing as many issues as possible, fix what we
> > can in 2 months and release with known non-compliance, but far less, and
> > information on what isn't compliant
> >  d) ?? - Release TomEE 8.x when it is Jakarta EE 8 Web Profile compliant
> >
> > I don't mention the 8.0 vs 8.1 distinction because I don't think it adds
> > anything to the conversation.  Whenever we do our first release it would
> be
> > called 8.0, it's really about when we want to do that.  I think we're all
> > on the same page that if we did release 8.0 now, we'd increment the
> version
> > in some way on milestones C or D.
> >
> > I won't give my preference in this email as to not pollute the options.
> > If you see an option that isn't discussed, do the same and attempt to
> > present it disconnected from your preference (i.e. use different emails).
> >
> > We should probably discuss for a while, capture some options we like,
> then
> > loop in users and try to get as much feedback as possible.  Maybe a
> google
> > poll.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> >
>

Re: MP.next()

[Romain Manni-Bucau]

Hmm,

I don't get the rational of having a 7.x with that. Any reason?
Technically TomEE 8 is way more ready to release than TomEE 7.1 ;).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-19 12:00 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Right now we have JL's change in master as well as TomEE 8. I'm happy to
> try and find time to release both. However, I think we're inching very
> close with TomEE 7.0.5, so does anyone mind if I create the 7.1 branch, and
> shift JL's JWT work there, and take it out of master (7.0.5)?
>
> Jon
>
> On Thu, Apr 19, 2018 at 10:24 AM, Mark Struberg <strub...@yahoo.de.invalid
> >
> wrote:
>
> > Of course having a TomEE-7.1 which bumps the requirement to java8 is
> cool.
> > And I fully support that.
> > But right now let's please focus on shipping TomEE-7.0.5 first.
> > Most probably 7.1 could be done almost in parallel.
> > But we do not have endless resources. At least I don't.
> >
> > LieGrue,
> > strub
> >
> > > Am 19.04.2018 um 05:25 schrieb David Blevins <david.blev...@gmail.com
> >:
> > >
> > >
> > >> On Apr 18, 2018, at 4:08 AM, Mark Struberg <strub...@yahoo.de.INVALID
> >
> > wrote:
> > >>
> > >> There was a discussion about this a few weeks ago where we agreed to
> > ship TomEE-7.0.5 and only then switch to a branch.
> > >>
> > >> That's the reason why we backported tons of stuff in Johnzon, OWB and
> > OpenJPA.
> > >> Just waiting for feedback whether it now works fine or if there is
> > still something broken.
> > >>
> > >> So my suggestion is to apply this to the TomEE8 branch and wait with
> > the other PR until TomEE-7.0.5 is released.
> > >
> > > Kicked off a proper "Status of TomEE 8" thread so we can have a full
> > conversation on what to do with TomEE 8.
> > >
> > > If people were willing to put the effort into a TomEE 7.1 in addition
> to
> > whatever is decided in that thread, would you be ok with a TomEE 7.1 as
> > well?
> > >
> > > For context: I know Jean-Louis is heading off to Brazil in May to do a
> > TomEE talk that shows his JWT work.  Ideally he's not showing a snapshot
> > and people could leave with something they can try.  He's doing that talk
> > again in June.
> > >
> > > My personal perspective is if the decision was made to release TomEE 8
> > now, I'd still see value in a 7.1 release with MicroProfile as then the
> > users would have the choice.  Some may not want to do a Java EE 7 to Java
> > EE 8 upgrade, but still want to enjoy some MicroProfile technologies.
> > >
> > >
> > > -David
> > >
> > >
> > >
> >
> >
>

Re: Status of TomEE 8

[Romain Manni-Bucau]

A) without hesitation. After years of feedbacks, our state is that we have
2 kinds of users:

- I dont care about the certification
- Certification is mandatory for me to look at what you do

Last category is clearly a subset of big companies and we lost them with EE
7 status so I think users just expect releases and moves.

It means release whatever you have and just clearly state what it is.

Side note: and we jakarta ee we can get back the second category but later.
However at least we still make category a happy in the meantime.

Le 19 avr. 2018 05:10, "David Blevins" <david.blev...@gmail.com> a écrit :

> On Apr 17, 2018, at 9:57 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> What is blocking to release tomee 8? Nothing ;)

Moving this over as it's probably a good "top level" topic to discuss.
This will probably come to do "do we care about certification anymore" and
that will probably involve us asking users for their opinions.

Here's the status I'm aware of from my involvement in Jakarta EE / EE4J PMC.

  - TCKs are due to show up in the May, June timeframe.  Once they show up,
we will be able to legally run them.  I.e. after 5 years our TCK access
will finally be restored.

  - Jakarta EE 8 TCK will be an functionally identical copy of the Java EE
8 TCK.  This is intentional so being Jakarta EE 8 certified can be implied
to be Java EE 8 certified.

  - As this one will be open source, we will all be able to work on it
together, openly without special paperwork.  We will also be able to openly
share the results and talk about how close or far we are and do we want to
release then or wait.

So I see three options:

 a) April - Release TomEE 8.x now with unknown compliance
 b) July - Run the Jakarta EE 8.x TCK, potentially release with known
non-compliance and information on what isn't compliant
 c) September - Time-box closing as many issues as possible, fix what we
can in 2 months and release with known non-compliance, but far less, and
information on what isn't compliant
 d) ?? - Release TomEE 8.x when it is Jakarta EE 8 Web Profile compliant

I don't mention the 8.0 vs 8.1 distinction because I don't think it adds
anything to the conversation.  Whenever we do our first release it would be
called 8.0, it's really about when we want to do that.  I think we're all
on the same page that if we did release 8.0 now, we'd increment the version
in some way on milestones C or D.

I won't give my preference in this email as to not pollute the options.  If
you see an option that isn't discussed, do the same and attempt to present
it disconnected from your preference (i.e. use different emails).

We should probably discuss for a while, capture some options we like, then
loop in users and try to get as much feedback as possible.  Maybe a google
poll.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Re: MP.next()

[Romain Manni-Bucau]

What is blocking to release tomee 8? Nothing ;)

Id keep it simple and avoid another maintenance branch.

Le 17 avr. 2018 23:49, "Jonathan Gallimore" 
a écrit :

> On Tue, 17 Apr 2018, 22:32 David Blevins,  wrote:
>
> > > On Apr 17, 2018, at 2:26 PM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > >
> > > Do we have a branch for it?
> > > Master is 7.x for Java 7
> >
> > Not sure how we want to run that.  One option is we could just switch
> > wherever 7x lives now to 7.1.
> >
> > If we really wanted to patch 7.0.x we could make a 7.0.x branch.
> >
> > Jon, I know you're doing a lot of Java 9 & 10 work.  Would you want to do
> > that in both a 7.1 and a 7.0.x or just a 7.1?
> >
>
> Good question. I'm fine with a 7.1 as well. The Java 9 and 10 stuff needs
> to happen in TomEE 8 as well of course, and I'd like to include 1.7.x as
> well as many people still use it.
>
> I appreciate that involves a lot of branches for the Java 9 and 10 work,
> but I'm happy to invest the time in that.
>
>
>
> > Certainly from a release announcement perspective, "TomEE 7.1 released
> > with MicroProfile and Java 10 support" is pretty catchy.
> >
>
> I agree.
>
>
> >
> > Preferences?
> >
> >
> > -David
> >
> > >
> > > On Tue, Apr 17, 2018 at 11:25 PM, David Blevins <
> david.blev...@gmail.com
> > >
> > > wrote:
> > >
> > >> Can we also create a TomEE 7.1?  I think everyone who +1ed was
> thinking
> > >> about something we could release sooner than TomEE 8.x.
> > >>
> > >>
> > >> --
> > >> David Blevins
> > >> http://twitter.com/dblevins
> > >> http://www.tomitribe.com
> > >>
> > >>> On Apr 17, 2018, at 1:55 PM, Jean-Louis Monteiro <
> > >> jlmonte...@tomitribe.com> wrote:
> > >>>
> > >>> Thanks guys.
> > >>> Yes I meant TomEE 8.x
> > >>>
> > >>> I have rework the MP-JWT contribution so the extension leaves into a
> > >>> different module than the TCK.
> > >>> The TCK is green for the MP-JWT.
> > >>>
> > >>> New PR is here https://github.com/apache/tomee/pull/130
> > >>> If you are ok, I will revert from current master the MP-JWT which
> > >> requires
> > >>> Java 8 and is therefor incompatible with TomEE 7.x
> > >>>
> > >>> On the TomEE 8.x branch, I'll create an example and push to the same
> > PR.
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Jean-Louis Monteiro
> > >>> http://twitter.com/jlouismonteiro
> > >>> http://www.tomitribe.com
> > >>>
> > >>> On Tue, Apr 17, 2018 at 8:05 PM, David Blevins <
> > david.blev...@gmail.com>
> > >>> wrote:
> > >>>
> >  +1
> > 
> > 
> >  --
> >  David Blevins
> >  http://twitter.com/dblevins
> >  http://www.tomitribe.com
> > 
> > > On Apr 16, 2018, at 4:11 PM, Jean-Louis Monteiro <
> >  jlmonte...@tomitribe.com> wrote:
> > >
> > > 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: 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
>

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

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

(Indeed) +1 from me and thanks Jon for the huge work. Will wait some other
member of the community review it since, as you mentionned, idea was coming
from me but happy to apply it after.

Le 15 avr. 2018 22:28, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

> Hi,
>
> This discussion originated on the TomEE dev@ list, but I think it is more
> appropriate that it continue here. Effectively I'm looking at trying to
> provide a 1.0.1 version of Johnzon that is at the the same API level as
> 1.0.0, but has all the fixes from master, that we can bundle with a TomEE 7
> release.
>
> I've opened up a PR here: https://github.com/apache/johnzon/pull/21, for
> discussion. I'll attempt to cross-reference this back to the JIRAs fixed
> over the next couple of days, but I'd welcome any feedback.
>
> Many thanks
>
> Jon
>
> On Sun, Apr 1, 2018 at 6:04 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Happy to try that. I'll give that a go this evening. I misunderstood your
> > proposal, but it makes sense now.
> >
> > Cheers
> >
> > Jo
> >
> > On 1 Apr 2018 17:41, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:
> >
> > What about my proposal? Take johnzon master, copy it over 1.0.x and
> > downgrade apis? It is probably the safest and shouldnt be long to make
> > work. Can help next week if needed.
> >
> > Le 1 avr. 2018 17:06, "Jonathan Gallimore" <jonathan.gallim...@gmail.com
> >
> > a
> > écrit :
> >
> > > Agreed. I'll start working on the list of fixes tonight.
> > >
> > > Jon
> > >
> > > On Sun, 1 Apr 2018, 16:02 Mark Struberg, <strub...@yahoo.de.invalid>
> > > wrote:
> > >
> > > > Of course I also want to ship a 7.0.5 (or 7.1.0 if we opt to up to
> > Java8
> > > > as min version).
> > > >
> > > > And I'd also happily volunteer to release Johnzon-1.0.1.
> > > >
> > > > BUT, first we need to check which Johnzon bugfixes are necessary to
> > > > backport!
> > > > Then let's create tickets for that version and solve them.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > > > Am 01.04.2018 um 16:50 schrieb Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com>:
> > > > >
> > > > > I think getting TomEE 8 out is obviously is preferred option. I
> would
> > > > still
> > > > > like to maintain TomEE 7 for those that want it. I'd be happy to go
> > > > through
> > > > > JIRA, and backport fixes as necessary for Johnzon 1.0.x.
> > > >
> > > >
> > >
> >
> >
> >
>

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

(Indeed) +1 from me and thanks Jon for the huge work. Will wait some other
member of the community review it since, as you mentionned, idea was coming
from me but happy to apply it after.

Le 15 avr. 2018 22:28, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

> Hi,
>
> This discussion originated on the TomEE dev@ list, but I think it is more
> appropriate that it continue here. Effectively I'm looking at trying to
> provide a 1.0.1 version of Johnzon that is at the the same API level as
> 1.0.0, but has all the fixes from master, that we can bundle with a TomEE 7
> release.
>
> I've opened up a PR here: https://github.com/apache/johnzon/pull/21, for
> discussion. I'll attempt to cross-reference this back to the JIRAs fixed
> over the next couple of days, but I'd welcome any feedback.
>
> Many thanks
>
> Jon
>
> On Sun, Apr 1, 2018 at 6:04 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Happy to try that. I'll give that a go this evening. I misunderstood your
> > proposal, but it makes sense now.
> >
> > Cheers
> >
> > Jo
> >
> > On 1 Apr 2018 17:41, "Romain Manni-Bucau" <rmannibu...@gmail.com> wrote:
> >
> > What about my proposal? Take johnzon master, copy it over 1.0.x and
> > downgrade apis? It is probably the safest and shouldnt be long to make
> > work. Can help next week if needed.
> >
> > Le 1 avr. 2018 17:06, "Jonathan Gallimore" <jonathan.gallim...@gmail.com
> >
> > a
> > écrit :
> >
> > > Agreed. I'll start working on the list of fixes tonight.
> > >
> > > Jon
> > >
> > > On Sun, 1 Apr 2018, 16:02 Mark Struberg, <strub...@yahoo.de.invalid>
> > > wrote:
> > >
> > > > Of course I also want to ship a 7.0.5 (or 7.1.0 if we opt to up to
> > Java8
> > > > as min version).
> > > >
> > > > And I'd also happily volunteer to release Johnzon-1.0.1.
> > > >
> > > > BUT, first we need to check which Johnzon bugfixes are necessary to
> > > > backport!
> > > > Then let's create tickets for that version and solve them.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > > > Am 01.04.2018 um 16:50 schrieb Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com>:
> > > > >
> > > > > I think getting TomEE 8 out is obviously is preferred option. I
> would
> > > > still
> > > > > like to maintain TomEE 7 for those that want it. I'd be happy to go
> > > > through
> > > > > JIRA, and backport fixes as necessary for Johnzon 1.0.x.
> > > >
> > > >
> > >
> >
> >
> >
>

Re: TomEE-7.0.5 work

[Romain Manni-Bucau]

I can probably deploy openjpa snapshot on monday if still needed but not
this week end.

Le 15 avr. 2018 07:16, "Alex The Rocker"  a écrit :

> Hello Jon,
>
> Sounds like very good news!
> I'm ready to run our real-life tests with any preview of Johnzon 1.0.1
> if it's compatible with current TomEE 7.0.4 (and of course I'll do the
> same when it'll be part of TomEE 7.0.5 preview/RC)
>
> Best regards,
> Alexandre
>
> 2018-04-14 23:43 GMT+02:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> > OpenJPA is pulling that in possibly... I submitted a PR to OpenJPA master
> > and 2.4.x which has been merged in - maybe a new snapshot deployment
> needed
> > there too.
> >
> > Also; I have worked on Johnzon porting from trunk to 1.0.x. Will submit a
> > PR for that tomorrow - just want to give it a final check.
> >
> > Jon
> >
> > On Sat, Apr 14, 2018 at 10:40 PM, Mark Struberg
> 
> > wrote:
> >
> >> Txs Jon!
> >> seems there is still a mixup between asm5 and 6 :(
> >> Will try to fix it tomorrow.
> >> LieGrue,strub
> >>
> >>
> >> On Saturday, 14 April 2018, 23:19:46 CEST, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >>
> >>  Thanks Mark! I'll run some tests and get back to you as soon as I can.
> >>
> >> Jon
> >>
> >> On Sat, Apr 14, 2018 at 10:16 PM, Mark Struberg
>  >> >
> >> wrote:
> >>
> >> > hi folks!
> >> > The messages got pretty much mixed up.So let's start a new thread to
> >> focus
> >> > on 7.0.5 tasks.
> >> > I've now backported tons of fixes in OWB and deployed an
> >> > OWB-1.7.5-SNAPSHOT.I've upgrade the version in our master pom.xml and
> >> also
> >> > upgraded xbean to 4.7.
> >> > Please test and provide feedback.If all looks fine then I can do an
> OWB
> >> > release.
> >> >
> >> > txs and LieGrue,strub
> >> >
> >>
> >>
>

Re: "Umbrella" discussion

[Romain Manni-Bucau]

Le 12 avr. 2018 23:24, "gilbertoca"  a écrit :

Guys, just a user here.

>From my experience, no one knows the Geronimo project[1] (for me it appears
a retired/dead one).
Everyone I talk with thinks everything is in TomEE (I thought like this
before).
Now, after read about the project in the mail-list (several discussion by
the way) I understand why the Geronimo project still exists. But it doesn't
change the general understanding, TomEE is the official Java EE
implementation on Apache Fundation.
I think the Geronimo site should be deactivated and the TomEE site, even
though is not official umbrella, should be changed to incorporate all
projects/sub-projects - like the spring portal[2]. It would show that the
Geronimo sub-projects are stronger and are empowering the TomEE engine.


If you do you kill subproject as not ee ones (we tried). We need to work on
the new geronimo identity but importing it in tomee is a known end for me.
Tomee users will not notice any diff (tomee is less than 5% of the apache
projects it uses and way less than geronimo code it includes).

I understand your point of view but this is also what killed geronimo as a
server.

Hope we can avoid to do it again ;)


Regards,

Gilberto

[1] http://geronimo.apache.org/
[2] https://spring.io/projects


agumbrecht wrote
> I agree with Roberto, that we can create a distinct area under the TomEE
> PMC. Now we have a firm name 'Jakarta EE', I think we should grab that
> by the horns in some way and run with it!
>
> I feel that 'anything' EE should not land in 'commons', but should be
> actively promoted as an EE component or library, even jakarta-[lib].
>
> As I mentioned in the TomEE MP thread already - We should act quickly.
> Yes, that may mean we cause ripples or waves in an unforeseen way, but
> we also need to keep the 'Apache' noise loud. Especially because Eclipse
> is on the leader board here. Anyway, nothing we do is cast in concrete.
>
> "We gave each other a lot of free space, which is why we stayed
> motivated to keep adding code there instead of keeping it in our
> projects" - It 'used' to be this way in TomEE, and it was fun. Between
> releases, what goes on in the repo is a playground - Kids should have
> fun in the playground until the bell rings.
>
> In fact, I'm feeling like getting in the playground again with MP and I
> think I will just get on with it, get some thick skin, and have fun. I
> will of course try and get more fun kids in the playground too, and if
> that gets me detention so be it :-P.
>
> Andy.
>
> On 27/02/18 15:33, Roberto Cortez wrote:
>>
>> Hi,
>> I'll +1 on:
>> 5.) Move the usable components to a disctinct area under the TomEE PMC,
>> but with a separate brand name. It should _not_ be TomEE components, but
>> something catchy
>>
>> Cheers,RobertoOn Sunday, February 25, 2018, 11:50:43 PM GMT, David
>> Blevins 

> david.blevins@

>  wrote:
>>
>>   Huge email, so if I don't respond to a point you were particularly
>> interested in, do let me know.  Adding some thoughts.
>>
>>> Again my argument:
>>>
>>>
>>> *) There should be a go-to place for such reusable enterprise parts at
>>> Apache. Like javamail, the tx-mgr, the specs, config, xbean, etc.
>>>
>>> *) We should keep the o.a.geronimo.specs groupId (would be tons of work
>>> for downstream projects to change it) and we cannot have multiple PMCs
>>> using this groupId and package name.
>>>
>>> *) Those reusable parts should have an own marketing name. We could
>>> reuse XBean or find a better one.
>>> Why? Geronimo is associated with a big and dead EE server, TomEE is
>>> associated with an alive EE server. Better, but not much.
>>> It should be clear that those reusable components are actually
>>> independent of each of the 3 projects.
>>>
>>> *) The reusablel parts each also have a separate livecycle.
>>>
>>> *) If we really shutdown Geronimo then all the active components should
>>> be moved to another project, the rest goes to the attic.
>>>
>>> *) I totally don't care which PMC does the organisatorial thing as long
>>> as it is active. That would be a plus for the TomEE PMC as it is
>>> reasonably more active. We did not even get enough +1 for the last votes
>>> over here. That's not making me happy.
>> I agree with the community perspective that having us all split into a
>> couple weak PMCs is not ideal.  I think we'd be stronger together.
>>
>> More reusable components released separately is a good way to keep build
>> times down.  There's a cost to that, so pragmatism is definitely
>> required.
>>
>> Some things are a couple lines of code.  Some things are a library in a
>> git repo.  Some things are their own repo, but not big enough for a PMC.
>> Some things need to be their own standalone project.
>>
>> The above said, they are all very subjective so what's really important
>> to me is that freedom still exist.
>>
>>   - I'm not a fan of seeing "you can't do x because y project owns it"
>>
>>   - I'm not a fan of 

Re: [RESULT] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

why -> for consistency accross our coupled communities
why does it matter if it is in G for T? -> it doesn't

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


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

Re: [RESULT] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

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 <matthew.broadh...@nbmlaw.co.uk>:
> Hi David,
>
> Thanks for the invitation to vote.  I don't want to vote because I am not
> sure I have enough knowledge to be able to do so.
>
> My gut feeling would probably be to side with Mark and Romain as they have
> been very supportive with my queries about TomEE and they have shown  deep
> technical knowledge about the inner workings.
>
> On the other hand I don't want to dismiss the excellent effort others are
> making on the JWT issue.  However as long as the code is reusable and finds
> a home it will not be wasted.
>
> I am still interested to know what Mark and Romain are looking for before
> they accept it into the project.  Does it need to have proven track record
> and reliability?  It is a security plugin after all...
>
> Matthew
>
>
> On 10/04/2018 05:23, David Blevins wrote:
>>
>> Officially closing the vote.  Thanks for the patience everyone.  As
>> mentioned in the other vote, this one needed some good discussion and a bit
>> of extra time.
>>
>> +1s
>> Andy Gumbrecht
>> David Blevins
>> Ivan Junckes Filho
>> Jean-Louis Monteiro
>> Jonathan Gallimore
>> Thiago Veronezi
>>
>> +0
>> Rudy De Busscher
>>
>> -1s
>> Mark Struberg
>> Romain Manni-Bucau
>>
>> This was intended as a non-technical vote, so I've registered Mark's -1 as
>> he intended it.  Thanks, Mark, for the clarification.  Matthew, you didn't
>> vote, your participation was quite high -- thank you!  You're more then
>> welcome to vote, sir :)
>>
>> This was a consensus vote to see if there was will keep working on the JWT
>> code here and see if it could be made reusable.  We didn't really need this
>> vote to accomplish anything other than to see where people's heads are at
>> and make sure we're communicating with each other clearly.
>>
>> It does seem over all that the desire is to take a couple more steps.
>> This vote did not address where the code should live in its final state.  We
>> don't really know how reusable anything will be.
>>
>> I'd probably expect us to take a few more steps, see how things look and
>> come back to the "where" topic.
>>
>>
>> -David
>>
>>
>>> On Mar 18, 2018, at 5:02 PM, David Blevins <david.blev...@gmail.com>
>>> wrote:
>>>
>>> The vote for merging PR 123 does not address community will on what to do
>>> with the code beyond merging it.  One can realistically vote +1 to merge the
>>> code, but then desire to see the code cleaned up and moved elsewhere.  One
>>> can realistically desire seeing an attempt to clean up the code to find what
>>> is reusable and may wish to withhold a final decision until we see how
>>> fruitful such a module would be.
>>>
>>> Out of respect for people who may not know exactly how they feel (TomEE
>>> or Geronimo), this is a vote for the latter.
>>>
>>> Vote: Should we attempt to extract code from the JWT PR to see what is
>>> reusable and how successful such a jar would be?
>>>
>>> +1 Let's give it a shot here
>>> +-0
>>> -1 Let's do this elsewhere
>>>
>>> If the vote is +1 to attempt an extraction of reusable code here, final
>>> conclusion of if that extraction is worth it or where it should live is not
>>> being voted on.  People are welcome to decide differently based on the
>>> results of the exercise.
>>>
>>>
>>> -David
>>>
>

Re: [RESULT] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

2018-04-10 9:24 GMT+02:00 Rudy De Busscher <rdebussc...@gmail.com>:
> Sorry Romain but I still have doubts if the code is really reusable, like
> that you can just add it to WildFly or Payara and that it works. (like
> Geronimo Config for example)

It will support the CDI+servlet support OOTB, the PR brings the
servlet/EJB integration (independently of microprofile) and we plugged
in
for jwt-auth to have EJB integration.

But it still means we are reusable in any CDI/servlet based server
OOTB without any dep and fully cover tomee scope so yes we are
reusable - we did it intentionally.

>
> Things like integrating with @RolesAllowed is not standardized (except
> using JASPIC maybe which I tried but I had other issues)

It is done though the CDI extension

>
> More generic parts like injecting the Claims etc, that could work.

Still a CDI thing.

>
> But I'm fine that the code is maintained at Geronimo, that TomEE code only
> contains the integration parts. But it will not be a complete
> implementation of MP JWT Auth (The Geronimo project).
>
> Rudy
>
> On 10 April 2018 at 06:58, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
>
>> Le 10 avr. 2018 05:23, "David Blevins" <david.blev...@gmail.com> a écrit :
>>
>> Officially closing the vote.  Thanks for the patience everyone.  As
>> mentioned in the other vote, this one needed some good discussion and a bit
>> of extra time.
>>
>> +1s
>> Andy Gumbrecht
>> David Blevins
>> Ivan Junckes Filho
>> Jean-Louis Monteiro
>> Jonathan Gallimore
>> Thiago Veronezi
>>
>> +0
>> Rudy De Busscher
>>
>> -1s
>> Mark Struberg
>> Romain Manni-Bucau
>>
>> This was intended as a non-technical vote, so I've registered Mark's -1 as
>> he intended it.  Thanks, Mark, for the clarification.  Matthew, you didn't
>> vote, your participation was quite high -- thank you!  You're more then
>> welcome to vote, sir :)
>>
>> This was a consensus vote to see if there was will keep working on the JWT
>> code here and see if it could be made reusable.  We didn't really need this
>> vote to accomplish anything other than to see where people's heads are at
>> and make sure we're communicating with each other clearly.
>>
>> It does seem over all that the desire is to take a couple more steps.  This
>> vote did not address where the code should live in its final state.  We
>> don't really know how reusable anything will be.
>>
>>
>>
>> ...it has been mention 3 times the code IS reusable and should just be a
>> lib. It was codes this exact way so no ambiguity here.
>>
>>
>> I'd probably expect us to take a few more steps, see how things look and
>> come back to the "where" topic.
>>
>>
>> -David
>>
>>
>> > On Mar 18, 2018, at 5:02 PM, David Blevins <david.blev...@gmail.com>
>> wrote:
>> >
>> > The vote for merging PR 123 does not address community will on what to do
>> with the code beyond merging it.  One can realistically vote +1 to merge
>> the code, but then desire to see the code cleaned up and moved elsewhere.
>> One can realistically desire seeing an attempt to clean up the code to find
>> what is reusable and may wish to withhold a final decision until we see how
>> fruitful such a module would be.
>> >
>> > Out of respect for people who may not know exactly how they feel (TomEE
>> or Geronimo), this is a vote for the latter.
>> >
>> > Vote: Should we attempt to extract code from the JWT PR to see what is
>> reusable and how successful such a jar would be?
>> >
>> > +1 Let's give it a shot here
>> > +-0
>> > -1 Let's do this elsewhere
>> >
>> > If the vote is +1 to attempt an extraction of reusable code here, final
>> conclusion of if that extraction is worth it or where it should live is not
>> being voted on.  People are welcome to decide differently based on the
>> results of the exercise.
>> >
>> >
>> > -David
>> >
>>

Re: [RESULT] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Le 10 avr. 2018 05:23, "David Blevins" <david.blev...@gmail.com> a écrit :

Officially closing the vote.  Thanks for the patience everyone.  As
mentioned in the other vote, this one needed some good discussion and a bit
of extra time.

+1s
Andy Gumbrecht
David Blevins
Ivan Junckes Filho
Jean-Louis Monteiro
Jonathan Gallimore
Thiago Veronezi

+0
Rudy De Busscher

-1s
Mark Struberg
Romain Manni-Bucau

This was intended as a non-technical vote, so I've registered Mark's -1 as
he intended it.  Thanks, Mark, for the clarification.  Matthew, you didn't
vote, your participation was quite high -- thank you!  You're more then
welcome to vote, sir :)

This was a consensus vote to see if there was will keep working on the JWT
code here and see if it could be made reusable.  We didn't really need this
vote to accomplish anything other than to see where people's heads are at
and make sure we're communicating with each other clearly.

It does seem over all that the desire is to take a couple more steps.  This
vote did not address where the code should live in its final state.  We
don't really know how reusable anything will be.



...it has been mention 3 times the code IS reusable and should just be a
lib. It was codes this exact way so no ambiguity here.


I'd probably expect us to take a few more steps, see how things look and
come back to the "where" topic.


-David


> On Mar 18, 2018, at 5:02 PM, David Blevins <david.blev...@gmail.com>
wrote:
>
> The vote for merging PR 123 does not address community will on what to do
with the code beyond merging it.  One can realistically vote +1 to merge
the code, but then desire to see the code cleaned up and moved elsewhere.
One can realistically desire seeing an attempt to clean up the code to find
what is reusable and may wish to withhold a final decision until we see how
fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE
or Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is
reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final
conclusion of if that extraction is worth it or where it should live is not
being voted on.  People are welcome to decide differently based on the
results of the exercise.
>
>
> -David
>

Re: Warnings in Catalina log file

[Romain Manni-Bucau]

Without the code it is hard to guess bit the exception mapping is not
correct it seems. Does TestException match the wsdl? Is it a generated wsdl?

Le 6 avr. 2018 08:18, "Dignesh"  a écrit :

Hi,

I am getting regular warning messages in the catalina log file,when i start
the tomee and access the webservice.

WARNING: Mismatch between Java model and WSDL model found, For wsdl
operation {http://www.myapp.in/ws/dignesh/api}testAddition,There is no
matching wsdl fault with detail QName
{http://www.myapp.in/ws/dignesh/api}TestException

I checked the java class and wsdl, I dont see any mismatch in the service
name. Is there anything that needs to be done to avoid the warning. Can
anyone please help me on this

Thank you.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

What about my proposal? Take johnzon master, copy it over 1.0.x and
downgrade apis? It is probably the safest and shouldnt be long to make
work. Can help next week if needed.

Le 1 avr. 2018 17:06, "Jonathan Gallimore"  a
écrit :

> Agreed. I'll start working on the list of fixes tonight.
>
> Jon
>
> On Sun, 1 Apr 2018, 16:02 Mark Struberg, 
> wrote:
>
> > Of course I also want to ship a 7.0.5 (or 7.1.0 if we opt to up to Java8
> > as min version).
> >
> > And I'd also happily volunteer to release Johnzon-1.0.1.
> >
> > BUT, first we need to check which Johnzon bugfixes are necessary to
> > backport!
> > Then let's create tickets for that version and solve them.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 01.04.2018 um 16:50 schrieb Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>:
> > >
> > > I think getting TomEE 8 out is obviously is preferred option. I would
> > still
> > > like to maintain TomEE 7 for those that want it. I'd be happy to go
> > through
> > > JIRA, and backport fixes as necessary for Johnzon 1.0.x.
> >
> >
>

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

Le 1 avr. 2018 12:13, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit :

> No, if you read back the proposal (wzs months ago now) > we would have
updated javaee api jar too.
That would trash tons of downstream users which use openejb-core in their
unit tests :(


Nop, why? You are thinking of an explicit javaee staying to 7? Upgrading
openejb can need to upgrade javaee api anyway (for bugfixes) so not a
blocker by itself.

That said, once again, tomee 8 option is saner.

LieGrue,strub

   On Sunday, 1 April 2018, 12:03:23 CEST, Mark Struberg
<strub...@yahoo.de.INVALID> wrote:

 The problem is that adding Johnzon-1.1.7 to TomEE7 _without_ also updating
the jsonp spec to 1.1 will NOT work!
It will blow up with MethodNotFoundExceptions...

What is needed is the following:We need a list of bugs in johnzon-1.0.0
which got fixed in the 8 EE8 releases we did so far (johnzon-1.1.0..
1.1.7).Then we can look which one can easily get backported and which
others would be complicated.
And again: EVERY HELPING HAND IS WELCOME!
Yes, most of you are interested primarily in TomEE, but lots of the hard
work is done also in other projects!Don't be afraid, the Johnzon people
will not bite you if you help them ;)
I've seen https://issues.apache.org/jira/browse/JOHNZON-149Is this one
ticket referenced there the only thing we would need for TomEE7? In that
case I could run the Johnzon-1.0.1 release today.But what else do we need?
Is there a TomEE ticket which explains what's missing?

LieGrue,strub


On Sunday, 1 April 2018, 08:59:03 CEST, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:

 Le 1 avr. 2018 07:47, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :

Hello Mark,

The point is not to enable EE8 features in TomEE 7.0.5.
Is is about fixing the many issues of currently available TomEE 7.0.4
in its JSON-P 1.0 *implementation*.

With Johnzon 1.1.7, TomEE 7.0.5 will remains at EE7 compatiblity level
because there's no plan to include EE8 *interfaces* in 7.0.5: Johnzon
is "just" the *implementation* of JSON-P in TomEE  since TomEE version
7.


No you need the api too.


My understanding of Romain's proposal is that Johnzon 1.1.7 can fix
fhe current issues of JSON-P 1.0 in TomEE 7.0.5 in a more efficient
way than trying to sort out which Johnzon 1.1.7 fixes could be
backported to Johnzon 1.0.1.


The fear here is a partial backport or more delay for 7.0.5.


I find this proposal quite reasonable.

In addition, I have to mention that I know couple of developers who
hacked around couple of JPSON issues they got with TomEE 7.0.4 by
replacing Johnzon with 1.1.x. Make this is official in TomEE 7.0.5
would make non-hackers more comfortable with TomEE 7.



Same here




 I am not part of TomEE contributors, so of course all this is suggestions.
What is the process for deciding on whether or not Johnzon 1.1.7 would
be the JSON-P implementation of TomEE 7.0.5? A vote by binding people?


That said Mark is right and why i proposed to just use tomee 8 which is a
smooth upgrade


Best regards,
Alexandre


2018-03-31 23:34 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> If we start adding EE8 features then we will further blur the line.Imo we
should remain clean and push for TomEE8 instead...
> LieGrue,strub
>
>
>On Saturday, 31 March 2018, 23:00:43 CEST, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:
>
>  Le 31 mars 2018 22:33, "Mark Struberg" <strub...@yahoo.de.invalid> a
écrit :
>
> folks stop. johnzon-1.1.7 is JSON-P-1.1 which is EE8.Do we really want to
> include this in Tomee7 (seven!)?
> I don't think so...
>
>
> Why? Doesnt prevent to be ee7 certified + we are not so only constraint is
> about java min version.
>
> That said agree tomee 8 can be safer for a long terms choice.
>
> LieGrue,strub
>
>
>On Saturday, 31 March 2018, 19:32:52 CEST, Alex The Rocker <
> alex.m3...@gmail.com> wrote:
>
>  Hello,
>
> To continue on this thread: I have updated
> https://issues.apache.org/jira/browse/TOMEE-2153 title to make it more
> explicit.
> New title of this JIRA is now "Dependency upgrade to Johnzon 1.1.7"
>
> Could this be part of next 7.0.5-snapshot ?
>
> Best regards,
> Alexandre
>
>
> 2018-03-31 18:12 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>> Le 31 mars 2018 16:36, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :
>>
>> Hi Romain,
>>
>> Are you suggesting that instead of waiting for TomEE 7.0.5 people
>> should upgrade to TomEE 8 ?
>>
>>
>> Yes
>>
>>
>> IHMO it's a bigger step for people : major version changes usually
>> involves major impacts (at least that's my experience).
>>
>>
>> Shouldnt be the case here. Tomee 1.0 to 1.5 was way more hurting than 1
to

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

Le 1 avr. 2018 07:47, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :

Hello Mark,

The point is not to enable EE8 features in TomEE 7.0.5.
Is is about fixing the many issues of currently available TomEE 7.0.4
in its JSON-P 1.0 *implementation*.

With Johnzon 1.1.7, TomEE 7.0.5 will remains at EE7 compatiblity level
because there's no plan to include EE8 *interfaces* in 7.0.5: Johnzon
is "just" the *implementation* of JSON-P in TomEE  since TomEE version
7.


No you need the api too.


My understanding of Romain's proposal is that Johnzon 1.1.7 can fix
fhe current issues of JSON-P 1.0 in TomEE 7.0.5 in a more efficient
way than trying to sort out which Johnzon 1.1.7 fixes could be
backported to Johnzon 1.0.1.


The fear here is a partial backport or more delay for 7.0.5.


I find this proposal quite reasonable.

In addition, I have to mention that I know couple of developers who
hacked around couple of JPSON issues they got with TomEE 7.0.4 by
replacing Johnzon with 1.1.x. Make this is official in TomEE 7.0.5
would make non-hackers more comfortable with TomEE 7.



Same here




 I am not part of TomEE contributors, so of course all this is suggestions.
What is the process for deciding on whether or not Johnzon 1.1.7 would
be the JSON-P implementation of TomEE 7.0.5? A vote by binding people?


That said Mark is right and why i proposed to just use tomee 8 which is a
smooth upgrade


Best regards,
Alexandre


2018-03-31 23:34 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
> If we start adding EE8 features then we will further blur the line.Imo we
should remain clean and push for TomEE8 instead...
> LieGrue,strub
>
>
> On Saturday, 31 March 2018, 23:00:43 CEST, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:
>
>  Le 31 mars 2018 22:33, "Mark Struberg" <strub...@yahoo.de.invalid> a
écrit :
>
> folks stop. johnzon-1.1.7 is JSON-P-1.1 which is EE8.Do we really want to
> include this in Tomee7 (seven!)?
> I don't think so...
>
>
> Why? Doesnt prevent to be ee7 certified + we are not so only constraint is
> about java min version.
>
> That said agree tomee 8 can be safer for a long terms choice.
>
> LieGrue,strub
>
>
> On Saturday, 31 March 2018, 19:32:52 CEST, Alex The Rocker <
> alex.m3...@gmail.com> wrote:
>
>  Hello,
>
> To continue on this thread: I have updated
> https://issues.apache.org/jira/browse/TOMEE-2153 title to make it more
> explicit.
> New title of this JIRA is now "Dependency upgrade to Johnzon 1.1.7"
>
> Could this be part of next 7.0.5-snapshot ?
>
> Best regards,
> Alexandre
>
>
> 2018-03-31 18:12 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>> Le 31 mars 2018 16:36, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :
>>
>> Hi Romain,
>>
>> Are you suggesting that instead of waiting for TomEE 7.0.5 people
>> should upgrade to TomEE 8 ?
>>
>>
>> Yes
>>
>>
>> IHMO it's a bigger step for people : major version changes usually
>> involves major impacts (at least that's my experience).
>>
>>
>> Shouldnt be the case here. Tomee 1.0 to 1.5 was way more hurting than 1
to
>> 7. Here it should even be smoother.
>>
>> I'm more fond of a TomEE 7.0.5 with Java 8 as the minimum prerequisite
>> if this allows for the replacement of Johnzon 1.0.0 by latest Johnzon
>> 1.1.x to get all the fixes committed so far.
>>
>>
>> +1 from me too
>>
>> After all ,Java 7 end of public updates was in April 2015, so making
>> Java 8 as the minimum prerequisite for TomEE7 three years later after
>> this date sounds very reasonable.
>>
>> Thanks,
>> Alexandre
>>
>>
>>
>>
>> 2018-03-31 15:44 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>>> Le 31 mars 2018 15:00, "Jonathan Gallimore" <
jonathan.gallim...@gmail.com
>>
>>> a écrit :
>>>
>>> It requires TomEE 7.x, which targets EE7, to shift to Java 8.
>>>
>>> I'm not fussed either way, but we should discuss it and encourage input
>>> from the wider community. I'm sure I've asked before if it's ok to
> require
>>> Java 8 and still target EE 7, but I can't remember if it was
definitively
>>> answered or not, and if it was, I can't remember what the answer was.
>>>
>>>
>>> Mixed thread.
>>>
>>> Having tomee 8 released just after the 7.0.5 it can also mean you can
>>> ignore this one and upgrade straight after. Just thinking out loud.
>>>
>>>
>>> Jon
>>>
>>> On Sat, 31 Mar 2018, 12:29 Alex The Rocker, <alex.m3...@gmail.c

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

Le 31 mars 2018 22:33, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit :

folks stop. johnzon-1.1.7 is JSON-P-1.1 which is EE8.Do we really want to
include this in Tomee7 (seven!)?
I don't think so...


Why? Doesnt prevent to be ee7 certified + we are not so only constraint is
about java min version.

That said agree tomee 8 can be safer for a long terms choice.

LieGrue,strub


On Saturday, 31 March 2018, 19:32:52 CEST, Alex The Rocker <
alex.m3...@gmail.com> wrote:

 Hello,

To continue on this thread: I have updated
https://issues.apache.org/jira/browse/TOMEE-2153 title to make it more
explicit.
New title of this JIRA is now "Dependency upgrade to Johnzon 1.1.7"

Could this be part of next 7.0.5-snapshot ?

Best regards,
Alexandre


2018-03-31 18:12 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> Le 31 mars 2018 16:36, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :
>
> Hi Romain,
>
> Are you suggesting that instead of waiting for TomEE 7.0.5 people
> should upgrade to TomEE 8 ?
>
>
> Yes
>
>
> IHMO it's a bigger step for people : major version changes usually
> involves major impacts (at least that's my experience).
>
>
> Shouldnt be the case here. Tomee 1.0 to 1.5 was way more hurting than 1 to
> 7. Here it should even be smoother.
>
> I'm more fond of a TomEE 7.0.5 with Java 8 as the minimum prerequisite
> if this allows for the replacement of Johnzon 1.0.0 by latest Johnzon
> 1.1.x to get all the fixes committed so far.
>
>
> +1 from me too
>
> After all ,Java 7 end of public updates was in April 2015, so making
> Java 8 as the minimum prerequisite for TomEE7 three years later after
> this date sounds very reasonable.
>
> Thanks,
> Alexandre
>
>
>
>
> 2018-03-31 15:44 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>> Le 31 mars 2018 15:00, "Jonathan Gallimore" <jonathan.gallim...@gmail.com
>
>> a écrit :
>>
>> It requires TomEE 7.x, which targets EE7, to shift to Java 8.
>>
>> I'm not fussed either way, but we should discuss it and encourage input
>> from the wider community. I'm sure I've asked before if it's ok to
require
>> Java 8 and still target EE 7, but I can't remember if it was definitively
>> answered or not, and if it was, I can't remember what the answer was.
>>
>>
>> Mixed thread.
>>
>> Having tomee 8 released just after the 7.0.5 it can also mean you can
>> ignore this one and upgrade straight after. Just thinking out loud.
>>
>>
>> Jon
>>
>> On Sat, 31 Mar 2018, 12:29 Alex The Rocker, <alex.m3...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I agree with Romain : couldn't TomEE 7.0.5 be based on latest stable
>>> Johnzon 1.1.x ?
>>>
>>> Best regards,
>>> Alexandre
>>>
>>>
>>> 2018-03-31 11:16 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>>> > We can but we miss (ATM) a looot of fixes.
>>> >
>>> > Le 30 mars 2018 23:26, "Jonathan Gallimore" <
>>> jonathan.gallim...@gmail.com>
>>> > a écrit :
>>> >
>>> >> I wonder if we can get a Johnzon 1.0.1 release, targetting EE7? Looks
>>> like
>>> >> the code is in the branch and ready to go.
>>> >>
>>> >> Jon
>>> >>
>>> >> On Fri, Mar 30, 2018 at 9:03 AM, Alex The Rocker <
alex.m3...@gmail.com
>>
>>> >> wrote:
>>> >>
>>> >> > (sorry previous mail got truncated)
>>> >> >
>>> >> > Hello Jon,
>>> >> >
>>> >> > To answer your question about whether or not my expected Johnzon
>> fixes
>>> >> > are in current "to become TomEE 7.0.5" : my view is that this is
not
>>> >> > the case:
>>> >> >  * The following JIRA is still opened :
>>> >> > https://issues.apache.org/jira/browse/TOMEE-2153
>>> >> >  * According to discussion in same thread of message, Romain
> proposed
>>> >> > to push Johnzon 1.1.x in current TomEE 7.x repository (sorry if I
>>> >> > don't use the proper vocabulary) and I like very this proposal
given
>>> >> > the large amount of fixes in Johnzon 1.1.x versus the pile I have
>> been
>>> >> > internally reported on  Johnzon 1.0.0
>>> >> >  * Appart from Johnzon 1.1.x, TomEE 7.0.5 should include latest
>> Tomcat
>>> >> > 8.5.x security fix level, so that we could propose

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

Le 31 mars 2018 16:36, "Alex The Rocker" <alex.m3...@gmail.com> a écrit :

Hi Romain,

Are you suggesting that instead of waiting for TomEE 7.0.5 people
should upgrade to TomEE 8 ?


Yes


IHMO it's a bigger step for people : major version changes usually
involves major impacts (at least that's my experience).


Shouldnt be the case here. Tomee 1.0 to 1.5 was way more hurting than 1 to
7. Here it should even be smoother.

I'm more fond of a TomEE 7.0.5 with Java 8 as the minimum prerequisite
if this allows for the replacement of Johnzon 1.0.0 by latest Johnzon
1.1.x to get all the fixes committed so far.


+1 from me too

After all ,Java 7 end of public updates was in April 2015, so making
Java 8 as the minimum prerequisite for TomEE7 three years later after
this date sounds very reasonable.

Thanks,
Alexandre




2018-03-31 15:44 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> Le 31 mars 2018 15:00, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
> a écrit :
>
> It requires TomEE 7.x, which targets EE7, to shift to Java 8.
>
> I'm not fussed either way, but we should discuss it and encourage input
> from the wider community. I'm sure I've asked before if it's ok to require
> Java 8 and still target EE 7, but I can't remember if it was definitively
> answered or not, and if it was, I can't remember what the answer was.
>
>
> Mixed thread.
>
> Having tomee 8 released just after the 7.0.5 it can also mean you can
> ignore this one and upgrade straight after. Just thinking out loud.
>
>
> Jon
>
> On Sat, 31 Mar 2018, 12:29 Alex The Rocker, <alex.m3...@gmail.com> wrote:
>
>> Hello,
>>
>> I agree with Romain : couldn't TomEE 7.0.5 be based on latest stable
>> Johnzon 1.1.x ?
>>
>> Best regards,
>> Alexandre
>>
>>
>> 2018-03-31 11:16 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>> > We can but we miss (ATM) a looot of fixes.
>> >
>> > Le 30 mars 2018 23:26, "Jonathan Gallimore" <
>> jonathan.gallim...@gmail.com>
>> > a écrit :
>> >
>> >> I wonder if we can get a Johnzon 1.0.1 release, targetting EE7? Looks
>> like
>> >> the code is in the branch and ready to go.
>> >>
>> >> Jon
>> >>
>> >> On Fri, Mar 30, 2018 at 9:03 AM, Alex The Rocker <alex.m3...@gmail.com
>
>> >> wrote:
>> >>
>> >> > (sorry previous mail got truncated)
>> >> >
>> >> > Hello Jon,
>> >> >
>> >> > To answer your question about whether or not my expected Johnzon
> fixes
>> >> > are in current "to become TomEE 7.0.5" : my view is that this is not
>> >> > the case:
>> >> >  * The following JIRA is still opened :
>> >> > https://issues.apache.org/jira/browse/TOMEE-2153
>> >> >  * According to discussion in same thread of message, Romain
proposed
>> >> > to push Johnzon 1.1.x in current TomEE 7.x repository (sorry if I
>> >> > don't use the proper vocabulary) and I like very this proposal given
>> >> > the large amount of fixes in Johnzon 1.1.x versus the pile I have
> been
>> >> > internally reported on  Johnzon 1.0.0
>> >> >  * Appart from Johnzon 1.1.x, TomEE 7.0.5 should include latest
> Tomcat
>> >> > 8.5.x security fix level, so that we could propose to casual TomEE
>> >> > users a version "as secure as possible" when it'll be released.
>> >> >
>> >> > Of course I volunteer to run tests on any snapshot / RC on our large
>> >> > number of complex web apps.
>> >> >
>> >> > Best regards,
>> >> > Alexandre
>> >> >
>> >> >
>> >> > 2018-03-30 9:59 GMT+02:00 Alex The Rocker <alex.m3...@gmail.com>:
>> >> > > Hello Jon,
>> >> > >
>> >> > > To answer your question about whether or not my expected Johnzon
>> fixes
>> >> > > are in current "to become TomEE 7.0.5" : my view is that this is
> not
>> >> > > the case:
>> >> > >  * The following JIRA is still opened :
>> >> > > https://issues.apache.org/jira/browse/TOMEE-2153
>> >> > >  * According to discussion in same thread of message, Romain
>> proposed
>> >> > > to push Johnzon 1.1.x in wha
>> >> > >
>> >> > > 2018-03-29 19:00 GMT+02:00 Jonathan Gallimore <
>> >> > jonathan.gall

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

Le 31 mars 2018 15:00, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

It requires TomEE 7.x, which targets EE7, to shift to Java 8.

I'm not fussed either way, but we should discuss it and encourage input
from the wider community. I'm sure I've asked before if it's ok to require
Java 8 and still target EE 7, but I can't remember if it was definitively
answered or not, and if it was, I can't remember what the answer was.


Mixed thread.

Having tomee 8 released just after the 7.0.5 it can also mean you can
ignore this one and upgrade straight after. Just thinking out loud.


Jon

On Sat, 31 Mar 2018, 12:29 Alex The Rocker, <alex.m3...@gmail.com> wrote:

> Hello,
>
> I agree with Romain : couldn't TomEE 7.0.5 be based on latest stable
> Johnzon 1.1.x ?
>
> Best regards,
> Alexandre
>
>
> 2018-03-31 11:16 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > We can but we miss (ATM) a looot of fixes.
> >
> > Le 30 mars 2018 23:26, "Jonathan Gallimore" <
> jonathan.gallim...@gmail.com>
> > a écrit :
> >
> >> I wonder if we can get a Johnzon 1.0.1 release, targetting EE7? Looks
> like
> >> the code is in the branch and ready to go.
> >>
> >> Jon
> >>
> >> On Fri, Mar 30, 2018 at 9:03 AM, Alex The Rocker <alex.m3...@gmail.com>
> >> wrote:
> >>
> >> > (sorry previous mail got truncated)
> >> >
> >> > Hello Jon,
> >> >
> >> > To answer your question about whether or not my expected Johnzon
fixes
> >> > are in current "to become TomEE 7.0.5" : my view is that this is not
> >> > the case:
> >> >  * The following JIRA is still opened :
> >> > https://issues.apache.org/jira/browse/TOMEE-2153
> >> >  * According to discussion in same thread of message, Romain proposed
> >> > to push Johnzon 1.1.x in current TomEE 7.x repository (sorry if I
> >> > don't use the proper vocabulary) and I like very this proposal given
> >> > the large amount of fixes in Johnzon 1.1.x versus the pile I have
been
> >> > internally reported on  Johnzon 1.0.0
> >> >  * Appart from Johnzon 1.1.x, TomEE 7.0.5 should include latest
Tomcat
> >> > 8.5.x security fix level, so that we could propose to casual TomEE
> >> > users a version "as secure as possible" when it'll be released.
> >> >
> >> > Of course I volunteer to run tests on any snapshot / RC on our large
> >> > number of complex web apps.
> >> >
> >> > Best regards,
> >> > Alexandre
> >> >
> >> >
> >> > 2018-03-30 9:59 GMT+02:00 Alex The Rocker <alex.m3...@gmail.com>:
> >> > > Hello Jon,
> >> > >
> >> > > To answer your question about whether or not my expected Johnzon
> fixes
> >> > > are in current "to become TomEE 7.0.5" : my view is that this is
not
> >> > > the case:
> >> > >  * The following JIRA is still opened :
> >> > > https://issues.apache.org/jira/browse/TOMEE-2153
> >> > >  * According to discussion in same thread of message, Romain
> proposed
> >> > > to push Johnzon 1.1.x in wha
> >> > >
> >> > > 2018-03-29 19:00 GMT+02:00 Jonathan Gallimore <
> >> > jonathan.gallim...@gmail.com>:
> >> > >> Yes, if we want to release now we'd need to roll that change back.
> >> > >>
> >> > >> Jon
> >> > >>
> >> > >> On Thu, 29 Mar 2018, 17:55 Romain Manni-Bucau, <
> rmannibu...@gmail.com
> >> >
> >> > >> wrote:
> >> > >>
> >> > >>> Le 29 mars 2018 18:23, "Jonathan Gallimore" <
> >> > jonathan.gallim...@gmail.com>
> >> > >>> a écrit :
> >> > >>>
> >> > >>> We did talk about doing a TomEE 7 release. I'm willing to be
> release
> >> > >>> manager. I have 2 questions:
> >> > >>>
> >> > >>> * Does the TomEE 7 / master branch have the fix you want already,
> or
> >> is
> >> > >>> there work to do there?
> >> > >>>
> >> > >>> * I did upgrade xbean to a version that handles java 9 and 10,
> and I
> >> > also
> >> > >>> pushed updates to OWB and OpenJPA for the same. Do we want to
wait
> >> for
> >> > >>&

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

We can but we miss (ATM) a looot of fixes.

Le 30 mars 2018 23:26, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

> I wonder if we can get a Johnzon 1.0.1 release, targetting EE7? Looks like
> the code is in the branch and ready to go.
>
> Jon
>
> On Fri, Mar 30, 2018 at 9:03 AM, Alex The Rocker <alex.m3...@gmail.com>
> wrote:
>
> > (sorry previous mail got truncated)
> >
> > Hello Jon,
> >
> > To answer your question about whether or not my expected Johnzon fixes
> > are in current "to become TomEE 7.0.5" : my view is that this is not
> > the case:
> >  * The following JIRA is still opened :
> > https://issues.apache.org/jira/browse/TOMEE-2153
> >  * According to discussion in same thread of message, Romain proposed
> > to push Johnzon 1.1.x in current TomEE 7.x repository (sorry if I
> > don't use the proper vocabulary) and I like very this proposal given
> > the large amount of fixes in Johnzon 1.1.x versus the pile I have been
> > internally reported on  Johnzon 1.0.0
> >  * Appart from Johnzon 1.1.x, TomEE 7.0.5 should include latest Tomcat
> > 8.5.x security fix level, so that we could propose to casual TomEE
> > users a version "as secure as possible" when it'll be released.
> >
> > Of course I volunteer to run tests on any snapshot / RC on our large
> > number of complex web apps.
> >
> > Best regards,
> > Alexandre
> >
> >
> > 2018-03-30 9:59 GMT+02:00 Alex The Rocker <alex.m3...@gmail.com>:
> > > Hello Jon,
> > >
> > > To answer your question about whether or not my expected Johnzon fixes
> > > are in current "to become TomEE 7.0.5" : my view is that this is not
> > > the case:
> > >  * The following JIRA is still opened :
> > > https://issues.apache.org/jira/browse/TOMEE-2153
> > >  * According to discussion in same thread of message, Romain proposed
> > > to push Johnzon 1.1.x in wha
> > >
> > > 2018-03-29 19:00 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>:
> > >> Yes, if we want to release now we'd need to roll that change back.
> > >>
> > >> Jon
> > >>
> > >> On Thu, 29 Mar 2018, 17:55 Romain Manni-Bucau, <rmannibu...@gmail.com
> >
> > >> wrote:
> > >>
> > >>> Le 29 mars 2018 18:23, "Jonathan Gallimore" <
> > jonathan.gallim...@gmail.com>
> > >>> a écrit :
> > >>>
> > >>> We did talk about doing a TomEE 7 release. I'm willing to be release
> > >>> manager. I have 2 questions:
> > >>>
> > >>> * Does the TomEE 7 / master branch have the fix you want already, or
> is
> > >>> there work to do there?
> > >>>
> > >>> * I did upgrade xbean to a version that handles java 9 and 10, and I
> > also
> > >>> pushed updates to OWB and OpenJPA for the same. Do we want to wait
> for
> > >>> releases of those, or do we want to release right away?
> > >>>
> > >>>
> > >>> Guess we want to have a single xbean version so either wait or
> rollback
> > >>> pby.
> > >>>
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Mar 29, 2018 at 4:16 PM, Alex The Rocker <
> alex.m3...@gmail.com
> > >
> > >>> wrote:
> > >>>
> > >>> > Hello,
> > >>> >
> > >>> > I noticed that in latest TomEE 7.0.5 SNAPSHOT we will have Johnzon
> > 1.0.0.
> > >>> > Is there any chance to see Romain's proposal to ise jsonp/b 1.1/1.0
> > in
> > >>> > tomee 7 come out anytime soon?
> > >>> >
> > >>> > Best regards,
> > >>> > Alexandre
> > >>> >
> > >>> >
> > >>> > 2018-03-04 14:46 GMT+01:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >>> > > @Mark: it is tracked on johnzon (
> > >>> > >
> > >>> https://issues.apache.org/jira/plugins/servlet/mobile#
> > issue/JOHNZON-149
> > >>> > ).
> > >>> > > There was the proposal I did months ago to just use jsonp/b
> > 1.1/1.0 in
> > >>> > > tomee 7 (doesnt prevent anything from tomee perspective if we
> drop
> > java
> > >>> 7
> > >>> > > compat). If not

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Le 30 mars 2018 23:46, "David Blevins" <david.blev...@gmail.com> a écrit :

> On Mar 29, 2018, at 10:06 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> Le 30 mars 2018 04:30, "David Blevins" <david.blev...@gmail.com> a écrit :
>
>
>> On Mar 29, 2018, at 12:57 PM, David Blevins <david.blev...@gmail.com>
> wrote:
>>
>>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>>>
>>> Le 29 mars 2018 20:49, "David Blevins" <david.blev...@gmail.com> a écrit
> :
>>>
>>>
>>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>>> wrote:
>>>>
>>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <david.blev...@gmail.com>
>>> wrote:
>>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>>
>>>> That + the fact tomee is not and shouldnt become a put it all project
> just
>>>> become of scm perms IMO but stay an integration project to keep sense
> and
>>>> not mess up its own image and mess up the quality of our reusable libs.
>>>
>>>> Do you see this as a one-time situation or do you intend to vote the
> same
>>>> way on any future MicroProfile implementation work in TomEE?
>>>>
>>>> For example, should work be started to implement MicroProfile
> OpenTracing
>>>> in TomEE, would that PR be -1 on the basis the implementation should be
> in
>>>> Geronimo?
>>>
>>> Being said it will be in G anyway since that is half of G definition
> since
>>> some months now (since server has been dropped), I ll do my best to keep
> it
>>> consistent in our small ecosystem and do the same to have strong
reusable
>>> libs since there is no technical blockers @MP to have it and a strong
>>> integration solution (tomee) and not a mess with an in between state.
>>
>> I'm reading that as a yes that you would -1 future MP implementation work
> in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> come to that and will do your best to create good implementations in
> Geronimo so it isn't necessary.
>>
>> If I misunderstood, please clarify.
>
>> On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>>
>> Globally that is it. You explained a lot why geronimo failed and not sure
>> why tomee is kind of taking the same path - well actually cause of "perms
>> lack" fear from what I read. This is not a safe reason (+not that
relevant
>> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
>> we have been 7 years ago instead of just going on different paths cause
of
>> a fears.
>
> > I think we should openly discuss your perspective and how it might be
> > perceived by the project.  There are 11 +1 votes, 5 of them binding.  It
> > does appear that overall the project would like to move forward with the
> > code.  You -1 the code on the basis that it should go to Geronimo
instead
> > with the clear statement you will continue to -1 on future MicroProfile
> > code.  Can you see how this creates a situation where 11 people feel
they
> > have no ability to contribute to the project now or in the future?  Do
you
> > feel this is the spirit of the Apache Way and represents community over
> > code?
>
>
> More than never but I just dont ignore other projects. I understand most
of
> voting people are not involved in G and therefore I can see where they
come
> from (and no Jon, this was not directed to you in particular).
>
> The main difference is Im thinking of communities and not community.

I think it would be fair to assume everyone is thinking of communities
plural and that no one is ignoring the greater good of Apache.  Only that
there are differences in opinion on what that is and how it should be
achieved.

> You are also plain wrong saying there is no way to contribute, there are
> plenty as on any asf projects and for most people it will be the exact
same.
>
> Project is created @G, if T duplicates it what does happen? We get an half
> baked flavor on one side and another one on the other? Do you think it is
> the right thing for asf David? Do you want to split communities? Do you
> want to make of TomEE a put it all project which means getting rid of
TomEE
> as a thing?

We need to acknowledge that the community voted on where to continue
working on the code and that vote was overwhelmingly to continue evolving
it here.  The perspective of "TomEE is duplicating G

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

2018-03-30 7:24 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>:

> On Fri, 30 Mar 2018, 06:06 Romain Manni-Bucau, <rmannibu...@gmail.com>
> wrote:
>
> > Le 30 mars 2018 04:30, "David Blevins" <david.blev...@gmail.com> a
> écrit :
> >
> >
> > > On Mar 29, 2018, at 12:57 PM, David Blevins <david.blev...@gmail.com>
> > wrote:
> > >
> > >> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> > >>
> > >> Le 29 mars 2018 20:49, "David Blevins" <david.blev...@gmail.com> a
> > écrit
> > :
> > >>
> > >>
> > >>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>>> On Mar 28, 2018, at 6:29 PM, David Blevins <david.blev...@gmail.com
> >
> > >> wrote:
> > >>>> Is your -1 on the basis that the code must be moved to Geronimo?
> > >>>
> > >>> That + the fact tomee is not and shouldnt become a put it all project
> > just
> > >>> become of scm perms IMO but stay an integration project to keep sense
> > and
> > >>> not mess up its own image and mess up the quality of our reusable
> libs.
> > >>
> > >>> Do you see this as a one-time situation or do you intend to vote the
> > same
> > >>> way on any future MicroProfile implementation work in TomEE?
> > >>>
> > >>> For example, should work be started to implement MicroProfile
> > OpenTracing
> > >>> in TomEE, would that PR be -1 on the basis the implementation should
> be
> > in
> > >>> Geronimo?
> > >>
> > >> Being said it will be in G anyway since that is half of G definition
> > since
> > >> some months now (since server has been dropped), I ll do my best to
> keep
> > it
> > >> consistent in our small ecosystem and do the same to have strong
> > reusable
> > >> libs since there is no technical blockers @MP to have it and a strong
> > >> integration solution (tomee) and not a mess with an in between state.
> > >
> > > I'm reading that as a yes that you would -1 future MP implementation
> work
> > in TomEE on the basis it should live in Geronimo, but you hope it doesn't
> > come to that and will do your best to create good implementations in
> > Geronimo so it isn't necessary.
> > >
> > > If I misunderstood, please clarify.
> >
> > > On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> > >
> > > Globally that is it. You explained a lot why geronimo failed and not
> sure
> > > why tomee is kind of taking the same path - well actually cause of
> "perms
> > > lack" fear from what I read. This is not a safe reason (+not that
> > relevant
> > > @asf thanks to the meritocracy) and Id prefer to keep "us" being unite
> as
> > > we have been 7 years ago instead of just going on different paths cause
> > of
> > > a fears.
> >
> > I think we should openly discuss your perspective and how it might be
> > perceived by the project.  There are 11 +1 votes, 5 of them binding.  It
> > does appear that overall the project would like to move forward with the
> > code.  You -1 the code on the basis that it should go to Geronimo instead
> > with the clear statement you will continue to -1 so on future
> MicroProfile
> > code.  Can you see how this creates a situation where 11 people feel they
> > have no ability to contribute to the project now or in the future?  Do
> you
> > feel this is the spirit of the Apache Way and represents community over
> > code?
> >
> >
> > More than never but I just dont ignore other projects. I understand most
> of
> > voting people are not involved in G and therefore I can see where they
> come
> > from (and no Jon, this was not directed to you in particular).
> >
> > The main difference is Im thinking of communities and not community.
> >
> > You are also plain wrong saying there is no way to contribute, there are
> > plenty as on any asf projects and for most people it will be the exact
> > same.
> >
>
> Is that what was said?
>

Was my understanding of "people feel they have no ability to contribute to
the project now or in the future"


>
>
> > Project is created 

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Le 30 mars 2018 04:30, "David Blevins" <david.blev...@gmail.com> a écrit :


> On Mar 29, 2018, at 12:57 PM, David Blevins <david.blev...@gmail.com>
wrote:
>
>> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>>
>> Le 29 mars 2018 20:49, "David Blevins" <david.blev...@gmail.com> a écrit
:
>>
>>
>>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>>
>>>> On Mar 28, 2018, at 6:29 PM, David Blevins <david.blev...@gmail.com>
>> wrote:
>>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>>
>>> That + the fact tomee is not and shouldnt become a put it all project
just
>>> become of scm perms IMO but stay an integration project to keep sense
and
>>> not mess up its own image and mess up the quality of our reusable libs.
>>
>>> Do you see this as a one-time situation or do you intend to vote the
same
>>> way on any future MicroProfile implementation work in TomEE?
>>>
>>> For example, should work be started to implement MicroProfile
OpenTracing
>>> in TomEE, would that PR be -1 on the basis the implementation should be
in
>>> Geronimo?
>>
>> Being said it will be in G anyway since that is half of G definition
since
>> some months now (since server has been dropped), I ll do my best to keep
it
>> consistent in our small ecosystem and do the same to have strong reusable
>> libs since there is no technical blockers @MP to have it and a strong
>> integration solution (tomee) and not a mess with an in between state.
>
> I'm reading that as a yes that you would -1 future MP implementation work
in TomEE on the basis it should live in Geronimo, but you hope it doesn't
come to that and will do your best to create good implementations in
Geronimo so it isn't necessary.
>
> If I misunderstood, please clarify.

> On Mar 29, 2018, at 1:49 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> Globally that is it. You explained a lot why geronimo failed and not sure
> why tomee is kind of taking the same path - well actually cause of "perms
> lack" fear from what I read. This is not a safe reason (+not that relevant
> @asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
> we have been 7 years ago instead of just going on different paths cause of
> a fears.

I think we should openly discuss your perspective and how it might be
perceived by the project.  There are 11 +1 votes, 5 of them binding.  It
does appear that overall the project would like to move forward with the
code.  You -1 the code on the basis that it should go to Geronimo instead
with the clear statement you will continue to -1 so on future MicroProfile
code.  Can you see how this creates a situation where 11 people feel they
have no ability to contribute to the project now or in the future?  Do you
feel this is the spirit of the Apache Way and represents community over
code?


More than never but I just dont ignore other projects. I understand most of
voting people are not involved in G and therefore I can see where they come
from (and no Jon, this was not directed to you in particular).

The main difference is Im thinking of communities and not community.

You are also plain wrong saying there is no way to contribute, there are
plenty as on any asf projects and for most people it will be the exact same.

Project is created @G, if T duplicates it what does happen? We get an half
baked flavor on one side and another one on the other? Do you think it is
the right thing for asf David? Do you want to split communities? Do you
want to make of TomEE a put it all project which means getting rid of TomEE
as a thing?


Im really fed up to be always felt as the bad guy but I also know it is
wrong and will fail. Short terms it will fake some activity on the project
(is it the goal?) Which can be good, long terms it will kill all the good
of TomEE AND our libraries as mentionned earlier.

If you want to pass it in force you can but please remive me from the pmc
before.




-David

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Globally that is it. You explained a lot why geronimo failed and not sure
why tomee is kind of taking the same path - well actually cause of "perms
lack" fear from what I read. This is not a safe reason (+not that relevant
@asf thanks to the meritocracy) and Id prefer to keep "us" being unite as
we have been 7 years ago instead of just going on different paths cause of
a fears.



Le 29 mars 2018 21:57, "David Blevins" <david.blev...@gmail.com> a écrit :

> On Mar 29, 2018, at 12:15 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> Le 29 mars 2018 20:49, "David Blevins" <david.blev...@gmail.com> a écrit :
>
>
>> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>>
>>> On Mar 28, 2018, at 6:29 PM, David Blevins <david.blev...@gmail.com>
> wrote:
>>> Is your -1 on the basis that the code must be moved to Geronimo?
>>
>> That + the fact tomee is not and shouldnt become a put it all project
just
>> become of scm perms IMO but stay an integration project to keep sense and
>> not mess up its own image and mess up the quality of our reusable libs.
>
> > Do you see this as a one-time situation or do you intend to vote the
same
> > way on any future MicroProfile implementation work in TomEE?
> >
> > For example, should work be started to implement MicroProfile
OpenTracing
> > in TomEE, would that PR be -1 on the basis the implementation should be
in
> > Geronimo?
>
> Being said it will be in G anyway since that is half of G definition since
> some months now (since server has been dropped), I ll do my best to keep
it
> consistent in our small ecosystem and do the same to have strong reusable
> libs since there is no technical blockers @MP to have it and a strong
> integration solution (tomee) and not a mess with an in between state.

I'm reading that as a yes that you would -1 future MP implementation work
in TomEE on the basis it should live in Geronimo, but you hope it doesn't
come to that and will do your best to create good implementations in
Geronimo so it isn't necessary.

If I misunderstood, please clarify.


-David

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Le 29 mars 2018 20:49, "David Blevins" <david.blev...@gmail.com> a écrit :


> On Mar 28, 2018, at 8:53 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> > On Mar 28, 2018, at 6:29 PM, David Blevins <david.blev...@gmail.com>
wrote:
> > Is your -1 on the basis that the code must be moved to Geronimo?
>
> That + the fact tomee is not and shouldnt become a put it all project just
> become of scm perms IMO but stay an integration project to keep sense and
> not mess up its own image and mess up the quality of our reusable libs.

Do you see this as a one-time situation or do you intend to vote the same
way on any future MicroProfile implementation work in TomEE?

For example, should work be started to implement MicroProfile OpenTracing
in TomEE, would that PR be -1 on the basis the implementation should be in
Geronimo?


Being said it will be in G anyway since that is half of G definition since
some months now (since server has been dropped), I ll do my best to keep it
consistent in our small ecosystem and do the same to have strong reusable
libs since there is no technical blockers @MP to have it and a strong
integration solution (tomee) and not a mess with an in between state.




-David

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

@Matthew: with JWT you get a self contained token you validate without any
remote call, you just need to put @LoginConfig (from the MP spec, not the
servlet one) or the equivalent in the web.xml to activate it. To configure
it you can use mp-config to set the certificate which validate the JWT
signature (and optionally the date validation range).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-29 12:59 GMT+02:00 Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk
>:

> thanks for the more detailed explanation and it is good that @RolesAllowed
> will finally work.
> by "configuration of an oauth endpoint" i meant that the user could define
> an endpoint in config that would allow TomEE to use that as as a security
> provider.  i.e. not using TomEE itself as a security provider.
> in keycloak a realm client has a "keycloak OIDC JSON" file that is created
> through the user interface.  this is dropped into the webapp and a valve
> has to be setup in context.xml
> 
> 
> 
> i just wondered if it was similar.  are there any docs?
>
>
> On 29/03/2018 04:00, David Blevins wrote:
>
>> On Mar 28, 2018, at 1:22 AM, Matthew Broadhead <
>>> matthew.broadh...@nbmlaw.co.uk> wrote:
>>>
>>> would it allow configuration of an oauth endpoint in TomEE and then
>>> defining security-constraint in the web.xml of a webapp?  seems like a good
>>> plan if it drops the need for 3rd party libs
>>>
>> Very close.  It wouldn't provide an endpoint that creates JWT tokens, but
>> it would provide functionality for JWT tokens to be *validated* when passed
>> to TomEE in the "Authorization" header of any HTTP request.
>>
>> But, absolutely yes that validation would be done without the need for
>> any third-party libraries.  The assumption is that TomEE would need to be
>> given the RSA public key corresponding to the private key the token server
>> used to create the JWT.
>>
>> After validation, there are three groups of additional features to make
>> things convenient for developers:
>>
>>   - Identity: The server is required to propagate the JWT `sub` to
>> getCallerPrinciple() and similar existing calls in various Java EE apis
>>
>>   - Permissions: `@RolesAllowed` finally becomes useful as the server is
>> required to honor the JWT `scopes` claim in uses of `@RolesAllowed` and
>> `isCallerInRole()`
>>
>>   - Claims:  Any other values of the incoming JWT can be injected into
>> your code via CDI `@Inject @Claim("foo")` as a handful of different data
>> types.  I.e. you can use it as a secure cookie if you want and do not need
>> to write any parsing code.
>>
>> You still need something to create the tokens, which could be done with
>> an API Gateway or some code you write.  You wouldn't put that code on all
>> microservices as the power of JWT is that there's one source of identity
>> that the enterprise trusts so that should be some fairly small set of very
>> secure servers who hold the private key and do not share it.
>>
>> Hope that puts some color on it.  We'll want to document the feature and
>> this is a good start, so more questions the better.
>>
>>
>> -David
>>
>>
>

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Le 29 mars 2018 03:29, "David Blevins" <david.blev...@gmail.com> a écrit :

> On Mar 28, 2018, at 1:21 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
>
> Just move the "main" code to the repo created @G and import the new lib in
> tomee MP as Roberto did for config. Nothing blocking JL to do them at all.

I will need to include the recent discussion in the April board report and
I want to fairly represent everyone's votes.

Is your -1 on the basis that the code must be moved to Geronimo?


That + the fact tomee is not and shouldnt become a put it all project just
become of scm perms IMO but stay an integration project to keep sense and
not mess up its own image and mess up the quality of our reusable libs.



-David

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

@Jon: drop some SE style code to move to CDI style and allow apps to
override "naturally" impls + droppring jose dep are the main ones. Some
optim in the Bean impl should pby be planned too but can need some more
investment and are less blocking for a 1.0.0.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-28 10:46 GMT+02:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:

> Yes it would allow that.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Wed, Mar 28, 2018 at 10:22 AM, Matthew Broadhead <
> matthew.broadh...@nbmlaw.co.uk> wrote:
>
> > would it allow configuration of an oauth endpoint in TomEE and then
> > defining security-constraint in the web.xml of a webapp?  seems like a
> good
> > plan if it drops the need for 3rd party libs
> >
> >
> > On 28/03/2018 10:15, Romain Manni-Bucau wrote:
> >
> >> Hi Matthew,
> >>
> >> it is an impl of https://github.com/eclipse/microprofile-jwt-auth
> >>
> >> Normally with a JWT you can drop these things as well - can need some
> >> wrapper to handle the representation in a less raw way but nothing
> crazy.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <https://www.packtpub.com/application-development/java-ee-8-
> >> high-performance>
> >>
> >> 2018-03-28 10:10 GMT+02:00 Matthew Broadhead <
> >> matthew.broadh...@nbmlaw.co.uk
> >>
> >>> :
> >>> is this about JSON web tokens or some other JWT?
> >>> is this JWT library similar to something like the keycloak tomcat
> >>> adapter?
> >>> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
> >>> ava/tomcat-adapter.html
> >>> if so is there a specification on this and do different IDPs handle
> this
> >>> differently.  i.e. if TomEE had a JWT adapter would it no longer need
> the
> >>> keycloak adapter?
> >>> for instance the keycloak includes structures like UserRepresentation,
> >>> RoleRepresentation, CredentialRepresentation. would this be handled in
> a
> >>> new JWT lib?
> >>>
> >>>
> >>> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
> >>>
> >>> Roberto PR *is* merged JL.
> >>>> He did the work to be able to consume any CDI "container" lib.
> >>>>
> >>>> So I'd just extract the code as we discussed together in G before that
> >>>> mess
> >>>> and move forward to keep TCK and add the lib in the MP distro Roberto
> >>>> created to fit that design.
> >>>>
> >>>> As soon as you imported the lib in G, I will make sure to help to make
> >>>> it
> >>>> releasable.
> >>>>
> >>>> As the ee concurrency utilities dev I can guarantee you it is wrong to
> >>>> put
> >>>> it in TomEE :( - mea culpa here.
> >>>>
> >>>> I can understand the "i cant commit" but you can PR and several of
> these
> >>>> objections are coming from people willing RTC which leads to the same
> >>>> blocking state so not sure I get the rational to break projects here
> and
> >>>> make them messy which would deserve asf IMHO.
> >>>>
> >>>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <
> >>>> jonathan.gallim...@gmail.com
> >>>> a écrit :
> >>>>
> >>>> If it can sit in its own repository, and that improves re-usability,
> >>>> that
> >>>>
> >>>>> sounds like a good thing to me. I'd be happy with that under the
> TomEE
> >>>>> TLP.
> >>>>> I am sure some folks will prefer to see it under Geronimo. I am a
> TomEE
> >>>>> committer, I am not yet a Geronimo committer (maybe so

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

2018-03-28 10:22 GMT+02:00 Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk
>:

> would it allow configuration of an oauth endpoint in TomEE and then
> defining security-constraint in the web.xml of a webapp?  seems like a good
> plan if it drops the need for 3rd party libs


It is a "client" lib and in web.xml you can put "MP-JWT" to ensure the JWT
are validated and propagated to the request. (= validation side, not
emittion)


>
>
> On 28/03/2018 10:15, Romain Manni-Bucau wrote:
>
>> Hi Matthew,
>>
>> it is an impl of https://github.com/eclipse/microprofile-jwt-auth
>>
>> Normally with a JWT you can drop these things as well - can need some
>> wrapper to handle the representation in a less raw way but nothing crazy.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-
>> high-performance>
>>
>>
>> 2018-03-28 10:10 GMT+02:00 Matthew Broadhead <
>> matthew.broadh...@nbmlaw.co.uk
>>
>>> :
>>> is this about JSON web tokens or some other JWT?
>>> is this JWT library similar to something like the keycloak tomcat
>>> adapter?
>>> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
>>> ava/tomcat-adapter.html
>>> if so is there a specification on this and do different IDPs handle this
>>> differently.  i.e. if TomEE had a JWT adapter would it no longer need the
>>> keycloak adapter?
>>> for instance the keycloak includes structures like UserRepresentation,
>>> RoleRepresentation, CredentialRepresentation. would this be handled in a
>>> new JWT lib?
>>>
>>>
>>> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
>>>
>>> Roberto PR *is* merged JL.
>>>> He did the work to be able to consume any CDI "container" lib.
>>>>
>>>> So I'd just extract the code as we discussed together in G before that
>>>> mess
>>>> and move forward to keep TCK and add the lib in the MP distro Roberto
>>>> created to fit that design.
>>>>
>>>> As soon as you imported the lib in G, I will make sure to help to make
>>>> it
>>>> releasable.
>>>>
>>>> As the ee concurrency utilities dev I can guarantee you it is wrong to
>>>> put
>>>> it in TomEE :( - mea culpa here.
>>>>
>>>> I can understand the "i cant commit" but you can PR and several of these
>>>> objections are coming from people willing RTC which leads to the same
>>>> blocking state so not sure I get the rational to break projects here and
>>>> make them messy which would deserve asf IMHO.
>>>>
>>>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <
>>>> jonathan.gallim...@gmail.com
>>>> a écrit :
>>>>
>>>> If it can sit in its own repository, and that improves re-usability,
>>>> that
>>>>
>>>>> sounds like a good thing to me. I'd be happy with that under the TomEE
>>>>> TLP.
>>>>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>>>>> committer, I am not yet a Geronimo committer (maybe someday) so I
>>>>> would
>>>>> lean towards TomEE. Wherever it sits, it needs to be possible to work
>>>>> on
>>>>> it
>>>>> without being blocked.
>>>>>
>>>>> Jon
>>>>>
>>>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>>>>> jlmonte...@tomitribe.com> wrote:
>>>>>
>>>>> What about this vote David?
>>>>>
>>>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>>>>>>
>>>>>> not
>>>>>
>>>>> merged.
>>>>>> Most of the JWT code is server independent and therefor could be
>>>>>>
>>>>>> extracted
>>>>>
>>>>> into a separate library.
>>>>>>
>>>>>> So where the code sits is definitely a question we need to address.
>>>>>> I don't believe the current TomEE repo is a good ho

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

2018-03-28 10:17 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> On Wed, Mar 28, 2018 at 6:13 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > Roberto PR *is* merged JL.
> > He did the work to be able to consume any CDI "container" lib.
> >
> > So I'd just extract the code as we discussed together in G before that
> mess
> > and move forward to keep TCK and add the lib in the MP distro Roberto
> > created to fit that design.
> >
> > As soon as you imported the lib in G, I will make sure to help to make it
> > releasable.
> >
>
> What does that mean? What are the changes you're proposing, and why can't
> Jean-Louis do them?
>

Just move the "main" code to the repo created @G and import the new lib in
tomee MP as Roberto did for config. Nothing blocking JL to do them at all.


>
> Jon
>

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Hi Matthew,

it is an impl of https://github.com/eclipse/microprofile-jwt-auth

Normally with a JWT you can drop these things as well - can need some
wrapper to handle the representation in a less raw way but nothing crazy.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-28 10:10 GMT+02:00 Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk
>:

> is this about JSON web tokens or some other JWT?
> is this JWT library similar to something like the keycloak tomcat adapter?
> http://www.keycloak.org/docs/2.5/securing_apps/topics/oidc/j
> ava/tomcat-adapter.html
> if so is there a specification on this and do different IDPs handle this
> differently.  i.e. if TomEE had a JWT adapter would it no longer need the
> keycloak adapter?
> for instance the keycloak includes structures like UserRepresentation,
> RoleRepresentation, CredentialRepresentation. would this be handled in a
> new JWT lib?
>
>
> On 28/03/2018 07:13, Romain Manni-Bucau wrote:
>
>> Roberto PR *is* merged JL.
>> He did the work to be able to consume any CDI "container" lib.
>>
>> So I'd just extract the code as we discussed together in G before that
>> mess
>> and move forward to keep TCK and add the lib in the MP distro Roberto
>> created to fit that design.
>>
>> As soon as you imported the lib in G, I will make sure to help to make it
>> releasable.
>>
>> As the ee concurrency utilities dev I can guarantee you it is wrong to put
>> it in TomEE :( - mea culpa here.
>>
>> I can understand the "i cant commit" but you can PR and several of these
>> objections are coming from people willing RTC which leads to the same
>> blocking state so not sure I get the rational to break projects here and
>> make them messy which would deserve asf IMHO.
>>
>> Le 27 mars 2018 23:37, "Jonathan Gallimore" <jonathan.gallim...@gmail.com
>> >
>> a écrit :
>>
>> If it can sit in its own repository, and that improves re-usability, that
>>> sounds like a good thing to me. I'd be happy with that under the TomEE
>>> TLP.
>>> I am sure some folks will prefer to see it under Geronimo. I am a TomEE
>>> committer, I am not yet a Geronimo committer (maybe someday) so I
>>> would
>>> lean towards TomEE. Wherever it sits, it needs to be possible to work on
>>> it
>>> without being blocked.
>>>
>>> Jon
>>>
>>> On Tue, Mar 27, 2018 at 10:27 PM, Jean-Louis Monteiro <
>>> jlmonte...@tomitribe.com> wrote:
>>>
>>> What about this vote David?
>>>>
>>>> Roberto's PR for MP-Config integration and mine about MP-JWT are still
>>>>
>>> not
>>>
>>>> merged.
>>>> Most of the JWT code is server independent and therefor could be
>>>>
>>> extracted
>>>
>>>> into a separate library.
>>>>
>>>> So where the code sits is definitely a question we need to address.
>>>> I don't believe the current TomEE repo is a good home.
>>>>
>>>> TomEE as the Apache TLP can on the other hand become an home.
>>>> We only need another another repo where we could put some reusable code.
>>>>
>>>> There are a couple of utility classes in TomEE that could also become a
>>>> reusable library.
>>>> I have prepared and pushed the 2 PRs for Chatterbox and Sheldon
>>>> donation.
>>>>
>>>> So I would probably propose to create a dedicated git repo where we
>>>> could
>>>> put all the reusable parts.
>>>> One benefit I see is that we could make the TomEE codebase a bit
>>>> lighter.
>>>>
>>>> What do you guys think?
>>>>
>>>>
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>> On Thu, Mar 22, 2018 at 10:47 AM, Matthew Broadhead <
>>>> matthew.broadh...@nbmlaw.co.uk> wrote:
>>>>
>>>> does this mean a reusable JWT library external to TomEE, or within the
>>>>> TomEE project?
>>>>> i have to agree with previous statements i read that TomEE is a bundle
>

Re: MP-JWT progress

[Romain Manni-Bucau]

Personally I'd prefer to do it directly as ut will be since there is no
technical challenge at all.


Le 27 mars 2018 23:39, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

> I'm currently pulling the TomEE sandbox to Git from SVN. Seems like a long
> process, I'll post when it is done. I'd be supportive of experimental work
> taking place there. When its at the point of being released, I'd prefer it
> to have its own repo.
>
> Jon
>
> On Tue, Mar 27, 2018 at 10:32 PM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > I've tried to answer the 2 VOTE threads.
> >
> > Another option is to merge and immediately extract the code into a
> sandbox
> > project so everyone can clearly see what is reusable or not.
> > Would that help?
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Mon, Mar 19, 2018 at 11:08 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > wrote:
> >
> > > Used most to be explicit and my meaning but your wording is more
> correct.
> > >
> > >
> > > Le 19 mars 2018 22:46, "Mark Struberg" <strub...@yahoo.de.invalid> a
> > > écrit :
> > >
> > > > heh yea, just keep it going. But keep the idea of probably having
> > > > something tomee independent in the back of your head please!
> > > > It's not that we need to go through incubator if we want to move
> things
> > > > over to Geronimo later. But it would still be great to avoid
> > duplications
> > > > if possible.
> > > > > Jwt-auth impl doesnt depend on tomee and is reusable so must not be
> > put
> > > > in tomee codebase
> > > > Being french I assume you don't mean 'must not' but rather 'doesn't
> > need
> > > > to' or rather 'should not', isn't?
> > > > Of course people _can_ put it into TomEE. It's just that it doesn't
> > make
> > > > the most sense from an ASF wide approach. That doesn't mean that it's
> > not
> > > > allowed.
> > > >
> > > > LieGrue,strub
> > > >
> > > >
> > > >
> > > > On Monday, 19 March 2018, 21:46:17 CET, Andy Gumbrecht <
> > > > agumbre...@tomitribe.com> wrote:
> > > >
> > > >  Totally agree Mark! So not sure where the issue lays if any? I just
> > > > don't see a problem with accepting contributions and refactoring if
> > > > required in order to get the ball rolling, rather than staring at the
> > > > ball until becomes a cube, or waiting for it to be a perfect pyramid
> > ;-)
> > > >
> > > >
> > > > On 19/03/18 17:03, Mark Struberg wrote:
> > > > >
> > > > >On Monday, 19 March 2018, 11:05:21 CET, Andy Gumbrecht <
> > > > agumbre...@tomitribe.com> wrote:  > I don't see TomEE as the center
> of
> > > > the world, but somewhere where people
> > > > >> should be free to work without constantly being told it's not OK
> to
> > do
> > > > so.
> > > > > No, I didn't mean it that way. It's perfectly fine to do things in
> > > TomEE
> > > > of course. And again: TomEE IS important. But if we hit some CDI
> > problem
> > > > then we should try to fix it 'upstream' in OpenWebBeans - and not in
> > > TomEE.
> > > > And if we hit JAX-RS issues then we should try to fix it in CXF - and
> > not
> > > > in TomEE. Got me?
> > > > >
> > > > > You know that we had lots of duplication and hacks in TomEE to
> > 'tweak'
> > > > OWB. And it did really hurt when the spec did evolve. We cleaned that
> > up
> > > > and the code is now much easier to maintain.
> > > > > The thing I wanted to express is that the barriers for existing ASF
> > > > commiters are pretty low. If possible then we should fix things where
> > > they
> > > > belong to. Yes, sometimes it might be the easiest/quickest to just
> add
> > a
> > > > workaround in TomEE. But often that is not the _correct_ way to do
> it.
> > > And
> > > > in the long term it adds maintenance costs.
> > > > >
> > > > > I have to admit that I did just roughly glimpsed over the JWT work,
> > so
> > > I
> > > > cannot even judge whether the JWT part makes sense for Geronimo or
> not.
> > > > Will try to catch up in the next few days.
> > > > > LieGrue,strub
> > > > >
> > > > >
> > > >
> > > > --
> > > > Andy Gumbrecht
> > > > https://twitter.com/AndyGeeDe
> > > > http://www.tomitribe.com
> > > > https://www.tomitribe.io
> > > >
> > > >
> > > > Ubique
> > > >
> > > >
> > >
> >
>

Re: Propose a Logo for TomEE

[Romain Manni-Bucau]

You can, probably just use "Logo Contest" thread as the way to do it.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-27 15:28 GMT+02:00 Richard Monson-Haefel <rmon...@tomitribe.com>:

> So would you mind if I posted the proposal to the users mailing list?
>
> On Tue, Mar 27, 2018 at 8:09 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > 2018-03-27 15:03 GMT+02:00 Richard Monson-Haefel <rmon...@tomitribe.com
> >:
> >
> > > Is this something that would be put to a vote for the committees only
> or
> > > would it include the users?  Sorry, the process is not clear to me but
> I
> > > would like to make it an official proposal even if you don’t believe
> that
> > > there is an interest.
> > >
> >
> > There is no official process. At tomee we tend to let users drive (as
> > "influence the most") this kind of things
> > and just serve their will.
> >
> >
> > >
> > > Btw - I’m a member of Tomitribe but this logo proposal has nothing to
> do
> > > with that organization. It’s a personal contribution.
> > >
> >
> > Guessed so when I saw the twitter thread ;)
> >
> >
> > >
> > > On Mon, Mar 26, 2018 at 3:15 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Le 26 mars 2018 21:11, "Richard Monson-Haefel" <
> rmon...@tomitribe.com>
> > a
> > > > écrit :
> > > >
> > > > I can do that, but I wanted to just get some first reactions. Your
> > > > reaction is admittedly disappointing.  Why is there no hope?  I don't
> > see
> > > > TomEE using any of the existing logos proposed. Is it because no one
> > > really
> > > > cares about that or is there some other reason.  Thanks!
> > > >
> > > >
> > > > Some care(d) but gave up after months of discussion with a single
> logo
> > > > proposal and an aborted contest with 27 cool logos.
> > > >
> > > >
> > > > On Sun, Mar 25, 2018 at 10:00 AM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Richard,
> > > > >
> > > > > You can add one on https://issues.apache.org/jira/browse/TOMEE-574
> > but
> > > > the
> > > > > contest is actually dead and there is no discussion to change the
> > logo
> > > > ATM
> > > > > so don't get too much hope.
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <https://www.packtpub.com/application-development/java-
> > > > > ee-8-high-performance>
> > > > >
> > > > > 2018-03-25 16:36 GMT+02:00 Richard Monson-Haefel <
> > > rmon...@tomitribe.com
> > > > >:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I created a few logos for the Jakarta EE logo "contest" my best
> one
> > > was
> > > > > > rejected because the Island of Java has tigers on it - go figure.
> > > > > >
> > > > > > Anyway, before I file away the logos for good I thought I would
> > offer
> > > > the
> > > > > > best one I have to the TomEE project.  I know in the past you
> have
> > > gone
> > > > > > through the logo selection but it doesn't look like you actually
> > > > adopted
> > > > > > one.  I thought maybe this one might be desirable.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Richard
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > --
> > > Richard Monson-Haefel
> > > http://twitter.com/rmonson
> > > http://www.tomitribe.com
> > > http://www.tomitribe.io
> > >
> >
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>

Re: [DISCUSS] switching TomEE8 to master

[Romain Manni-Bucau]

Hi Felipe, your issue is not linked to tomee I think


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-27 15:23 GMT+02:00 Felipe Jaekel <fkjae...@gmail.com>:

> Hi,
>
> I'm also looking forward for this release, since a issue I'm facing with
> 7.0.4(TOMEE-2181 <https://issues.apache.org/jira/browse/TOMEE-2181>) is
> fixed on 7.0.5.
>
> Thanks
>
> Em ter, 27 de mar de 2018 às 08:57, Alex The Rocker <alex.m3...@gmail.com>
> escreveu:
>
> > Hello All,
> >
> > Is there any  possibility to see a TomEE 7.0.5 release anytime soon
> > with an up to date Johnzon 1.1.x in it ?
> >
> > Best regards,
> > Alexandre
> >
> >
> > 2018-03-04 15:12 GMT+01:00 Alex The Rocker <alex.m3...@gmail.com>:
> > > Oops my bad: please read in my previous mail that I just opened
> > JOHNZON-160:
> > >
> > https://issues.apache.org/jira/browse/JOHNZON-160?jql=
> text%20~%20%22MapperException%22
> > >
> > > Thanks,
> > > Alexandre
> > >
> > > 2018-03-04 15:08 GMT+01:00 Alex The Rocker <alex.m3...@gmail.com>:
> > >> Hello Romain & Mark,
> > >>
> > >> Yes I already filled a generic JIRA JOHNZON-149 a while ago for asking
> > >> Johnzon upgrade to 1.1.x in TomEE 7.0.5.
> > >>
> > >> And I just filled JOHNZON-105 with a more specific JSON-B/Mapper
> issue:
> > >>
> > https://issues.apache.org/jira/projects/JOHNZON/issues/
> JOHNZON-105?filter=allopenissues
> > >>
> > >> It would be great to have a fix for it in upcoming TomEE 7.0.5, along
> > >> with latest security updates on embedded components (Tomcat, etc..)
> > >>
> > >> I will provide feedbacks with our large & complex web apps as soon as
> > >> there's something testable as a snapshot (or I can built stuff with
> > >> Maven, but i'll need by steps to make sure I'm pointing to appropriate
> > >> repos/versions/tags)
> > >>
> > >> Best regards,
> > >> Alex
> > >>
> > >>
> > >> 2018-03-04 14:46 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > >>> @Mark: it is tracked on johnzon (
> > >>>
> > https://issues.apache.org/jira/plugins/servlet/mobile#issue/JOHNZON-149
> ).
> > >>> There was the proposal I did months ago to just use jsonp/b 1.1/1.0
> in
> > >>> tomee 7 (doesnt prevent anything from tomee perspective if we drop
> > java 7
> > >>> compat). If not desired we should redo 1.x from master pby to avoid
> an
> > half
> > >>> merged branch.
> > >>>
> > >>> Le 4 mars 2018 12:40, "Mark Struberg" <strub...@yahoo.de.invalid> a
> > écrit :
> > >>>
> > >>>> Hi Alex!
> > >>>>
> > >>>> johnzon-1.0.x is targetting JSON-P_1.0 (EE7) and johnzon-1.0.0 is
> > indeed
> > >>>> the last version we shipped so far.
> > >>>>
> > >>>> johnzon-1.1.x is targetting JSON-P_1.1 and JSON-B_1.0.
> > >>>> Those are all EE8 specs and thus this is also the version used in
> > TomEE8.
> > >>>>
> > >>>> If you have some urgent need/request for a fix in Johnzon-1.0.x
> (EE7)
> > then
> > >>>> please identify the tickets you suggest to have fixed and report
> them
> > on
> > >>>> the d...@johnzon.apache.org list.
> > >>>> What could work is if you go through either the tickets resolved in
> > >>>> various johnzon-1.1.x versions, or scan the git log for fixes you
> > want to
> > >>>> have backported.
> > >>>> We will then discuss it over there, create tickets and then merge
> > back the
> > >>>> stuff.
> > >>>> The Johnzon team is surely happy about every helping hand!
> > >>>>
> > >>>> Btw, that's really the same for almost all the parts of TomEE.
> > >>>> 85% of the tickets and improvements are really happening at all the
> > other
> > >>>> projects: johnzon, bval, OpenWebBeans, OpenJPA, MyFaces, Tomcat,
> 

Re: Propose a Logo for TomEE

[Romain Manni-Bucau]

2018-03-27 15:03 GMT+02:00 Richard Monson-Haefel <rmon...@tomitribe.com>:

> Is this something that would be put to a vote for the committees only or
> would it include the users?  Sorry, the process is not clear to me but I
> would like to make it an official proposal even if you don’t believe that
> there is an interest.
>

There is no official process. At tomee we tend to let users drive (as
"influence the most") this kind of things
and just serve their will.


>
> Btw - I’m a member of Tomitribe but this logo proposal has nothing to do
> with that organization. It’s a personal contribution.
>

Guessed so when I saw the twitter thread ;)


>
> On Mon, Mar 26, 2018 at 3:15 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Le 26 mars 2018 21:11, "Richard Monson-Haefel" <rmon...@tomitribe.com> a
> > écrit :
> >
> > I can do that, but I wanted to just get some first reactions. Your
> > reaction is admittedly disappointing.  Why is there no hope?  I don't see
> > TomEE using any of the existing logos proposed. Is it because no one
> really
> > cares about that or is there some other reason.  Thanks!
> >
> >
> > Some care(d) but gave up after months of discussion with a single logo
> > proposal and an aborted contest with 27 cool logos.
> >
> >
> > On Sun, Mar 25, 2018 at 10:00 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi Richard,
> > >
> > > You can add one on https://issues.apache.org/jira/browse/TOMEE-574 but
> > the
> > > contest is actually dead and there is no discussion to change the logo
> > ATM
> > > so don't get too much hope.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <https://www.packtpub.com/application-development/java-
> > > ee-8-high-performance>
> > >
> > > 2018-03-25 16:36 GMT+02:00 Richard Monson-Haefel <
> rmon...@tomitribe.com
> > >:
> > >
> > > > Hi,
> > > >
> > > > I created a few logos for the Jakarta EE logo "contest" my best one
> was
> > > > rejected because the Island of Java has tigers on it - go figure.
> > > >
> > > > Anyway, before I file away the logos for good I thought I would offer
> > the
> > > > best one I have to the TomEE project.  I know in the past you have
> gone
> > > > through the logo selection but it doesn't look like you actually
> > adopted
> > > > one.  I thought maybe this one might be desirable.
> > > >
> > > > Thanks,
> > > >
> > > > Richard
> > > >
> > > >
> > > >
> > >
> >
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>

Re: Propose a Logo for TomEE

[Romain Manni-Bucau]

Le 26 mars 2018 21:11, "Richard Monson-Haefel" <rmon...@tomitribe.com> a
écrit :

I can do that, but I wanted to just get some first reactions. Your
reaction is admittedly disappointing.  Why is there no hope?  I don't see
TomEE using any of the existing logos proposed. Is it because no one really
cares about that or is there some other reason.  Thanks!


Some care(d) but gave up after months of discussion with a single logo
proposal and an aborted contest with 27 cool logos.


On Sun, Mar 25, 2018 at 10:00 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Hi Richard,
>
> You can add one on https://issues.apache.org/jira/browse/TOMEE-574 but the
> contest is actually dead and there is no discussion to change the logo ATM
> so don't get too much hope.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-03-25 16:36 GMT+02:00 Richard Monson-Haefel <rmon...@tomitribe.com>:
>
> > Hi,
> >
> > I created a few logos for the Jakarta EE logo "contest" my best one was
> > rejected because the Island of Java has tigers on it - go figure.
> >
> > Anyway, before I file away the logos for good I thought I would offer
the
> > best one I have to the TomEE project.  I know in the past you have gone
> > through the logo selection but it doesn't look like you actually adopted
> > one.  I thought maybe this one might be desirable.
> >
> > Thanks,
> >
> > Richard
> >
> >
> >
>

Re: Propose a Logo for TomEE

[Romain Manni-Bucau]

2018-03-25 17:16 GMT+02:00 Ivan Junckes Filho <ivanjunc...@gmail.com>:

> Hey guys, even though the old contest is dead. I would love if TomEE had a
> cool logo, we probably should reopen the discussion as Richard is willing
> to provide some logos :)
>
> Richard, can you send the logos to this email? I don't see them in your
> email.
>

maybe attach it to jira, generally half of the clients don't get the
attached files :(


>
> On Sun, Mar 25, 2018 at 12:00 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > Hi Richard,
> >
> > You can add one on https://issues.apache.org/jira/browse/TOMEE-574 but
> the
> > contest is actually dead and there is no discussion to change the logo
> ATM
> > so don't get too much hope.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
> > 2018-03-25 16:36 GMT+02:00 Richard Monson-Haefel <rmon...@tomitribe.com
> >:
> >
> > > Hi,
> > >
> > > I created a few logos for the Jakarta EE logo "contest" my best one was
> > > rejected because the Island of Java has tigers on it - go figure.
> > >
> > > Anyway, before I file away the logos for good I thought I would offer
> the
> > > best one I have to the TomEE project.  I know in the past you have gone
> > > through the logo selection but it doesn't look like you actually
> adopted
> > > one.  I thought maybe this one might be desirable.
> > >
> > > Thanks,
> > >
> > > Richard
> > >
> > >
> > >
> >
>

Re: Propose a Logo for TomEE

[Romain Manni-Bucau]

Hi Richard,

You can add one on https://issues.apache.org/jira/browse/TOMEE-574 but the
contest is actually dead and there is no discussion to change the logo ATM
so don't get too much hope.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-25 16:36 GMT+02:00 Richard Monson-Haefel <rmon...@tomitribe.com>:

> Hi,
>
> I created a few logos for the Jakarta EE logo "contest" my best one was
> rejected because the Island of Java has tigers on it - go figure.
>
> Anyway, before I file away the logos for good I thought I would offer the
> best one I have to the TomEE project.  I know in the past you have gone
> through the logo selection but it doesn't look like you actually adopted
> one.  I thought maybe this one might be desirable.
>
> Thanks,
>
> Richard
>
>
>

Re: What is this project?

[Romain Manni-Bucau]

This approach is fine and where I disagree - but as you said one of the
beauty of asf is to be allowed to "disagree" - and dislike it a lot is that
it is a tomee central vision instead of considering asf as the central
point.

To try to illustrate it I'll take a car example: you can optimise the
thermic part of an engine, you can optimize the mecanic part, you can
optimize the electronic part. You will get the very best of each and some
figures for the car (perf/price/autonomy/...). Now if you start thinking
car wide you will degrade the mecanic part a bit, degrade the electronic
etc...and gain like 30% on the overall perf and price cause you dont look
locally but globally. A global optimum is rarely also a local optimum (only
in 1 case actually). This is why mecatronic and thinking globally is more
efficient than specialties in general and why just speaking of tomee sounds
like not going very far to me.

Le 22 mars 2018 03:04, "David Blevins"  a écrit :

> > On Mar 19, 2018, at 2:45 AM, Mark Struberg 
> wrote:
> >
> > Let's face it TomEE is mostly an aggregator. A great one, I really love
> it - but still.
> > [...]
> > Folks, you have to stop thinking as TomEE as being the center of the
> world. I love TomEE and it's a great aggregator and a great community.
>
> Everyone is free to have a perspective on what this project is and it's ok
> for it not to be the same.  It almost never is.  It ebbs and it flows and
> that is natural.  As long as we're clear when we say "TomEE is..." we are
> expressing our own opinions, we're ok.
>
> People tend to think of the project in terms of when they came in.  Their
> "OpenEJB is x" or "TomEE is x" seems to reflect around the time they got
> commit.
>
> I've put together a timeline of how I've experienced the project.  I think
> people should dream for more.  It's the best part about open source and
> what got us even this far.
>
> If you look at this timeline you see all the growth periods are people
> deciding that this is where they wanted to work and they we're the most
> flexible on what that was.  Even to the point of turning an EJB container
> into a Java EE platform.
>
> --
> 1999-2001
>
> Project is born as an EJB library.  Not quite a full EJB implementation.
> It is envisioned as an EJB Container with the EJB Server part being
> implemented by a full app server.  The vision was to strategically not
> implement the server part so true app servers would integrate the project
> as a library.  Resources are abundant, people are everywhere.
>
> Many people on the project want to implement the server portion and make
> the project more than it is.  Myself and Richard tell them no.  Speaking
> for myself, I was a newbie idiot in this phase of the project.
>
> 2001-2003
>
> Funding has dropped from the project, everyone from the original community
> but Daniel, Jacek and Alan have gone.  I see it now as a full EJB
> implementation and perhaps a bit more.  The Tomcat integration is born so
> Tomcat can have an EJB implementation.  The embedded EJB container for
> testing is heavily pushed.  The full remote protocol is created.  The
> project is now bigger than its original scope, but only slightly.
> Generally, there are no resources and not many people around.
>
> 2003-2006
>
> Geronimo is launched and the project is flooded with new people excited
> about Geronimo's future.  OpenEJB 1.0 is abandoned for OpenEJB 2.0 which is
> a total rewrite of EJB on the Geronimo kernel and module system.  Tomcat
> integration and embedded EJB concepts are trashed.  I still see this as a
> project that can live on its own and be more and something I'd love to see
> grow in scope.  Everyone on Geronimo, but me, sees it as a library for
> Geronimo only.  At one point I pull the remote EJB code from OpenEJB 1.0
> into OpenEJB 2.0 and people got quietly mad for bringing "legacy" code
> forward.  The mailing list is dead in these years with most discussion and
> decisions made on the Geronimo list.  The project is now significantly
> smaller than its original scope, everyone is telling me to stop trying to
> make it more.  There is a lot of fighting in this time frame.
>
> 2006-2010
>
> Work on OpenEJB 3.0 starts and this project regains technical freedom from
> Geronimo.  Dain Sundstrom leaves Geronimo in this timeframe, wants to make
> up for killing OpenEJB 1.0 and puts his weight behind OpenEJB 3.0.  OpenEJB
> 3.0 is based on OpenEJB 1.0 and the work towards an embeddable EJB
> container and a Tomcat integration continue where they left off.  There was
> some discomfort, skepticism and grumbling in the Geronimo community but
> largely ripping out the old EJB container and putting in the new old EJB
> container was tolerated.  Enjoyed, no, tolerated, yes.  It was enjoyed
> perhaps a bit later.  The embeddable container is a strong feature and
> brings new people into the project.
>
> The project is bigger than any of the 

Re: MP-JWT progress

[Romain Manni-Bucau]

Used most to be explicit and my meaning but your wording is more correct.


Le 19 mars 2018 22:46, "Mark Struberg"  a écrit :

> heh yea, just keep it going. But keep the idea of probably having
> something tomee independent in the back of your head please!
> It's not that we need to go through incubator if we want to move things
> over to Geronimo later. But it would still be great to avoid duplications
> if possible.
> > Jwt-auth impl doesnt depend on tomee and is reusable so must not be put
> in tomee codebase
> Being french I assume you don't mean 'must not' but rather 'doesn't need
> to' or rather 'should not', isn't?
> Of course people _can_ put it into TomEE. It's just that it doesn't make
> the most sense from an ASF wide approach. That doesn't mean that it's not
> allowed.
>
> LieGrue,strub
>
>
>
> On Monday, 19 March 2018, 21:46:17 CET, Andy Gumbrecht <
> agumbre...@tomitribe.com> wrote:
>
>  Totally agree Mark! So not sure where the issue lays if any? I just
> don't see a problem with accepting contributions and refactoring if
> required in order to get the ball rolling, rather than staring at the
> ball until becomes a cube, or waiting for it to be a perfect pyramid ;-)
>
>
> On 19/03/18 17:03, Mark Struberg wrote:
> >
> >On Monday, 19 March 2018, 11:05:21 CET, Andy Gumbrecht <
> agumbre...@tomitribe.com> wrote:  > I don't see TomEE as the center of
> the world, but somewhere where people
> >> should be free to work without constantly being told it's not OK to do
> so.
> > No, I didn't mean it that way. It's perfectly fine to do things in TomEE
> of course. And again: TomEE IS important. But if we hit some CDI problem
> then we should try to fix it 'upstream' in OpenWebBeans - and not in TomEE.
> And if we hit JAX-RS issues then we should try to fix it in CXF - and not
> in TomEE. Got me?
> >
> > You know that we had lots of duplication and hacks in TomEE to 'tweak'
> OWB. And it did really hurt when the spec did evolve. We cleaned that up
> and the code is now much easier to maintain.
> > The thing I wanted to express is that the barriers for existing ASF
> commiters are pretty low. If possible then we should fix things where they
> belong to. Yes, sometimes it might be the easiest/quickest to just add a
> workaround in TomEE. But often that is not the _correct_ way to do it. And
> in the long term it adds maintenance costs.
> >
> > I have to admit that I did just roughly glimpsed over the JWT work, so I
> cannot even judge whether the JWT part makes sense for Geronimo or not.
> Will try to catch up in the next few days.
> > LieGrue,strub
> >
> >
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

Jwt-auth impl doesnt depend on tomee and is reusable so must not be put in
tomee codebase.

Hope it is clearer this time.

Le 19 mars 2018 18:54, "John D. Ament" <johndam...@apache.org> a écrit :

> On Mon, Mar 19, 2018 at 3:20 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > 2018-03-19 0:07 GMT+01:00 John D. Ament <johndam...@apache.org>:
> >
> >>
> >>
> >> On Sun, Mar 18, 2018 at 5:38 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> Le 18 mars 2018 21:29, "David Blevins" <david.blev...@gmail.com> a
> >>> écrit :
> >>>
> >>>
> >>> > On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau <
> >>> rmannibu...@gmail.com> wrote:
> >>> >
> >>> > 1. code will be at geronimo - whatever happens at tomee
> >>>
> >>> As far as I understand the topic is still open and no git repos have
> >>> been created anywhere yet, is that right?
> >>>
> >>>
> >>> Yes
> >>>
> >>>
> >>> Is there anyone on the Geronimo side who would be open to collaborating
> >>> on a reusable JWT library under the TomEE project for a change?
> Something
> >>> not branded tomee or geronimo.
> >>>
> >>>
> >>> This is what was proposed to be created @g which is just an umbrella,
> no
> >>> more a project delivery by itself.
> >>>
> >>> Are you against/-1ing g-jwt-auth?
> >>>
> >>
> >> As mentioned elsewhere in the thread, I am against bringing something in
> >> geronimo that is TomEE specific.  I haven't looked at the code (as far
> as I
> >> can tell, nothing is linked in this thread so I have no idea if code
> even
> >> exists) but based on what I've seen with implementing JWT it's closely
> tied
> >> to your container.  So I don't believe its a good fit.
> >>
> >> Why is your preference to bring this into geronimo?
> >>
> >
> > As mentionned there is no link to TomEE in the jwt-auth codebase so no
> > reason to hold that code in something not reusable at tomee.
> >
>
>
> Too many negatives in that sentence to make sense of what you're trying to
> say.
>
>
> >
> >
> >>
> >>
> >>>
> >>>
> >>>
> >>> -David
> >>>
> >>>
> >>>
> >
>

Re: Git repos for sandbox and openejb-eclipse-plugin

[Romain Manni-Bucau]

2018-03-19 14:48 GMT+01:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> 1. We haven't. WTP functionality makes up about 50% of the plugin. It could
> be that the other 50% is no use to anyone, although it did have some users
> in the past. I'd like to at least work on it, and I'm ok if that is back in
> the sandbox. If that then moves to WTP, because that's best in the long
> run, that is cool with me.
>

Let's do it this way then (tomee then propose @wtp) rather than the
opposite since we have no entry point yet and are in minority for now.
Can be interesting to compete the idea integration which is promoted as
complete but not as much as your plugin ;).


>
> 2. I can't remember the mechanics of it, but we did manage it at one point
> - effectively the update site is an extracted zip, and that zip is a
> voted-upon artifact.
>

I thought - can be wrong - it was using svn which is now highly not
encouraged but anyway if we can make it it would ease the usage (but can be
done after a few releases).


>
> Cheers
>
> Jon
>
> On Mon, Mar 19, 2018 at 12:26 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > +1
> >
> > Side questions:
> >
> > 1. did we already try contributing to wtp?
> > 2. How to expose an update site at asf?
> >
> > Le 19 mars 2018 13:19, "Jonathan Gallimore" <
> jonathan.gallim...@gmail.com>
> > a écrit :
> >
> > > Hi
> > >
> > > As discussed here:
> > > http://tomee-openejb.979440.n4.nabble.com/MP-JWT-progress-
> > > tp4683480p4683612.html
> > >
> > > I'd like migrate our old SVN sandbox to a git repository.
> > >
> > > I've also had someone ping me (not on the mailing list) asking for the
> > > OpenEJB Eclipse Plugin - I'd therefore like to bring it up to date and
> > have
> > > a Git repository for that too.
> > >
> > > Does anyone object? If not, I'll create tomee-sandbox and
> > > tomee-eclipse-plugin and migrate those over.
> > >
> > > Thanks
> > >
> > > Jon
> > >
> >
>

Re: Git repos for sandbox and openejb-eclipse-plugin

[Romain Manni-Bucau]

+1

Side questions:

1. did we already try contributing to wtp?
2. How to expose an update site at asf?

Le 19 mars 2018 13:19, "Jonathan Gallimore" 
a écrit :

> Hi
>
> As discussed here:
> http://tomee-openejb.979440.n4.nabble.com/MP-JWT-progress-
> tp4683480p4683612.html
>
> I'd like migrate our old SVN sandbox to a git repository.
>
> I've also had someone ping me (not on the mailing list) asking for the
> OpenEJB Eclipse Plugin - I'd therefore like to bring it up to date and have
> a Git repository for that too.
>
> Does anyone object? If not, I'll create tomee-sandbox and
> tomee-eclipse-plugin and migrate those over.
>
> Thanks
>
> Jon
>

Re: MP-JWT progress

[Romain Manni-Bucau]

No nees to ask to move vode over sandbox, great idea Jon.

Le 19 mars 2018 12:10, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

> We used to have the concept of a sandbox which allowed folks to play with
> different ideas https://svn.apache.org/repos/asf/tomee/sandbox/. I it did
> a
> while back (ok, 10 years back - has it really been that long...?) for an
> Eclipse plugin. I think we need a safe place where experimentation can
> happen and code can be committed and worked on (that isn't just a PR). A
> number of things in the old sandbox have moved onto other places.
>
> If I sent a PR and it was whisked away to Geronimo, my immediate issue
> would be that I don't have commit access there, so I'm then restricted to
> sending in PRs.
>
> Jon
>
> On Mon, Mar 19, 2018 at 10:04 AM, Andy Gumbrecht <agumbre...@tomitribe.com
> >
> wrote:
>
> > I don't see TomEE as the center of the world, but somewhere where people
> > should be free to work without constantly being told it's not OK to do
> so.
> >
> >
> >
> > On 19/03/18 10:45, Mark Struberg wrote:
> >
> >> @Anydy and @David
> >> Let's face it TomEE is mostly an aggregator. A great one, I really love
> >> it - but still.
> >>   For example: apart from verifying and excluding all the broken TCKs I
> >> had probably 30 committs for TomEE8 which are really due to upgrades for
> >> EE8. Most of them have been CDI-2.0 adoptions and adopting to Tomcat
> >> behaviour changes.
> >> But apart from that Romain I had about 4000 commits in all the other
> >> projects, all for TomEE8. And there are many more people and projects
> >> involved which just get consumed by TomEE:
> >> * Tomcat* OpenWebBeans* MyFaces
> >> * Johnzon* OpenJPA* BVal* log4j* commons* BatchEE
> >> * various geronimo libs like * xbean, * geronimo-jta, *
> >> geronimo-javamail, tons of * geronimo-specs
> >> Folks, you have to stop thinking as TomEE as being the center of the
> >> world. I love TomEE and it's a great aggregator and a great community.
> >> But building TomEE is literally just the tip of the iceberg. All the
> work
> >> on the parts under the water - which is the vast majority - is done FOR
> >> TomEE but *not* AT TomEE!So don't fight those communities but embrace
> them.
> >>
> >> This is not a one way street.
> >> We (TomEE) should be really much more active in pointing that out TomEE
> >> contributors are perfectly welcome to tinker around in all the
> downstream
> >> projects as well. And the other way around.
> >> We need EACH OTHER! TomEE as kind of end-user projects which adds a huge
> >> adoption factor. And of course the components underneath as a rock solid
> >> base.
> >>
> >> LieGrue,strub
> >>
> >>
> >>  On Monday, 19 March 2018, 09:37:36 CET, Andy Gumbrecht <
> >> agumbre...@tomitribe.com> wrote:
> >> I think that if anyone feels like contributing to TomEE then we
> should
> >> allow and encourage that as soon as possible. The politics of where
> >> things should 'eventually' reside is a huge distraction and just serves
> >> to block any progress at the moment - The enthusiasm dies quickly after
> >> a week of back and forth. The first choice for anything should be TomEE,
> >> as that is the community we serve. The first response should be thank
> >> you, and we should accept the help offered. Then those that want to
> >> worry about extraction and reuse should feel free to go ahead and do
> >> that if they feel strongly enough about it. It should not be the
> >> priority for TomEE.
> >>
> >> The goal should be to get TomEE on the MP board as soon as possible. If
> >> that initially means TomEE 8, Java 8, and accepting a few PRs then we
> >> should press ahead with that now. Anything that might need back-porting
> >> can be addressed later.
> >>
> >> Andy.
> >>
> >>
> >> On 19/03/18 01:02, David Blevins wrote:
> >>
> >>> On Mar 18, 2018, at 2:38 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>> Are you against/-1ing g-jwt-auth?
> >>>>
> >>> I wouldn't do that, but it's also clear to me the discussion in this
> >>> thread can be significantly clearer.  Objections were made that weren't
> >>> resolved.  The discussion started as what do "we" do with we meaning
> TomEE
> >>> and Geronimo.  At some point in the middle it was stated Geronimo has
> >>> already made a decision.  I also have the feeling people may have
> opinions
> >>> that are in-between a full TomEE vs Geronimo decision, such as wanting
> to
> >>> put work into inching closer to get a better view before deciding.
> >>>
> >>> I think all these things are fine, but we need some healthy votes so
> >>> people can move forward with clear support.
> >>>
> >>>
> >>> -David
> >>>
> >>>
> >>>
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> > https://www.tomitribe.io
> >
> >
> > Ubique
> >
> >
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-19 11:04 GMT+01:00 Andy Gumbrecht <agumbre...@tomitribe.com>:

> I don't see TomEE as the center of the world, but somewhere where people
> should be free to work without constantly being told it's not OK to do so.


you describe ASF here ;)

However it is also important to not shout in our own foot and this is what
I try to do ensure we do having a single umbrella project. Goal is not to
prevent TomEE
to be "free" but really to make its community stronger and consistent
accross ASF and users.

A random example is: if we end up having geronimo-jwt-auth and
tomee-jwt-auth then what end users will use? How will tomee be perceived in
ASF ecosystem?
We always managed to have a strong and consistent ecosystem and it is what
I'm trying to promote with my warning on creating a jwt-auth @tomee which
would
split the efforts.

If the issue is the committership then this is something quickly fixes with
the contributions at asf so this must not be a blocker for the choice today.
People at tomee are great and a lot are worth having G committership once
passed the entering bar which is valuable contributions as on any asf
project. No
reason it doesn't happen.



>
>
>
> On 19/03/18 10:45, Mark Struberg wrote:
>
>> @Anydy and @David
>> Let's face it TomEE is mostly an aggregator. A great one, I really love
>> it - but still.
>>   For example: apart from verifying and excluding all the broken TCKs I
>> had probably 30 committs for TomEE8 which are really due to upgrades for
>> EE8. Most of them have been CDI-2.0 adoptions and adopting to Tomcat
>> behaviour changes.
>> But apart from that Romain I had about 4000 commits in all the other
>> projects, all for TomEE8. And there are many more people and projects
>> involved which just get consumed by TomEE:
>> * Tomcat* OpenWebBeans* MyFaces
>> * Johnzon* OpenJPA* BVal* log4j* commons* BatchEE
>> * various geronimo libs like * xbean, * geronimo-jta, *
>> geronimo-javamail, tons of * geronimo-specs
>> Folks, you have to stop thinking as TomEE as being the center of the
>> world. I love TomEE and it's a great aggregator and a great community.
>> But building TomEE is literally just the tip of the iceberg. All the work
>> on the parts under the water - which is the vast majority - is done FOR
>> TomEE but *not* AT TomEE!So don't fight those communities but embrace them.
>>
>> This is not a one way street.
>> We (TomEE) should be really much more active in pointing that out TomEE
>> contributors are perfectly welcome to tinker around in all the downstream
>> projects as well. And the other way around.
>> We need EACH OTHER! TomEE as kind of end-user projects which adds a huge
>> adoption factor. And of course the components underneath as a rock solid
>> base.
>>
>> LieGrue,strub
>>
>>
>>  On Monday, 19 March 2018, 09:37:36 CET, Andy Gumbrecht <
>> agumbre...@tomitribe.com> wrote:
>> I think that if anyone feels like contributing to TomEE then we should
>> allow and encourage that as soon as possible. The politics of where
>> things should 'eventually' reside is a huge distraction and just serves
>> to block any progress at the moment - The enthusiasm dies quickly after
>> a week of back and forth. The first choice for anything should be TomEE,
>> as that is the community we serve. The first response should be thank
>> you, and we should accept the help offered. Then those that want to
>> worry about extraction and reuse should feel free to go ahead and do
>> that if they feel strongly enough about it. It should not be the
>> priority for TomEE.
>>
>> The goal should be to get TomEE on the MP board as soon as possible. If
>> that initially means TomEE 8, Java 8, and accepting a few PRs then we
>> should press ahead with that now. Anything that might need back-porting
>> can be addressed later.
>>
>> Andy.
>>
>>
>> On 19/03/18 01:02, David Blevins wrote:
>>
>>> On Mar 18, 2018, at 2:38 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>>>> wrote:
>>>>
>>>> Are you against/-1ing g-jwt-auth?
>>>>
>>> I wouldn't do that, but it's also clear to me the discussion in this
>>> thread can be significantly clearer.  Objections were made that weren't
>>> resolved.  The discussion started as what do "we" do with we meaning TomEE
>>> and Geronimo.  At some point in the middle it was stated Geronimo has
>>> already made a decision.  I also have the feeling people may have opinions
>>> that are in-between a full TomEE vs Geronimo decision, such as wanting to
>>> put work into inching closer to get a better view before deciding.
>>>
>>> I think all these things are fine, but we need some healthy votes so
>>> people can move forward with clear support.
>>>
>>>
>>> -David
>>>
>>>
>>>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-19 9:37 GMT+01:00 Andy Gumbrecht <agumbre...@tomitribe.com>:

> I think that if anyone feels like contributing to TomEE then we should
> allow and encourage that as soon as possible. The politics of where things
> should 'eventually' reside is a huge distraction and just serves to block
> any progress at the moment - The enthusiasm dies quickly after a week of
> back and forth. The first choice for anything should be TomEE, as that is
> the community we serve. The first response should be thank you, and we
> should accept the help offered. Then those that want to worry about
> extraction and reuse should feel free to go ahead and do that if they feel
> strongly enough about it. It should not be the priority for TomEE.
>

Well, this has been discussed N times and TomEE always has been the second
choice. I am particularly unhappy it keeps coming back until it is TomEE
which will just kill TomEE as a project IMHO and it kills the effort as
well.


>
> The goal should be to get TomEE on the MP board as soon as possible. If
> that initially means TomEE 8, Java 8, and accepting a few PRs then we
> should press ahead with that now. Anything that might need back-porting can
> be addressed later.
>

This is actually what is done and as showed with MP-Config it works very
well this way:
1. impl @G
2. integration @T (keep in mind tomee is an integration project and not an
impl project otherwise we need to absorb cxf, activemp, openjpa,
openwebbeans, batchee, johnzon, ...)

This allows to use the projects in any CDI based application without having
the drawback of being tomee dependent which is not required by any MP spec.



>
> Andy.
>
>
>
> On 19/03/18 01:02, David Blevins wrote:
>
>> On Mar 18, 2018, at 2:38 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>>> wrote:
>>>
>>> Are you against/-1ing g-jwt-auth?
>>>
>> I wouldn't do that, but it's also clear to me the discussion in this
>> thread can be significantly clearer.  Objections were made that weren't
>> resolved.  The discussion started as what do "we" do with we meaning TomEE
>> and Geronimo.  At some point in the middle it was stated Geronimo has
>> already made a decision.  I also have the feeling people may have opinions
>> that are in-between a full TomEE vs Geronimo decision, such as wanting to
>> put work into inching closer to get a better view before deciding.
>>
>> I think all these things are fine, but we need some healthy votes so
>> people can move forward with clear support.
>>
>>
>> -David
>>
>>
>>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
> https://www.tomitribe.io
>
>
> Ubique
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-19 0:07 GMT+01:00 John D. Ament <johndam...@apache.org>:

>
>
> On Sun, Mar 18, 2018 at 5:38 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
>>
>>
>> Le 18 mars 2018 21:29, "David Blevins" <david.blev...@gmail.com> a
>> écrit :
>>
>>
>> > On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>> >
>> > 1. code will be at geronimo - whatever happens at tomee
>>
>> As far as I understand the topic is still open and no git repos have been
>> created anywhere yet, is that right?
>>
>>
>> Yes
>>
>>
>> Is there anyone on the Geronimo side who would be open to collaborating
>> on a reusable JWT library under the TomEE project for a change?  Something
>> not branded tomee or geronimo.
>>
>>
>> This is what was proposed to be created @g which is just an umbrella, no
>> more a project delivery by itself.
>>
>> Are you against/-1ing g-jwt-auth?
>>
>
> As mentioned elsewhere in the thread, I am against bringing something in
> geronimo that is TomEE specific.  I haven't looked at the code (as far as I
> can tell, nothing is linked in this thread so I have no idea if code even
> exists) but based on what I've seen with implementing JWT it's closely tied
> to your container.  So I don't believe its a good fit.
>
> Why is your preference to bring this into geronimo?
>

As mentionned there is no link to TomEE in the jwt-auth codebase so no
reason to hold that code in something not reusable at tomee.


>
>
>>
>>
>>
>> -David
>>
>>
>>

Re: [VOTE] Merge Pull Request 123 - MicroProfile JWT support

[Romain Manni-Bucau]

-1 - even against this vote to be honest, you started 2 votes to decide
what we do about that code, we discussed it and stated it was an awesome
start but needing cleanup to be integrable and releasable,  so why another
3rd vote to urge things and get code preventing a release merged?

Le 19 mars 2018 01:02, "David Blevins"  a écrit :

Jean-Louis has put a PR up for discussion for JWT Support in TomEE.

 - https://github.com/apache/tomee/pull/123

There are 35 commits spanning 27 days of work.  It's been reviewed by Andy
and Rudy.  One a committer and one a contributor, which is great for us.

There's an open question as to where the code should live in its final
state: TomEE or Geronimo.  This conversation doesn't seem conclusive after
12 days.  It's ok for us not to agree, but we should have more votes so
there is a clear outcome and we are acting as a community to our best
ability.

Vote: Merge Pull Request 123?

 +1  Yes, let's do it
 +-0 Abstain
 -1  No, don't put this code in TomEE


Out of respect for the conversation, this is not a vote of where the code
will live in its final state.  This is just a decision to merge or not.  It
would give the users something they can try, which can be updated by a
future PR if the code does eventually move.


-David

Re: [VOTE] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

Hey David,

How does this vote relates to the geronimo one you launched?

Are they purely concurrent or can they be conditional one for the other?


Le 19 mars 2018 01:03, "David Blevins"  a écrit :

> The vote for merging PR 123 does not address community will on what to do
> with the code beyond merging it.  One can realistically vote +1 to merge
> the code, but then desire to see the code cleaned up and moved elsewhere.
> One can realistically desire seeing an attempt to clean up the code to find
> what is reusable and may wish to withhold a final decision until we see how
> fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE or
> Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is
> reusable and how successful such a jar would be?
>
>  +1 Let's give it a shot here
>  +-0
>  -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final
> conclusion of if that extraction is worth it or where it should live is not
> being voted on.  People are welcome to decide differently based on the
> results of the exercise.
>
>
> -David
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-18 20:38 GMT+01:00 David Blevins <david.blev...@gmail.com>:

> In case that wasn't clear, gentle objection to moving this now.
>
> If we can get this merged and at least a snapshot out, that'd be preferred.
>

I'm not following the rational here. Let me try to summarize another time
for you to ensure we speak of the same thing:

1. code will be at geronimo - whatever happens at tomee
2. code we worked on with JL has no tomee dependency (see 4 to be complete
here)
3. as the MP-Config work Roberto did, we'll need a TCK module (next to the
Roberto's one) for jwt-auth spec + a modification of the MP distro
4. TomEE had some propagation bug we need to fix - MP or not since it
happens with a plain servlet

So the JWT-Auth PR for TomEE can be:

A. this one which means TomEE will have an implementation of JWT-Auth and
Geronimo another one
B. the JWT-Auth code moves to Geronimo and TomEE merges from this PR 3 and 4

Just to restate it since it seems we restart from a blank page ;): I'm -1
on A to avoid to split our effort and noise as ASF and +1 for B.


>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> On Mar 18, 2018, at 12:26 PM, David Blevins <david.blev...@gmail.com>
> wrote:
>
> I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge
> this at least?
>
>
> -David
>
> On Mar 9, 2018, at 3:20 AM, John D. Ament <johndam...@apache.org> wrote:
>
> I don't think its a good idea to move TomEE code into Geronimo.
>
> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> If there is no other comment, any objection to move it to
> geronimo-jwt-auth? (let say if not we do it on monday european time)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
>
> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>
> :
>
> Hi community,
>
>
> So we now have something close in terms of MP-JWT implementation.
>
> With the playground branch I've been working on (Thanks Romain for the
> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> TCK
> I have eagerly added - see ticket on MP-JWT).
>
> Now the question is how do we proceed?
> Knowing that most of the code is not TomEE specific.
>
>
> I'd move it to G to a new git repo keeping only the tck exec - a bit like
> Roberto started with config. I'll be happy to help fixing the small
> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
>
>
>
> Only few things are in the TomcatSecurityService but that can remain in
> TomEE because it's not really MP-JWT specific either.
>
>
> +1, was overdue anyway for our servlet-ejb integration
>
>
>
> Here is the PR for discussion
> https://github.com/apache/tomee/pull/123
>
> Cheers
> Jean-Louis
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
>
>
>
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

@JL: ok I let you do

@David: hmm, not sure which part I missed but there is nothing to merge
except the TCK part which requires to extract it from the PR. This is what
JL will do tmr so we can merge it after.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-18 20:26 GMT+01:00 David Blevins <david.blev...@gmail.com>:

> I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge
> this at least?
>
>
> -David
>
> > On Mar 9, 2018, at 3:20 AM, John D. Ament <johndam...@apache.org> wrote:
> >
> > I don't think its a good idea to move TomEE code into Geronimo.
> >
> > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> >
> >> If there is no other comment, any objection to move it to
> >> geronimo-jwt-auth? (let say if not we do it on monday european time)
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau> | Book
> >> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
> >>
> >> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >>
> >>>
> >>> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> >>> :
> >>>
> >>>> Hi community,
> >>>>
> >>>>
> >>>> So we now have something close in terms of MP-JWT implementation.
> >>>>
> >>>> With the playground branch I've been working on (Thanks Romain for the
> >>>> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> >>>> TCK
> >>>> I have eagerly added - see ticket on MP-JWT).
> >>>>
> >>>> Now the question is how do we proceed?
> >>>> Knowing that most of the code is not TomEE specific.
> >>>>
> >>>
> >>> I'd move it to G to a new git repo keeping only the tck exec - a bit
> like
> >>> Roberto started with config. I'll be happy to help fixing the small
> >>> remaining enhancements to do (jwt parsing based on jsonb/p, config
> etc).
> >>>
> >>>
> >>>>
> >>>> Only few things are in the TomcatSecurityService but that can remain
> in
> >>>> TomEE because it's not really MP-JWT specific either.
> >>>>
> >>>
> >>> +1, was overdue anyway for our servlet-ejb integration
> >>>
> >>>
> >>>>
> >>>> Here is the PR for discussion
> >>>> https://github.com/apache/tomee/pull/123
> >>>>
> >>>> Cheers
> >>>> Jean-Louis
> >>>>
> >>>>
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>
> >>>
> >>
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

quick heads up: if no objection in between I plan to start creating the
project tomorrow to let JL importing the code he did.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-12 16:33 GMT+01:00 Rudy De Busscher <rdebussc...@gmail.com>:

> OK (non-binding of course :) for generic classes at Geronimo.
>
> On 12 March 2018 at 16:01, Jean-Louis Monteiro <jlmonte...@tomitribe.com>
> wrote:
>
> > So what's the conclusion here?
> >
> > Should I request a git repo on geronimo and extract all generic classes
> > there along side with other implementations?
> > Or do you guys prefer another tomee repo with the MP-JWT impl?
> >
> > I don't mind if they go here and there, just need to know so I can move
> on
> > with the contribution.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Fri, Mar 9, 2018 at 2:15 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > 2018-03-09 12:37 GMT+01:00 Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com>
> > > :
> > >
> > > > Currently this in a PR, so it hasn't actually been merged anywhere.
> > > There's
> > > > some at least some TomEE specific code, so some modules need defining
> > > > before it can be "moved" in my view.
> > > >
> > > > Rudy's point is good one - no doubt a generic, reusable module may
> well
> > > be
> > > > what we end up with. Wherever that lives when it has clearly been
> > > defined,
> > > > it needs documenting and showing how to use it.
> > > >
> > > > We talked previously about being able to have modules in separate
> repos
> > > > under TomEE. Is there some issue with doing that? What's the rush to
> > > shift
> > > > this off to Geronimo?
> > > >
> > >
> > > No rush, geronimo will have a jwt-auth impl and I was waiting JL push
> > what
> > > he did before speaking of creating a project @G. I would like to share
> > the
> > > same impl with tomee to avoid to x2 the effort. however if not desired
> it
> > > is fine as well.
> > >
> > > It is also important to keep in mind that on tomee side there is *no*
> > > specific code, only fixes in the propagation which also impact
> > webprofile,
> > > nothing linked to MP or this particular spec.
> > >
> > >
> > >
> > > >
> > > > Jon
> > > >
> > > > On Fri, Mar 9, 2018 at 11:27 AM, Rudy De Busscher <
> > rdebussc...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I'm not saying we should move TomEE code into Geronimo.
> > > > >
> > > > > If we move the generic stuff for JWT Auth to Geronimo, it will not
> be
> > > > > enough to have it completely functional. And that should be made
> > clear
> > > > from
> > > > > the beginning for all potential usages.
> > > > >
> > > > > On 9 March 2018 at 12:20, John D. Ament <johndam...@apache.org>
> > wrote:
> > > > >
> > > > > > I don't think its a good idea to move TomEE code into Geronimo.
> > > > > >
> > > > > > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If there is no other comment, any objection to move it to
> > > > > > > geronimo-jwt-auth? (let say if not we do it on monday european
> > > time)
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github
> > > > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > > > > <https://www.linkedin.com/in/rmannibucau> 

Re: Tomee and java 10

[Romain Manni-Bucau]

with updates each 6 months it must be ;)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-14 17:59 GMT+01:00 cocorossello <cocorosse...@gmail.com>:

> That was so fast!
>
> Thanks,
> Vicente.
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> f982480.html
>

Re: Tomee and java 10

[Romain Manni-Bucau]

Note that Type.getType(String) has been broken in asm 6.1 vs 6.0, you have
to pass the descriptor or the type but getType(type.getName()) doesn't work
anymore


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-14 17:47 GMT+01:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Cool. I'll update OWB and OpenJPA and send some more PRs, and will test
> them in TomEE with master :)
>
> On Wed, Mar 14, 2018 at 4:45 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > it is uploading (if my signing doesnt fail on that computer)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
> > 2018-03-14 17:44 GMT+01:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Oh wow, you released it too?
> > >
> > > On Wed, Mar 14, 2018 at 4:43 PM, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > You beat me to it.. :)
> > > >
> > > > On Wed, Mar 14, 2018 at 4:40 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > > wrote:
> > > >
> > > >> FYI https://issues.apache.org/jira/browse/XBEAN-302
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> <https://rmannibucau.metawerx.net/> | Old Blog
> > > >> <http://rmannibucau.wordpress.com> | Github <
> > > >> https://github.com/rmannibucau> |
> > > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > >> <https://www.packtpub.com/application-development/java-ee-8-
> > > >> high-performance>
> > > >>
> > > >> 2018-03-14 17:17 GMT+01:00 Jonathan Gallimore <
> > > >> jonathan.gallim...@gmail.com>
> > > >> :
> > > >>
> > > >> > Hehe... I had just updated OWB and OpenJPA. Yes, we can update to
> > 6.1
> > > >> > although that needs an xbean-asm-shaded update first (which I'm
> > happy
> > > to
> > > >> > do) - so it'll take a little time to turnaround (although should
> be
> > > much
> > > >> > quicker than the ASM 6 update).
> > > >> >
> > > >> > On Wed, Mar 14, 2018 at 4:05 PM, cocorossello <
> > cocorosse...@gmail.com
> > > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hi,
> > > >> > >
> > > >> > > I know you just moved to ASM 6 in both tomee 8 and 1.7.x
> branches,
> > > but
> > > >> > > would
> > > >> > > you consider upgrading both ASM to 6.1 so upcoming java 10 will
> be
> > > >> > > supported
> > > >> > > as well? (I guess, I don't know if there is something else that
> > > could
> > > >> > > break).
> > > >> > >
> > > >> > > Best regards,
> > > >> > > Vicente.
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> > > >> > > f982480.html
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Tomee and java 10

[Romain Manni-Bucau]

it is uploading (if my signing doesnt fail on that computer)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-14 17:44 GMT+01:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Oh wow, you released it too?
>
> On Wed, Mar 14, 2018 at 4:43 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > You beat me to it.. :)
> >
> > On Wed, Mar 14, 2018 at 4:40 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >> FYI https://issues.apache.org/jira/browse/XBEAN-302
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <https://www.packtpub.com/application-development/java-ee-8-
> >> high-performance>
> >>
> >> 2018-03-14 17:17 GMT+01:00 Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com>
> >> :
> >>
> >> > Hehe... I had just updated OWB and OpenJPA. Yes, we can update to 6.1
> >> > although that needs an xbean-asm-shaded update first (which I'm happy
> to
> >> > do) - so it'll take a little time to turnaround (although should be
> much
> >> > quicker than the ASM 6 update).
> >> >
> >> > On Wed, Mar 14, 2018 at 4:05 PM, cocorossello <cocorosse...@gmail.com
> >
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I know you just moved to ASM 6 in both tomee 8 and 1.7.x branches,
> but
> >> > > would
> >> > > you consider upgrading both ASM to 6.1 so upcoming java 10 will be
> >> > > supported
> >> > > as well? (I guess, I don't know if there is something else that
> could
> >> > > break).
> >> > >
> >> > > Best regards,
> >> > > Vicente.
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> >> > > f982480.html
> >> > >
> >> >
> >>
> >
> >
>

Re: Tomee and java 10

[Romain Manni-Bucau]

FYI https://issues.apache.org/jira/browse/XBEAN-302


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-14 17:17 GMT+01:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Hehe... I had just updated OWB and OpenJPA. Yes, we can update to 6.1
> although that needs an xbean-asm-shaded update first (which I'm happy to
> do) - so it'll take a little time to turnaround (although should be much
> quicker than the ASM 6 update).
>
> On Wed, Mar 14, 2018 at 4:05 PM, cocorossello <cocorosse...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I know you just moved to ASM 6 in both tomee 8 and 1.7.x branches, but
> > would
> > you consider upgrading both ASM to 6.1 so upcoming java 10 will be
> > supported
> > as well? (I guess, I don't know if there is something else that could
> > break).
> >
> > Best regards,
> > Vicente.
> >
> >
> >
> > --
> > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> > f982480.html
> >
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-12 16:01 GMT+01:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:

> So what's the conclusion here?
>
> Should I request a git repo on geronimo and extract all generic classes
> there along side with other implementations?
>

+1 from me


> Or do you guys prefer another tomee repo with the MP-JWT impl?
>
> I don't mind if they go here and there, just need to know so I can move on
> with the contribution.
>

we already have 3 days passed so tempted to say maybe wait tonight and just
move forward if you don't have more feedback
in any case it wouldn't be too late to fork back at tomee later if desired
(but hopefully we'll not self-fork ;))


>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Mar 9, 2018 at 2:15 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > 2018-03-09 12:37 GMT+01:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Currently this in a PR, so it hasn't actually been merged anywhere.
> > There's
> > > some at least some TomEE specific code, so some modules need defining
> > > before it can be "moved" in my view.
> > >
> > > Rudy's point is good one - no doubt a generic, reusable module may well
> > be
> > > what we end up with. Wherever that lives when it has clearly been
> > defined,
> > > it needs documenting and showing how to use it.
> > >
> > > We talked previously about being able to have modules in separate repos
> > > under TomEE. Is there some issue with doing that? What's the rush to
> > shift
> > > this off to Geronimo?
> > >
> >
> > No rush, geronimo will have a jwt-auth impl and I was waiting JL push
> what
> > he did before speaking of creating a project @G. I would like to share
> the
> > same impl with tomee to avoid to x2 the effort. however if not desired it
> > is fine as well.
> >
> > It is also important to keep in mind that on tomee side there is *no*
> > specific code, only fixes in the propagation which also impact
> webprofile,
> > nothing linked to MP or this particular spec.
> >
> >
> >
> > >
> > > Jon
> > >
> > > On Fri, Mar 9, 2018 at 11:27 AM, Rudy De Busscher <
> rdebussc...@gmail.com
> > >
> > > wrote:
> > >
> > > > I'm not saying we should move TomEE code into Geronimo.
> > > >
> > > > If we move the generic stuff for JWT Auth to Geronimo, it will not be
> > > > enough to have it completely functional. And that should be made
> clear
> > > from
> > > > the beginning for all potential usages.
> > > >
> > > > On 9 March 2018 at 12:20, John D. Ament <johndam...@apache.org>
> wrote:
> > > >
> > > > > I don't think its a good idea to move TomEE code into Geronimo.
> > > > >
> > > > > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > If there is no other comment, any objection to move it to
> > > > > > geronimo-jwt-auth? (let say if not we do it on monday european
> > time)
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github
> > > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <https://www.packtpub.com/application-development/java-
> > > > > ee-8-high-performance>
> > > > > >
> > > > > > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > > > >
> > > > > >>
> > > > > >> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com>
> > > > > >> :
> > > > > >>
> > > > > >>> Hi community,
> > > > > >>>
> > > > > >>>
> > > > > >>> So we now have something close in terms of MP-JWT
> implementation.
> > > > > >>>
> > > >

Re: TomEE MicroProfile Dist with Config

[Romain Manni-Bucau]

it hits the fb_tomee8 branch
note that you need mp-config-api built locally - if anyone has perms to
deploy a snapshot it would be welcomed and we can add the eclipse snapshot
repo if not already here

don't hesitate to have look even now it is merged, we can still change
everything

open point: we reuse eclipse api, it is asf v2 so should be ok just with a
notice ref but just asking in case we want to own the api with some
hardcoded provider


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-12 14:28 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> starting to apply it on tomee8 branch (merge + basic verifications on
> fb_tomee8)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> 2018-03-11 0:28 GMT+01:00 Roberto Cortez <radcor...@yahoo.com.invalid>:
>
>>
>> Cool! Thanks!On Saturday, March 10, 2018, 3:22:38 PM GMT, Romain
>> Manni-Bucau <rmannibu...@gmail.com> wrote:
>>
>>  PR looks good now to me - we need to have the war vs tomee-maven-plugin
>> assembly discussion in another thread so it doesn't block this particula
>> topic.
>>
>> Happy to merge it next week or if anyone else wants to have a look and do
>> it just go :).
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-
>> high-performance>
>>
>> 2018-03-10 8:03 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>>
>> >
>> >
>> > Le 9 mars 2018 23:21, "Roberto Cortez" <radcor...@yahoo.com.invalid> a
>> > écrit :
>> >
>> >
>> > Hi,
>> > New update to the PR. Let me know if that is better.
>> > I still believe we should have org.apache.geronimo.confi
>> > g.configsource.SystemPropertyConfigSource.copy = false as default,
>> since
>> > that is the behaviour the TCK expects.
>> >
>> >
>> > Point is that it should be consistent with the real impl default. That
>> > said it is not the default cause of TCK I think since it is more costly
>> to
>> > check it each time so can need a refinement here but independent from
>> tomee
>> > integration which is the whole point.
>> >
>> > Will check the pr update tmr, thanks for the hard work.
>> >
>> >
>> > Cheers,RobertoOn Wednesday, March 7, 2018, 8:07:04 AM GMT, Romain
>> > Manni-Bucau <rmannibu...@gmail.com> wrote:
>> >
>> >  2018-03-07 6:00 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.inval
>> > id>:
>> >
>> > > Hi all>>>>Yep, as mentionned no issue to have a new distro ;).Right
>> > > decision, TomEE is the best reasonable place to have MP profile. We
>> also
>> > > need to have only MP profile of TomEE (TomEE Micro with only have MP
>> > > nothing else).
>> > >
>> >
>> > Depends, we already have hammock which is a great MP "only" server so
>> tomee
>> > WP+MP can be beneficial for end users and avoid duplication @asf. Was
>> just
>> > my raw thought on that.
>> >
>> >
>> > >
>> > > CheersGurkan
>> > >
>> > >On Tuesday, March 6, 2018, 12:32:03 AM GMT+3, Romain Manni-Bucau <
>> > > rmannibu...@gmail.com> wrote:
>> > >
>> > >  Le 5 mars 2018 22:07, "Jonathan Gallimore" <
>> > jonathan.gallim...@gmail.com>
>> > > a
>> > > écrit :
>> > >
>> > > On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau <
>> > rmannibu...@gmail.com>
>> > > wrote:
>

Re: TomEE MicroProfile Dist with Config

[Romain Manni-Bucau]

starting to apply it on tomee8 branch (merge + basic verifications on
fb_tomee8)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-11 0:28 GMT+01:00 Roberto Cortez <radcor...@yahoo.com.invalid>:

>
> Cool! Thanks!    On Saturday, March 10, 2018, 3:22:38 PM GMT, Romain
> Manni-Bucau <rmannibu...@gmail.com> wrote:
>
>  PR looks good now to me - we need to have the war vs tomee-maven-plugin
> assembly discussion in another thread so it doesn't block this particula
> topic.
>
> Happy to merge it next week or if anyone else wants to have a look and do
> it just go :).
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-03-10 8:03 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> >
> >
> > Le 9 mars 2018 23:21, "Roberto Cortez" <radcor...@yahoo.com.invalid> a
> > écrit :
> >
> >
> > Hi,
> > New update to the PR. Let me know if that is better.
> > I still believe we should have org.apache.geronimo.confi
> > g.configsource.SystemPropertyConfigSource.copy = false as default, since
> > that is the behaviour the TCK expects.
> >
> >
> > Point is that it should be consistent with the real impl default. That
> > said it is not the default cause of TCK I think since it is more costly
> to
> > check it each time so can need a refinement here but independent from
> tomee
> > integration which is the whole point.
> >
> > Will check the pr update tmr, thanks for the hard work.
> >
> >
> > Cheers,RobertoOn Wednesday, March 7, 2018, 8:07:04 AM GMT, Romain
> > Manni-Bucau <rmannibu...@gmail.com> wrote:
> >
> >  2018-03-07 6:00 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.inval
> > id>:
> >
> > > Hi all>>>>Yep, as mentionned no issue to have a new distro ;).Right
> > > decision, TomEE is the best reasonable place to have MP profile. We
> also
> > > need to have only MP profile of TomEE (TomEE Micro with only have MP
> > > nothing else).
> > >
> >
> > Depends, we already have hammock which is a great MP "only" server so
> tomee
> > WP+MP can be beneficial for end users and avoid duplication @asf. Was
> just
> > my raw thought on that.
> >
> >
> > >
> > > CheersGurkan
> > >
> > >On Tuesday, March 6, 2018, 12:32:03 AM GMT+3, Romain Manni-Bucau <
> > > rmannibu...@gmail.com> wrote:
> > >
> > >  Le 5 mars 2018 22:07, "Jonathan Gallimore" <
> > jonathan.gallim...@gmail.com>
> > > a
> > > écrit :
> > >
> > > On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > Le 5 mars 2018 21:35, "Jonathan Gallimore" <
> > jonathan.gallim...@gmail.com
> > > >
> > > > a écrit :
> > > >
> > > > The name "MicroProfile" suggests an element of being small, so I'm
> not
> > > > sure why we'd only add this to our biggest distribution and no where
> > > else.
> > > > I've built the change (thanks for the help Roberto), and it adds
> <100KB
> > > to
> > > > the binary. I'd definitely add it to Plus and Plume, but I think we
> > > should
> > > > either add it web profile, or if we really don't want it in
> > WebProfile, I
> > > > see no harm in an extra flavour that is webprofile + microprofile.
> > > >
> > > >
> > > > Ok for plume and plus for me, please not to WP.
> > > >
> > >
> > > Would you be ok with the MP profile then? Seems like reasonable middle
> > > ground. Without that, folks who want "Micro"Profile features would be
> > > forced to use the biggest flavours.
> > >
> > >
> > > Yep, as mentionned no issue to have a new distro ;).
> > >
> > >
> > >
> > > >
> > > > Open point: should it be switchable to off even if provided in case
> it
> > > > breaks apps?
> > > >
> > >
> > > I'm ok with that.
> > >
> > > Jon
> > >
> >
> >
> >
>

Re: TomEE MicroProfile Dist with Config

[Romain Manni-Bucau]

PR looks good now to me - we need to have the war vs tomee-maven-plugin
assembly discussion in another thread so it doesn't block this particula
topic.

Happy to merge it next week or if anyone else wants to have a look and do
it just go :).




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-10 8:03 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

>
>
> Le 9 mars 2018 23:21, "Roberto Cortez" <radcor...@yahoo.com.invalid> a
> écrit :
>
>
> Hi,
> New update to the PR. Let me know if that is better.
> I still believe we should have org.apache.geronimo.confi
> g.configsource.SystemPropertyConfigSource.copy = false as default, since
> that is the behaviour the TCK expects.
>
>
> Point is that it should be consistent with the real impl default. That
> said it is not the default cause of TCK I think since it is more costly to
> check it each time so can need a refinement here but independent from tomee
> integration which is the whole point.
>
> Will check the pr update tmr, thanks for the hard work.
>
>
> Cheers,RobertoOn Wednesday, March 7, 2018, 8:07:04 AM GMT, Romain
> Manni-Bucau <rmannibu...@gmail.com> wrote:
>
>  2018-03-07 6:00 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.inval
> id>:
>
> > Hi all>>>>Yep, as mentionned no issue to have a new distro ;).Right
> > decision, TomEE is the best reasonable place to have MP profile. We also
> > need to have only MP profile of TomEE (TomEE Micro with only have MP
> > nothing else).
> >
>
> Depends, we already have hammock which is a great MP "only" server so tomee
> WP+MP can be beneficial for end users and avoid duplication @asf. Was just
> my raw thought on that.
>
>
> >
> > CheersGurkan
> >
> >On Tuesday, March 6, 2018, 12:32:03 AM GMT+3, Romain Manni-Bucau <
> > rmannibu...@gmail.com> wrote:
> >
> >  Le 5 mars 2018 22:07, "Jonathan Gallimore" <
> jonathan.gallim...@gmail.com>
> > a
> > écrit :
> >
> > On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > Le 5 mars 2018 21:35, "Jonathan Gallimore" <
> jonathan.gallim...@gmail.com
> > >
> > > a écrit :
> > >
> > > The name "MicroProfile" suggests an element of being small, so I'm not
> > > sure why we'd only add this to our biggest distribution and no where
> > else.
> > > I've built the change (thanks for the help Roberto), and it adds <100KB
> > to
> > > the binary. I'd definitely add it to Plus and Plume, but I think we
> > should
> > > either add it web profile, or if we really don't want it in
> WebProfile, I
> > > see no harm in an extra flavour that is webprofile + microprofile.
> > >
> > >
> > > Ok for plume and plus for me, please not to WP.
> > >
> >
> > Would you be ok with the MP profile then? Seems like reasonable middle
> > ground. Without that, folks who want "Micro"Profile features would be
> > forced to use the biggest flavours.
> >
> >
> > Yep, as mentionned no issue to have a new distro ;).
> >
> >
> >
> > >
> > > Open point: should it be switchable to off even if provided in case it
> > > breaks apps?
> > >
> >
> > I'm ok with that.
> >
> > Jon
> >
>
>
>

Re: TomEE MicroProfile Dist with Config

[Romain Manni-Bucau]

Le 9 mars 2018 23:21, "Roberto Cortez" <radcor...@yahoo.com.invalid> a
écrit :


Hi,
New update to the PR. Let me know if that is better.
I still believe we should have org.apache.geronimo.config.configsource.
SystemPropertyConfigSource.copy = false as default, since that is the
behaviour the TCK expects.


Point is that it should be consistent with the real impl default. That said
it is not the default cause of TCK I think since it is more costly to check
it each time so can need a refinement here but independent from tomee
integration which is the whole point.

Will check the pr update tmr, thanks for the hard work.


Cheers,RobertoOn Wednesday, March 7, 2018, 8:07:04 AM GMT, Romain
Manni-Bucau <rmannibu...@gmail.com> wrote:

 2018-03-07 6:00 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.invalid>:

> Hi all>>>>Yep, as mentionned no issue to have a new distro ;).Right
> decision, TomEE is the best reasonable place to have MP profile. We also
> need to have only MP profile of TomEE (TomEE Micro with only have MP
> nothing else).
>

Depends, we already have hammock which is a great MP "only" server so tomee
WP+MP can be beneficial for end users and avoid duplication @asf. Was just
my raw thought on that.


>
> CheersGurkan
>
>On Tuesday, March 6, 2018, 12:32:03 AM GMT+3, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Le 5 mars 2018 22:07, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
> a
> écrit :
>
> On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> >
> >
> > Le 5 mars 2018 21:35, "Jonathan Gallimore" <jonathan.gallim...@gmail.com
> >
> > a écrit :
> >
> > The name "MicroProfile" suggests an element of being small, so I'm not
> > sure why we'd only add this to our biggest distribution and no where
> else.
> > I've built the change (thanks for the help Roberto), and it adds <100KB
> to
> > the binary. I'd definitely add it to Plus and Plume, but I think we
> should
> > either add it web profile, or if we really don't want it in WebProfile,
I
> > see no harm in an extra flavour that is webprofile + microprofile.
> >
> >
> > Ok for plume and plus for me, please not to WP.
> >
>
> Would you be ok with the MP profile then? Seems like reasonable middle
> ground. Without that, folks who want "Micro"Profile features would be
> forced to use the biggest flavours.
>
>
> Yep, as mentionned no issue to have a new distro ;).
>
>
>
> >
> > Open point: should it be switchable to off even if provided in case it
> > breaks apps?
> >
>
> I'm ok with that.
>
> Jon
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-09 12:37 GMT+01:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Currently this in a PR, so it hasn't actually been merged anywhere. There's
> some at least some TomEE specific code, so some modules need defining
> before it can be "moved" in my view.
>
> Rudy's point is good one - no doubt a generic, reusable module may well be
> what we end up with. Wherever that lives when it has clearly been defined,
> it needs documenting and showing how to use it.
>
> We talked previously about being able to have modules in separate repos
> under TomEE. Is there some issue with doing that? What's the rush to shift
> this off to Geronimo?
>

No rush, geronimo will have a jwt-auth impl and I was waiting JL push what
he did before speaking of creating a project @G. I would like to share the
same impl with tomee to avoid to x2 the effort. however if not desired it
is fine as well.

It is also important to keep in mind that on tomee side there is *no*
specific code, only fixes in the propagation which also impact webprofile,
nothing linked to MP or this particular spec.



>
> Jon
>
> On Fri, Mar 9, 2018 at 11:27 AM, Rudy De Busscher <rdebussc...@gmail.com>
> wrote:
>
> > I'm not saying we should move TomEE code into Geronimo.
> >
> > If we move the generic stuff for JWT Auth to Geronimo, it will not be
> > enough to have it completely functional. And that should be made clear
> from
> > the beginning for all potential usages.
> >
> > On 9 March 2018 at 12:20, John D. Ament <johndam...@apache.org> wrote:
> >
> > > I don't think its a good idea to move TomEE code into Geronimo.
> > >
> > > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > If there is no other comment, any objection to move it to
> > > > geronimo-jwt-auth? (let say if not we do it on monday european time)
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github
> > > > <https://github.com/rmannibucau> | LinkedIn
> > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <https://www.packtpub.com/application-development/java-
> > > ee-8-high-performance>
> > > >
> > > > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > >>
> > > >> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com>
> > > >> :
> > > >>
> > > >>> Hi community,
> > > >>>
> > > >>>
> > > >>> So we now have something close in terms of MP-JWT implementation.
> > > >>>
> > > >>> With the playground branch I've been working on (Thanks Romain for
> > the
> > > >>> help), we now pass 100% of the TCK (including a missing part in
> > MP-JWT
> > > >>> TCK
> > > >>> I have eagerly added - see ticket on MP-JWT).
> > > >>>
> > > >>> Now the question is how do we proceed?
> > > >>> Knowing that most of the code is not TomEE specific.
> > > >>>
> > > >>
> > > >> I'd move it to G to a new git repo keeping only the tck exec - a bit
> > > like
> > > >> Roberto started with config. I'll be happy to help fixing the small
> > > >> remaining enhancements to do (jwt parsing based on jsonb/p, config
> > etc).
> > > >>
> > > >>
> > > >>>
> > > >>> Only few things are in the TomcatSecurityService but that can
> remain
> > in
> > > >>> TomEE because it's not really MP-JWT specific either.
> > > >>>
> > > >>
> > > >> +1, was overdue anyway for our servlet-ejb integration
> > > >>
> > > >>
> > > >>>
> > > >>> Here is the PR for discussion
> > > >>> https://github.com/apache/tomee/pull/123
> > > >>>
> > > >>> Cheers
> > > >>> Jean-Louis
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Jean-Louis Monteiro
> > > >>> http://twitter.com/jlouismonteiro
> > > >>> http://www.tomitribe.com
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-09 12:02 GMT+01:00 Rudy De Busscher <rdebussc...@gmail.com>:

> No objection but an important remark to make.
>
> it will not be enough to just add this  geronimo-jwt-auth artifact to a
> server to have it functional. There will be some server-side integration
> code required (just as we will need for TomEE)
>

it is not the case for tomee and shouldn't normally if the server
propagates properly its security context. It is not always the case, you
are right,
but for asf servers it should AFAIK, no?


>
> This is thus clearly different from other microprofile implementations like
> geronimo-config.
>
> Just want to mention this as there are already people (outside of this
> community) thinking that such a thing is possible (or should be possible)
>
> Rudy
>
> On 9 March 2018 at 11:49, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > If there is no other comment, any objection to move it to
> > geronimo-jwt-auth? (let say if not we do it on monday european time)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
> > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > >
> > > 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> jlmonte...@tomitribe.com
> > >:
> > >
> > >> Hi community,
> > >>
> > >>
> > >> So we now have something close in terms of MP-JWT implementation.
> > >>
> > >> With the playground branch I've been working on (Thanks Romain for the
> > >> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> > TCK
> > >> I have eagerly added - see ticket on MP-JWT).
> > >>
> > >> Now the question is how do we proceed?
> > >> Knowing that most of the code is not TomEE specific.
> > >>
> > >
> > > I'd move it to G to a new git repo keeping only the tck exec - a bit
> like
> > > Roberto started with config. I'll be happy to help fixing the small
> > > remaining enhancements to do (jwt parsing based on jsonb/p, config
> etc).
> > >
> > >
> > >>
> > >> Only few things are in the TomcatSecurityService but that can remain
> in
> > >> TomEE because it's not really MP-JWT specific either.
> > >>
> > >
> > > +1, was overdue anyway for our servlet-ejb integration
> > >
> > >
> > >>
> > >> Here is the PR for discussion
> > >> https://github.com/apache/tomee/pull/123
> > >>
> > >> Cheers
> > >> Jean-Louis
> > >>
> > >>
> > >> --
> > >> Jean-Louis Monteiro
> > >> http://twitter.com/jlouismonteiro
> > >> http://www.tomitribe.com
> > >>
> > >
> > >
> >
>

Re: MP-JWT progress

[Romain Manni-Bucau]

If there is no other comment, any objection to move it to
geronimo-jwt-auth? (let say if not we do it on monday european time)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

>
> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:
>
>> Hi community,
>>
>>
>> So we now have something close in terms of MP-JWT implementation.
>>
>> With the playground branch I've been working on (Thanks Romain for the
>> help), we now pass 100% of the TCK (including a missing part in MP-JWT TCK
>> I have eagerly added - see ticket on MP-JWT).
>>
>> Now the question is how do we proceed?
>> Knowing that most of the code is not TomEE specific.
>>
>
> I'd move it to G to a new git repo keeping only the tck exec - a bit like
> Roberto started with config. I'll be happy to help fixing the small
> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
>
>
>>
>> Only few things are in the TomcatSecurityService but that can remain in
>> TomEE because it's not really MP-JWT specific either.
>>
>
> +1, was overdue anyway for our servlet-ejb integration
>
>
>>
>> Here is the PR for discussion
>> https://github.com/apache/tomee/pull/123
>>
>> Cheers
>> Jean-Louis
>>
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>
>

Re: TomEE MicroProfile Dist with Config

[Romain Manni-Bucau]

2018-03-07 6:00 GMT+01:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.invalid>:

> Hi all>>>>Yep, as mentionned no issue to have a new distro ;).Right
> decision, TomEE is the best reasonable place to have MP profile. We also
> need to have only MP profile of TomEE (TomEE Micro with only have MP
> nothing else).
>

Depends, we already have hammock which is a great MP "only" server so tomee
WP+MP can be beneficial for end users and avoid duplication @asf. Was just
my raw thought on that.


>
> CheersGurkan
>
>     On Tuesday, March 6, 2018, 12:32:03 AM GMT+3, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Le 5 mars 2018 22:07, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
> a
> écrit :
>
> On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> >
> >
> > Le 5 mars 2018 21:35, "Jonathan Gallimore" <jonathan.gallim...@gmail.com
> >
> > a écrit :
> >
> > The name "MicroProfile" suggests an element of being small, so I'm not
> > sure why we'd only add this to our biggest distribution and no where
> else.
> > I've built the change (thanks for the help Roberto), and it adds <100KB
> to
> > the binary. I'd definitely add it to Plus and Plume, but I think we
> should
> > either add it web profile, or if we really don't want it in WebProfile, I
> > see no harm in an extra flavour that is webprofile + microprofile.
> >
> >
> > Ok for plume and plus for me, please not to WP.
> >
>
> Would you be ok with the MP profile then? Seems like reasonable middle
> ground. Without that, folks who want "Micro"Profile features would be
> forced to use the biggest flavours.
>
>
> Yep, as mentionned no issue to have a new distro ;).
>
>
>
> >
> > Open point: should it be switchable to off even if provided in case it
> > breaks apps?
> >
>
> I'm ok with that.
>
> Jon
>