Re: Potential release vote for 8.0.7 and 9.0.0-M7

[Gurkan Erdogdu]

Skip my previous question.
Regards.
Gurkan

On Sat, May 1, 2021 at 8:57 AM Gurkan Erdogdu  wrote:

> AFAIK, (please correct me if I am wrong), ASF is not a member of the
> Jakarta EE working group and is not able to get certified. How will TomEE
> get certified?
> Because of this, Tomcat is not able to be listed in certification pages of
> Servlet specification.
>
> Regards.
> Gurkan
>
> On Sat, May 1, 2021 at 4:32 AM David Blevins 
> wrote:
>
>> Heads up that we are narrowing in in the last few TCK issues and there is
>> still some chance we can be Jakarta EE 9.1 Web Profile certified in time
>> for the Jakarta EE 9.1 release vote Monday.
>>
>> It would be super super and I mean *super* tight
>>
>> However, if we can get it done we'll need to do a release vote by no
>> later than Sunday afternoon and file our certification request.  We don't
>> need to have concluded our vote to make the Jakarta EE 9.1 release ballot,
>> we just need final binaries of our own to be at least in staging and in the
>> process of our own vote.
>>
>> We do need that vote pass, however, so that would require some pragmatism
>> on all our parts.
>>
>> For that reason I recommend we do not try to push out a 9.0.0 final, but
>> go ahead with 9.0.0-M7. If there are some issues with the binaries we put
>> up for vote, unless they are legal issues, we can still release them and
>> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.
>> There's no reason to "wait", we can simply release twice.  Version numbers
>> are free.
>>
>> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement
>> would happen some days after that.  Ff we did want to push out a 9.0.0 for
>> the announcement, we'd have at least till May 17th to do that, perhaps even
>> the 20th.
>>
>> The reason we want to get certified in time for the ballot is recently
>> there was a change that implementations listed on the ballot get a special
>> place at the top of the specification page.  Any implementations that come
>> even one day later cannot be included and will not be accepted or given
>> special designation.  This lasts forever and is a permanent advantage to
>> those in the list.  It's also a permanent *disadvantage* to those not on
>> the list.  It's eat or be eaten.
>>
>> So that's what we're going for:  A staged binary up for a vote here,
>> passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot
>> Monday.
>>
>>
>> -David
>>
>>

Re: Potential release vote for 8.0.7 and 9.0.0-M7

[Gurkan Erdogdu]

AFAIK, (please correct me if I am wrong), ASF is not a member of the
Jakarta EE working group and is not able to get certified. How will TomEE
get certified?
Because of this, Tomcat is not able to be listed in certification pages of
Servlet specification.

Regards.
Gurkan

On Sat, May 1, 2021 at 4:32 AM David Blevins 
wrote:

> Heads up that we are narrowing in in the last few TCK issues and there is
> still some chance we can be Jakarta EE 9.1 Web Profile certified in time
> for the Jakarta EE 9.1 release vote Monday.
>
> It would be super super and I mean *super* tight
>
> However, if we can get it done we'll need to do a release vote by no later
> than Sunday afternoon and file our certification request.  We don't need to
> have concluded our vote to make the Jakarta EE 9.1 release ballot, we just
> need final binaries of our own to be at least in staging and in the process
> of our own vote.
>
> We do need that vote pass, however, so that would require some pragmatism
> on all our parts.
>
> For that reason I recommend we do not try to push out a 9.0.0 final, but
> go ahead with 9.0.0-M7. If there are some issues with the binaries we put
> up for vote, unless they are legal issues, we can still release them and
> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8.
> There's no reason to "wait", we can simply release twice.  Version numbers
> are free.
>
> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement
> would happen some days after that.  Ff we did want to push out a 9.0.0 for
> the announcement, we'd have at least till May 17th to do that, perhaps even
> the 20th.
>
> The reason we want to get certified in time for the ballot is recently
> there was a change that implementations listed on the ballot get a special
> place at the top of the specification page.  Any implementations that come
> even one day later cannot be included and will not be accepted or given
> special designation.  This lasts forever and is a permanent advantage to
> those in the list.  It's also a permanent *disadvantage* to those not on
> the list.  It's eat or be eaten.
>
> So that's what we're going for:  A staged binary up for a vote here,
> passing the TCK, in time to be listed on the Jakarta EE 9.1 release ballot
> Monday.
>
>
> -David
>
>

Re: Fixing TomEE 7.1.x Build

[Gurkan Erdogdu]

Cool, thank you!

On Fri, Mar 22, 2019 at 6:56 PM Daniel Cunha  wrote:

> Hi Gurkan,
>
> You right! My fault from my last two Pull Request.
> I'll work to it not happenings again.
>
> Em sex, 22 de mar de 2019 às 12:52, Gurkan Erdogdu 
> escreveu:
>
> > Hi
> > As a general idea:
> > I advise to attach a JIRA issue for each commit. Otherwise, the community
> > are not able to follow the commits and their exact reasons.
> > Regards.
> > Gurkan
> >
> > On Fri, Mar 22, 2019 at 5:41 PM Daniel Cunha 
> > wrote:
> >
> > > Thanks for review it and merge Jon.
> > >
> > > Em sex, 22 de mar de 2019 às 11:41, Daniel Cunha <
> daniels...@apache.org>
> > > escreveu:
> > >
> > > > I'll keep my eyes on the buildbot. :)
> > > >
> > > > Em sex, 22 de mar de 2019 às 11:34, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> escreveu:
> > > >
> > > >> Merged - thanks for sending that over!
> > > >>
> > > >> Jon
> > > >>
> > > >> On Fri, Mar 22, 2019 at 12:20 PM Daniel Cunha <
> daniels...@apache.org>
> > > >> wrote:
> > > >>
> > > >> > Hi folks,
> > > >> >
> > > >> > I opened a PR to fix the build for tomee-7.1.x branch:
> > > >> > https://github.com/apache/tomee/pull/450
> > > >> > Please review it.
> > > >> >
> > > >> > That is the current status for that branch:
> > > >> >
> > > >> > [image: Screenshot from 2019-03-22 09-18-24.png]
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Daniel "soro" Cunha
> > > >> > https://twitter.com/dvlc_
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Daniel "soro" Cunha
> > > > https://twitter.com/dvlc_
> > > >
> > >
> > >
> > > --
> > > Daniel "soro" Cunha
> > > https://twitter.com/dvlc_
> > >
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: Fixing TomEE 7.1.x Build

[Gurkan Erdogdu]

Hi
As a general idea:
I advise to attach a JIRA issue for each commit. Otherwise, the community
are not able to follow the commits and their exact reasons.
Regards.
Gurkan

On Fri, Mar 22, 2019 at 5:41 PM Daniel Cunha  wrote:

> Thanks for review it and merge Jon.
>
> Em sex, 22 de mar de 2019 às 11:41, Daniel Cunha 
> escreveu:
>
> > I'll keep my eyes on the buildbot. :)
> >
> > Em sex, 22 de mar de 2019 às 11:34, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> escreveu:
> >
> >> Merged - thanks for sending that over!
> >>
> >> Jon
> >>
> >> On Fri, Mar 22, 2019 at 12:20 PM Daniel Cunha 
> >> wrote:
> >>
> >> > Hi folks,
> >> >
> >> > I opened a PR to fix the build for tomee-7.1.x branch:
> >> > https://github.com/apache/tomee/pull/450
> >> > Please review it.
> >> >
> >> > That is the current status for that branch:
> >> >
> >> > [image: Screenshot from 2019-03-22 09-18-24.png]
> >> >
> >> >
> >> > --
> >> > Daniel "soro" Cunha
> >> > https://twitter.com/dvlc_
> >> >
> >> >
> >>
> >
> >
> > --
> > Daniel "soro" Cunha
> > https://twitter.com/dvlc_
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: Remove TomEE Web Access Module from Repository

[Gurkan Erdogdu]

I think it does not have any usable features and source files were last
updated 3 years ago.
Regards.
Gurkan

On Fri, Mar 22, 2019 at 6:34 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> I haven't look for quite a while.
>
> What is the module supposed to do or what does it offer?
> And can you elaborate on why it's not usable? Is it broken?
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, Mar 21, 2019 at 8:09 PM Gurkan Erdogdu 
> wrote:
>
> > Hi folks,
> > Can we remove the TomEE web access project (tomee/tomee-web-access) from
> > the repository? I think this module is not usable. Any Idea?
> > Regards.
> > Gurkan
> >
>

Remove TomEE Web Access Module from Repository

[Gurkan Erdogdu]

Hi folks,
Can we remove the TomEE web access project (tomee/tomee-web-access) from
the repository? I think this module is not usable. Any Idea?
Regards.
Gurkan

Re: [VOTE] Release Apache TomEE 8.0.0 MILESTONE 2

[Gurkan Erdogdu]

+1
Thank you!

On Mon, Jan 28, 2019 at 12:26 PM chongma 
wrote:

> +1  i will grab a copy and test it locally with my projects later and let
> you
> know if there are any difficulties
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Another 8.0.0 milestone release

[Gurkan Erdogdu]

+1
Gurkan

On Wed, Jan 23, 2019 at 10:17 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Sounds good to me.
>
> Le mer. 23 janv. 2019 à 04:23, César Hernández Mendoza <
> cesargu...@gmail.com>
> a écrit :
>
> > I have never done a TomEE release but I'm willing to learn during
> 8.0.0-M2
> > release :)
> >
> > El mar., 22 ene. 2019 a las 19:59, David Blevins (<
> david.blev...@gmail.com
> > >)
> > escribió:
> >
> > > There are plans to launch start.microprofile.io on January 29th.  We
> > have
> > > a lot more MicroProfile support in master than we do in 8.0.0-M1.
> > >
> > > What do we think about shooting out an 8.0.0-M2 asap and ensuring it's
> in
> > > the server list for start.microprofile.io?
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > >
> >
> > --
> > Atentamente:
> > César Hernández Mendoza.
> >
>

Re: JakartaEE TCK

[Gurkan Erdogdu]

I think we need to run tests with javaee_webprofile keyword filter. There
is also a GUI to run/see the tests. You can run it with :

   - Go to bin/ folder of TCK
   - Run ant gui
   - You need to create a custom filter configuration with keyword
   javaee_web_profile

When I filter, there exists 17517 tests for Web Profile.

On Mon, Jan 21, 2019 at 9:50 PM César Hernández Mendoza <
cesargu...@gmail.com> wrote:

> @Gurkan
> Thanks for the update.
>
> @List I appreciate pointers/opinions in these two questions:
> After reading the readme, I wonder if there is a proper way to split the
> entire set of tests in sub sets?
> My questions arise when I try to think how we can spread the work mentioned
> in Stage 2 and Stage 3 from the readme.
> I think having a shared document with status mapped to this sub sets can be
> useful as a reference to people trying to find areas to help. What do you
> think?
>
>
> El vie., 18 ene. 2019 a las 2:41, Gurkan Erdogdu ()
> escribió:
>
> > Hi Cesar
> >
> > My environment is macOS
> >
> > Before updating, I received the following error when I run the following
> > command from tomee-tck and also got some dev/tomee-tck/./target/lib is
> not
> > directory errors etc.
> >
> > ./runtests --web tomee-plume
> > com.sun.ts.tests.ejb30.bb.localaccess.statelessclient
> >
> > [INFO]
> > 
> > [ERROR] Failed to execute goal
> > org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
> > project openejb-tck: java.lang.Exception: Expected one file to be
> included
> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
> > excludes=null -> [Help 1]
> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> > goal org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
> > project openejb-tck: java.lang.Exception: Expected one file to be
> included
> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
> > excludes=null
> > at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> >
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > at
> >
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> >
> > On Fri, Jan 18, 2019 at 5:25 AM César Hernández Mendoza <
> > cesargu...@gmail.com> wrote:
> >
> > > Hi,
> > > I was able to set up my local environment and after executing:
> > > ./runtests --web tomee-plume
> > > com.sun.ts.tests.ejb30.bb.localaccess.statelessclient
> > > It seems I got a successful result [1] :).
> > >
> > > After reading the readme, I wonder if there is a proper 

Re: Jakarta EE TCKs and compatibility logo

[Gurkan Erdogdu]

+1
Gurkan

On Sat, Jan 19, 2019 at 3:47 AM David Blevins 
wrote:

> This would be a +1 from me.
>
> Adding some additional context that this doesn't just affect use of the
> compatible logo, but ability to be listed with all the other certified
> servers on the jakarta.ee website.
>
>
> -David
>
>
> On 2019/01/18 22:53:08, Mark Thomas  wrote:
> > Hi all,>
> >
> > I am writing to your dev@ lists (on BCC) as your project has, in the>
> > past, requested access to the Java EE TCKs while they were controlled
> by>
> > Sun and then Oracle.>
> >
> > As I am sure you are aware, Java EE has moved to Eclipse and is now>
> > Jakarta EE. The good news is that the TCKs have been open sourced.>
> >
> > https://github.com/eclipse-ee4j/jakartaee-tck>
> >
> > (I haven't tried to build the latest TCK from source yet but it is on
> my>
> > TODO list.)>
> >
> > Shipping compatible implementations of the Jakarta EE specs (and being>
> > able to make public statements to that effect) will be subject only to>
> > the spec [1] and TCK [2] licenses. There will no longer be a TCK>
> > agreement or NDA to sign. However...>
> >
> > The question has arisen whether or not any ASF projects will want to
> use>
> > the Jakarta EE compatible logo [3]. If a project wants to be able to do>
> > this, there are some organisational hoops to jump through. Before the>
> > ASF starts down that path the board has asked me to see if there are
> any>
> > projects that want to use the Jakarta EE compatible logo. After all,>
> > there is no point jumping through the hoops if no-one wants to use the
> logo.>
> >
> > With the above in mind can you please discuss this amongst your project>
> > community and reply back to jcp-o...@apache.org whether or not your>
> > project is interested in being able to use the Jakarta EE compatible>
> > logo. I ask that you complete this no later than the next board meeting>
> > (20th February 2019).>
> >
> > If you have any questions about any of the above, please also use>
> > jcp-o...@apache.org to ask them.>
> >
> > Thanks,>
> >
> > Mark>
> >
> >
> > [1] https://www.eclipse.org/legal/efsl.php>
> > [2] https://www.eclipse.org/legal/tck.php>
> > [3] https://www.eclipse.org/legal/tck.php>
> >
>
>

Re: JakartaEE TCK

[Gurkan Erdogdu]

Hi Cesar

My environment is macOS

Before updating, I received the following error when I run the following
command from tomee-tck and also got some dev/tomee-tck/./target/lib is not
directory errors etc.

./runtests --web tomee-plume
com.sun.ts.tests.ejb30.bb.localaccess.statelessclient

[INFO]

[ERROR] Failed to execute goal
org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
project openejb-tck: java.lang.Exception: Expected one file to be included
into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
excludes=null -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
project openejb-tck: java.lang.Exception: Expected one file to be included
into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
excludes=null
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

On Fri, Jan 18, 2019 at 5:25 AM César Hernández Mendoza <
cesargu...@gmail.com> wrote:

> Hi,
> I was able to set up my local environment and after executing:
> ./runtests --web tomee-plume
> com.sun.ts.tests.ejb30.bb.localaccess.statelessclient
> It seems I got a successful result [1] :).
>
> After reading the readme, I wonder if there is a proper way to split the
> entire set of tests in sub sets?
> My questions arise when I try to think how we can spread the work mentioned
> in Stage 2 and Stage 3 from the readme.
> I think having a shared document with status mapped to this sub sets can be
> useful as a reference to people trying to find areas to help. What do you
> think?
>
> @Gurkan, I executed:
> ./try.sh
> without modifying CommandSupport.groovy and I got a successul result  [2]
> What was the error you had before your changes on CommandSupport.groovy?
>
>
> [1]
>
> ===
>
> 1/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#exceptionTest1
> - PASSED
> 2/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#exceptionTest2
> - PASSED
> 3/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#exceptionTest3
> - PASSED
> 4/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#exceptionTest4
> - PASSED
> 5/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#exceptionTest5
> - PASSED
> 6/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#passByReferenceTest1
> - PASSED
> 7/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#passByReferenceTest2
> - PASSED
> 8/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#passByReferenceTest3
> - PASSED
> 9/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#passByReferenceTest4
> - PASSED
> 10/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#passByReferenceTest5
> - PASSED
> 11/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#passByValueTest
> - PASSED
> 12/-0/?0 -
>
> com/sun/ts/tests/ejb30/bb/localaccess/stat

Re: JakartaEE TCK

[Gurkan Erdogdu]

I have also executed some other tests and successfully PASSED,  Woww,
amazing, working with open source, free TCK :)
Regards.
Gurkan-

On Fri, Jan 18, 2019 at 1:52 AM Gurkan Erdogdu  wrote:

> I have now successfully executed the try.sh and see the PASSED lines :) I
> dont know whether it is true or not but I have done 2 small changes in
> CommandSupport.groovy.
>
> Here:
>
> +builder.appendAll("openejb-core-*.jar")
> +//builder.directory = "${project.build.directory}/lib"
>
>
> -builder.appendAll("openejb-core-*.jar")
> -builder.directory = "${project.build.directory}/lib"
>  builder.appendAll("*.jar")
>  builder.getPath("openejb.porting.classes")
>
> @@ -264,7 +269,7 @@ abstract class CommandSupport {
>  builder.reference("openejb.jee.classes")
>  builder.directory = "${project.build.directory}"
>  builder.append("openejb-tck-*.jar")
> -builder.directory = "${project.build.directory}/lib"
> +builder.directory = "${openejbLib}"
>      builder.append("openejb-lite*.jar")
>  builder.directory = "${javaeetckHome}/lib"
>  builder.append("javatest.jar")
>
> On Thu, Jan 17, 2019 at 2:32 PM Gurkan Erdogdu 
> wrote:
>
>> Hi Jon
>> Yeah I am with master but still receive the same error.
>>
>> On Thu, Jan 17, 2019 at 1:03 PM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>
>>> It looks like you're running into the same issue Jean-Louis had
>>> yesterday -
>>> can you check that you're up to date with master?
>>>
>>> Thanks
>>>
>>> Jon
>>>
>>> On Thu, Jan 17, 2019 at 6:30 AM Gurkan Erdogdu 
>>> wrote:
>>>
>>> > I received the following error when I run the following command from
>>> > tomee-tck, any idea?
>>> >
>>> > ./runtests --web tomee-plume
>>> > com.sun.ts.tests.ejb30.bb.localaccess.statelessclient
>>> >
>>> > [INFO]
>>> >
>>> 
>>> > [ERROR] Failed to execute goal
>>> > org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
>>> > project openejb-tck: java.lang.Exception: Expected one file to be
>>> included
>>> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
>>> > excludes=null -> [Help 1]
>>> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>>> execute
>>> > goal org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment)
>>> on
>>> > project openejb-tck: java.lang.Exception: Expected one file to be
>>> included
>>> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
>>> > excludes=null
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>> > at
>>> >
>>> >
>>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>>> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>>> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>>> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>>> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
>>> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
>>> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
>>> > at sun.reflect.NativeMethodAcces

Re: JakartaEE TCK

[Gurkan Erdogdu]

I have now successfully executed the try.sh and see the PASSED lines :) I
dont know whether it is true or not but I have done 2 small changes in
CommandSupport.groovy.

Here:

+builder.appendAll("openejb-core-*.jar")
+//builder.directory = "${project.build.directory}/lib"


-builder.appendAll("openejb-core-*.jar")
-builder.directory = "${project.build.directory}/lib"
 builder.appendAll("*.jar")
 builder.getPath("openejb.porting.classes")

@@ -264,7 +269,7 @@ abstract class CommandSupport {
 builder.reference("openejb.jee.classes")
 builder.directory = "${project.build.directory}"
 builder.append("openejb-tck-*.jar")
-builder.directory = "${project.build.directory}/lib"
+builder.directory = "${openejbLib}"
 builder.append("openejb-lite*.jar")
 builder.directory = "${javaeetckHome}/lib"
 builder.append("javatest.jar")

On Thu, Jan 17, 2019 at 2:32 PM Gurkan Erdogdu  wrote:

> Hi Jon
> Yeah I am with master but still receive the same error.
>
> On Thu, Jan 17, 2019 at 1:03 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> It looks like you're running into the same issue Jean-Louis had yesterday
>> -
>> can you check that you're up to date with master?
>>
>> Thanks
>>
>> Jon
>>
>> On Thu, Jan 17, 2019 at 6:30 AM Gurkan Erdogdu 
>> wrote:
>>
>> > I received the following error when I run the following command from
>> > tomee-tck, any idea?
>> >
>> > ./runtests --web tomee-plume
>> > com.sun.ts.tests.ejb30.bb.localaccess.statelessclient
>> >
>> > [INFO]
>> > 
>> > [ERROR] Failed to execute goal
>> > org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
>> > project openejb-tck: java.lang.Exception: Expected one file to be
>> included
>> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
>> > excludes=null -> [Help 1]
>> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>> execute
>> > goal org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment)
>> on
>> > project openejb-tck: java.lang.Exception: Expected one file to be
>> included
>> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
>> > excludes=null
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>> > at
>> >
>> >
>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
>> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
>> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> >
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> > at
>> >
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.lang.reflect.Method.invoke(Method.java:498)
>> > at
>> >
>> >
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>> > at
>> >
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>> &g

Re: JakartaEE TCK

[Gurkan Erdogdu]

Hi Jon
Yeah I am with master but still receive the same error.

On Thu, Jan 17, 2019 at 1:03 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> It looks like you're running into the same issue Jean-Louis had yesterday -
> can you check that you're up to date with master?
>
> Thanks
>
> Jon
>
> On Thu, Jan 17, 2019 at 6:30 AM Gurkan Erdogdu 
> wrote:
>
> > I received the following error when I run the following command from
> > tomee-tck, any idea?
> >
> > ./runtests --web tomee-plume
> > com.sun.ts.tests.ejb30.bb.localaccess.statelessclient
> >
> > [INFO]
> > 
> > [ERROR] Failed to execute goal
> > org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
> > project openejb-tck: java.lang.Exception: Expected one file to be
> included
> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
> > excludes=null -> [Help 1]
> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> > goal org.codehaus.gmaven:gmaven-plugin:1.5:execute (setup-environment) on
> > project openejb-tck: java.lang.Exception: Expected one file to be
> included
> > into path; dir=/dev/tomee-tck/./target/lib, includes=openejb-lite*.jar,
> > excludes=null
> > at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> > at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> >
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > at
> >
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> >
> >
> > On Thu, Jan 17, 2019 at 12:26 AM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > Merged, thanks for the PR.
> > >
> > > On Wed, Jan 16, 2019 at 8:21 PM Daniel Cunha 
> > wrote:
> > >
> > > > Hi folks,
> > > >
> > > > You're welcome Bruno.
> > > >
> > > > I opened a PR on tomee-ck to fix the issue that Bruno had.
> > > > Please, review it:
> > > > https://github.com/apache/tomee-tck/pull/5
> > > >
> > > > Em qua, 16 de jan de 2019 às 17:19, Bruno Baptista <
> bruno...@gmail.com
> > >
> > > > escreveu:
> > > >
> > > > > Also working here!
> > > > >
> > > > > Thanks Daniel Cunha for the help you gave me.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Bruno Baptista
> > > > > https://twitter.com/brunobat_
> > > > >
> > > > >
> > > > > On 16/01/19 18:10, Daniel Cunha wrote:
> > > > > > I was missing to export the GF_HOME.
> > > >

Re: JakartaEE TCK

[Gurkan Erdogdu]

gt;  0/-14/?0 -
> > > >>>>>
> > > >>>>>
> > > >>
> > >
> >
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#runtimeExceptionTest3
> > > >>>>> - FAILED
> > > >>>>>  0/-15/?0 -
> > > >>>>>
> > > >>>>>
> > > >>
> > >
> >
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#runtimeExceptionTest4
> > > >>>>> - FAILED
> > > >>>>>  0/-16/?0 -
> > > >>>>>
> > > >>>>>
> > > >>
> > >
> >
> com/sun/ts/tests/ejb30/bb/localaccess/statelessclient/Client#java#runtimeExceptionTest5
> > > >>>>> - FAILED
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>
> > >
> >
> ===
> > > >>>>> Completed running 16 tests (0:00:08.872):
> > > >>>>>
> > > >>>>>  Passed: 0
> > > >>>>>  Failed: 16
> > > >>>>>  Errors: 0
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>
> > >
> >
> ===
> > > >>>>> ?
> > > >>>>>
> > > >>>>> Em qua, 16 de jan de 2019 às 12:48, Jean-Louis Monteiro <
> > > >>>>> jlmonte...@tomitribe.com> escreveu:
> > > >>>>>
> > > >>>>>> works much better. Thank you
> > > >>>>>> --
> > > >>>>>> Jean-Louis Monteiro
> > > >>>>>> http://twitter.com/jlouismonteiro
> > > >>>>>> http://www.tomitribe.com
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Wed, Jan 16, 2019 at 4:45 PM Jonathan Gallimore <
> > > >>>>>> jonathan.gallim...@gmail.com> wrote:
> > > >>>>>>
> > > >>>>>>> Pushed a band-aid fix, that copies deps to target/lib and
> > > >>>>>>> ${openejb.home}/lib. Hopefully this will at least get people
> > > >> going.
> > > >>>>>>> Apologies for the issues.
> > > >>>>>>>
> > > >>>>>>> Jon
> > > >>>>>>>
> > > >>>>>>> On Wed, Jan 16, 2019 at 3:36 PM Jean-Louis Monteiro <
> > > >>>>>>> jlmonte...@tomitribe.com> wrote:
> > > >>>>>>>
> > > >>>>>>>> I am working on it too, no worries. I'll keep you posted
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> Jean-Louis Monteiro
> > > >>>>>>>> http://twitter.com/jlouismonteiro
> > > >>>>>>>> http://www.tomitribe.com
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Wed, Jan 16, 2019 at 4:35 PM Jonathan Gallimore <
> > > >>>>>>>> jonathan.gallim...@gmail.com> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Ok, weird. Something broke when I switched to
> > > >>>>>>>>> maven-dependency-plugin:copy-dependencies from
> > > >>>>>>>>> maven-dependency-plugin:copy.
> > > >>>>>>>>>
> > > >>>>>>>>> Looking into it. Status of this is that it is incredibly raw
> > > >>>>> because
> > > >>>>>>>>> everyone seemed to want it right away, so any help to fix
> > > >>> issues
> > > >>>> is
> > > >>>>>>>>> appreciated.
> > > >>>>>>>>> Jon
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Jan 16, 2019 at 3:29 PM Jonathan Gallimore <
> > > >>>>>>>>> jonathan.gallim...@gmail.com>

Re: JakartaEE TCK

[Gurkan Erdogdu]

I have successfully created the javaeetck-8.0_16-Jan-2019.zip.
My enviornment : macOS  Java(TM) SE Runtime Environment (build
1.8.0_161-b12)
Now, run some TCK tests :)
Regards.
Gurkan

On Tue, Jan 15, 2019 at 6:29 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Currently working on the harness here, and will update the README. Thanks
> for letting us know your result, glad its working.
>
> Jon
>
> On Tue, Jan 15, 2019 at 3:25 PM Bruno Baptista  wrote:
>
> > Success here,
> >
> > Thanks for the instructions, Jon!
> >
> > Got this at the end:
> > drwxr-xr-x  3 brunobat brunobat  4096 jan 15 15:08 ./
> > drwxr-xr-x  3 brunobat brunobat  4096 jan 15 15:06 ../
> > -rw-r--r--  1 brunobat brunobat  4076 jan 15 15:06
> > cts-internal-8.0_15-Jan-2019.zip
> > -rw-r--r--  1 brunobat brunobat  2075 jan 15 15:08
> > excludelist_javaeetck-8.0_15-Jan-2019.zip
> > drwxr-xr-x 13 brunobat brunobat  4096 jan 15 15:06 javaeetck/
> > -rw-r--r--  1 brunobat brunobat 654049181 jan 15 15:08
> > javaeetck-8.0_15-Jan-2019.zip
> >
> > at: jakartaee-tck/release/JAVAEE_BUILD/latest
> >
> > Bruno Baptista
> > https://twitter.com/brunobat_
> >
> >
> > On 15/01/19 14:28, Jonathan Gallimore wrote:
> > > Sorry, use the latest Ant 1.10 as opposed to 1.9.13.
> > >
> > > (Copy/paste error!)
> > >
> > > Thanks
> > >
> > > Jon
> > >
> > > On Tue, Jan 15, 2019 at 2:27 PM Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > >> Ok - could I get someone to give this a shot? (note the different
> > >> Glassfish URL):
> > >>
> > >> git clone https://github.com/eclipse-ee4j/jakartaee-tck
> > >> cd jakaratee-tck
> > >> export WORKSPACE=$(pwd)
> > >> export GF_BUNDLE_URL=
> > >>
> >
> https://jenkins.eclipse.org/glassfish/job/glassfish/job/EE4J_8/85/artifact/bundles/glassfish.zip
> > >> export GF_HOME=$WORKSPACE
> > >> export ANT_HOME=/home/jgallimore/Apps/apache-ant-1.9.13
> > >> export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64
> > >> export PATH=$JAVA_HOME/bin:$ANT_HOME/bin/:$PATH
> > >> $WORKSPACE/docker/build_jakartaeetck.sh
> > >>
> > >> Thanks
> > >>
> > >> Jon
> > >>
> > >> On Tue, Jan 15, 2019 at 2:24 PM César Hernández Mendoza <
> > >> cesargu...@gmail.com> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I also left this running during the night, it seems my laptop heated
> > the
> > >>> office nicely but I also see a lot of this kind of errors [1]:
> > >>> Then I kill the process since basically those `cannot find symbol`
> were
> > >>> all
> > >>> over the log.
> > >>>
> > >>> [1]
> > >>>   [ts.javac]   public void writeBytes(byte[] value) throws
> > JMSException {
> > >>>   [ts.javac]   ^
> > >>>   [ts.javac]   symbol:   class JMSException
> > >>>   [ts.javac]   location: class BytesMessageTestImpl
> > >>>   [ts.javac]
> > >>>
> > >>>
> >
> /Users/cesar/git/jakartaee-tck/src/com/sun/ts/tests/jms/common/BytesMessageTestImpl.java:804:
> > >>> error: cannot find symbol
> > >>>   [ts.javac]   throws JMSException {
> > >>>   [ts.javac]  ^
> > >>>   [ts.javac]   symbol:   class JMSException
> > >>>   [ts.javac]   location: class BytesMessageTestImpl
> > >>>   [ts.javac]
> > >>>
> > >>>
> >
> /Users/cesar/git/jakartaee-tck/src/com/sun/ts/tests/jms/common/BytesMessageTestImpl.java:833:
> > >>> error: cannot find symbol
> > >>>   [ts.javac]   public void writeObject(Object value) throws
> > JMSException {
> > >>>   [ts.javac]^
> > >>>   [ts.javac]   symbol:   class JMSException
> > >>>   [ts.javac]   location: class BytesMessageTestImpl
> > >>>   [ts.javac]
> > >>>
> > >>>
> >
> /Users/cesar/git/jakartaee-tck/src/com/sun/ts/tests/jms/common/BytesMessageTestImpl.java:872:
> > >>> error: cannot find symbol
> > >>>   [ts.javac]   public void reset() throws JMSException {
> > >>>   [ts.javac]  ^
> > >>>   [ts.javac]   symbol:   class JMSException
> > >>>   [ts.javac]   location: class BytesMessageTestImpl
> > >>>   [ts.javac]
> > >>>
> > >>>
> >
> /Users/cesar/git/jakartaee-tck/src/com/sun/ts/tests/jms/common/MessageTestImpl.java:46:
> > >>> error: cannot find symbol
> > >>>   [ts.javac]   private Destination JMSReplyTo;
> > >>>   [ts.javac]   ^
> > >>>   [ts.javac]   symbol:   class Destination
> > >>>   [ts.javac]   location: class MessageTestImpl
> > >>>   [ts.javac]
> > >>>
> > >>>
> >
> /Users/cesar/git/jakartaee-tck/src/com/sun/ts/tests/jms/common/MessageTestImpl.java:48:
> > >>> error: cannot find symbol
> > >>>   [ts.javac]   private Destination JMSDestination;
> > >>>   [ts.javac]   ^
> > >>>   [ts.javac]   symbol:   class Destination
> > >>>   [ts.javac]   location: class MessageTestImpl
> > >>>   [ts.javac]
> > >>>
> > >>>
> >
> /Users/cesar/git/jakartaee-tck/src/com/sun/ts/tests/jms/common/MessageTestImpl.java:90:
> > >>> error: cannot find symbol
> > >>>   [ts.javac]   public String getJMSMessageID() throws JMSException {
> > >>>   [ts.

Re: Jakarta EE TCK

[Gurkan Erdogdu]

Hello David
This is really great news! I did it once for Java EE 6 TCK and would be
happy to do it again for Apache TomEE. I'm sure it will be a very
challenging and enjoyable process :)
How can I access the current TCK runner of TomEE?
Regards.
Gurkan

On Sun, Jan 13, 2019 at 12:28 AM David Blevins 
wrote:

> All,
>
> I've opened a request to have the code we've been using to run the former
> Java EE TCK opened so everyone can run the new Jakarta EE TCK.
>
>  - https://issues.apache.org/jira/browse/INFRA-17633
>
> The history here is that the Java EE TCK was proprietary with significant
> access/usage restrictions and severe language against publicly sharing the
> results.  With these restrictions gone, we can now finally open up the
> harness so people can run the TCK on their machines and start the work to
> help TomEE become Jakarta EE 8 certified.
>
> Stay tuned.
>
> Once this is opened, there'll be a lot of work to move documentation to
> where it needs to be and organize the community as a whole.
>
> As a side note, I can promise you this will be one of the great trills of
> your life.  As I said in this email from Oct 4th 2011, the day TomEE was
> announced as a certified server, "Don't take it for granted because you
> never know if or when it might happen again."
>
>  -
> https://lists.apache.org/thread.html/7227c8881f183eb9f40ac03d17fdd2d5b7a2a019569129a388cb8335@1317793119@%3Cdev.tomee.apache.org%3E
>
> It would take a book to describe the battles that had to be fought for
> years to line up the stars for this day and this opportunity to come
> again.  We are nothing if not extremely tough, extremely passionate and
> unyielding.  We never give up.  We value each other and every contribution
> and therefore we can create the unimaginable and even surprise ourselves.
>
> I am so thrilled we're all standing here in 2018 with an open source TCK
> and the biggest community we've ever had and we get to do it again,
> together, even bigger and better than before.
>
> We are going to have the time of our lives, all 40+ of us .. and growing :)
>
> The world won't know what hit it.  Let's do this! :)
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: Adding Java EE Security 1.0 Spec to geronimo-specs

[Gurkan Erdogdu]

Roberto, is it ok for you?

On Fri, Jan 11, 2019 at 11:22 PM Romain Manni-Bucau 
wrote:

> If Roberto agrees +1
>
> Le ven. 11 janv. 2019 20:29, Gurkan Erdogdu  a écrit
> :
>
> > Hi folks
> > Regarding TomEE, we need to add Java EE Security, JSR-375 spec to
> > geronimo-specs and needs a release. I have committer access to
> > geronimo-specs and added to code (implemented by Roberto Cortez in
> > tomee-security) into my local. Can I commit to code to the
> geronimo-specs?
> > Any objection?
> > Regards.
> > Gurkan
> >
>

Re: Java EE Security API for EE 8

[Gurkan Erdogdu]

I have added geronimo-specs-security_1.0 to geronimo-specs and let
geronimo-dev about the issue. After receiving some response, I can commit
the code.

On Fri, Jan 11, 2019 at 9:50 PM Gurkan Erdogdu  wrote:

> Ok then I created subtask,
> https://issues.apache.org/jira/browse/TOMEE-2453 under the main issue,
> https://issues.apache.org/jira/browse/TOMEE-2365
> Can you please assign it to me?
>
>
> On Fri, Jan 11, 2019 at 12:58 PM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
>> That’d be great.
>> I have commit permissions so if you need help help or something. Lemme
>> know.
>>
>>
>> Le ven. 11 janv. 2019 à 07:12, Gurkan Erdogdu  a
>> écrit :
>>
>> > Hello Roberto
>> > We probably need to move javax.security.enterprise.* package to geronimo
>> > specs project (https://github.com/apache/geronimo-specs) and then
>> adding
>> > dependency to our javaee-api. After that we also need to release
>> > geronimo-specs. If you want, I can work on to create a new project in
>> > geronimo-specs.
>> > Regards.
>> > Gurkan
>> >
>> > On Wed, Jan 9, 2019 at 8:32 PM Roberto Cortez
>> > > >
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > I’ve merged the current state of the code.
>> > >
>> > > In the meanwhile, I’ll write some documentation to help to understand
>> the
>> > > implementation.
>> > >
>> > > Cheers,
>> > > Roberto
>> > >
>> > > > On 8 Jan 2019, at 15:19, Gurkan Erdogdu 
>> wrote:
>> > > >
>> > > > Hello Roberto,
>> > > > Thank you for initiating this integration.
>> > > > Can you prepare a small documentation (and also send to here) which
>> > helps
>> > > > contributors to understand the internals about your current commit.
>> > > > Regards.
>> > > > Gurkan
>> > > >
>> > > >
>> > > > On Tue, Jan 8, 2019 at 6:14 PM Roberto Cortez
>> > > 
>> > > > wrote:
>> > > >
>> > > >> Hi folks,
>> > > >>
>> > > >> I think I’m now done with the FormAuthentication.
>> > > >>
>> > > >> There are still things left to implement. At the moment, the code
>> is
>> > > part
>> > > >> of the project but is not part of the binary. I would like to merge
>> > the
>> > > >> current PR:
>> > > >> https://github.com/apache/tomee/pull/277 <
>> > > >> https://github.com/apache/tomee/pull/277>
>> > > >>
>> > > >> I think this will give a chance for the community to contribute
>> some
>> > of
>> > > >> the missing pieces. I can make a list in JIRA.
>> > > >>
>> > > >> So, if there is no strong opinions about merging this, I will be
>> doing
>> > > >> this in the end of the day.
>> > > >>
>> > > >> Cheers,
>> > > >> Roberto
>> > > >>
>> > > >>> On 30 Dec 2018, at 23:42, Roberto Cortez 
>> > wrote:
>> > > >>>
>> > > >>> Thanks! I’ll have a look!
>> > > >>>
>> > > >>>> On 28 Dec 2018, at 20:34, David Jencks > >
>> > > >> wrote:
>> > > >>>>
>> > > >>>> Perhaps I didn’t recall correctly, or perhaps I implemented it
>> for
>> > > >> Jetty (at eclipse).  The code I’ve found at
>> > > >>
>> > >
>> >
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
>> > > >> <
>> > > >>
>> > >
>> >
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
>> > > >
>> > > >> includes a FormAuthenticator and a JaspiAuthenticator.  I don’t
>> recall
>> > > any
>> > > >> details of how I modified tomcat’s auth setup: I might have made
>> one
>> > > that
>> > > >> was more adapted to JASPIC and the geronimo security framework than
>> > the
>> > > >> plain tomcat one.  If this code is of

Adding Java EE Security 1.0 Spec to geronimo-specs

[Gurkan Erdogdu]

Hi folks
Regarding TomEE, we need to add Java EE Security, JSR-375 spec to
geronimo-specs and needs a release. I have committer access to
geronimo-specs and added to code (implemented by Roberto Cortez in
tomee-security) into my local. Can I commit to code to the geronimo-specs?
Any objection?
Regards.
Gurkan

Re: Java EE Security API for EE 8

[Gurkan Erdogdu]

Ok then I created subtask, https://issues.apache.org/jira/browse/TOMEE-2453
under the main issue, https://issues.apache.org/jira/browse/TOMEE-2365
Can you please assign it to me?


On Fri, Jan 11, 2019 at 12:58 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> That’d be great.
> I have commit permissions so if you need help help or something. Lemme
> know.
>
>
> Le ven. 11 janv. 2019 à 07:12, Gurkan Erdogdu  a
> écrit :
>
> > Hello Roberto
> > We probably need to move javax.security.enterprise.* package to geronimo
> > specs project (https://github.com/apache/geronimo-specs) and then adding
> > dependency to our javaee-api. After that we also need to release
> > geronimo-specs. If you want, I can work on to create a new project in
> > geronimo-specs.
> > Regards.
> > Gurkan
> >
> > On Wed, Jan 9, 2019 at 8:32 PM Roberto Cortez
>  > >
> > wrote:
> >
> > > Hi,
> > >
> > > I’ve merged the current state of the code.
> > >
> > > In the meanwhile, I’ll write some documentation to help to understand
> the
> > > implementation.
> > >
> > > Cheers,
> > > Roberto
> > >
> > > > On 8 Jan 2019, at 15:19, Gurkan Erdogdu  wrote:
> > > >
> > > > Hello Roberto,
> > > > Thank you for initiating this integration.
> > > > Can you prepare a small documentation (and also send to here) which
> > helps
> > > > contributors to understand the internals about your current commit.
> > > > Regards.
> > > > Gurkan
> > > >
> > > >
> > > > On Tue, Jan 8, 2019 at 6:14 PM Roberto Cortez
> > > 
> > > > wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> I think I’m now done with the FormAuthentication.
> > > >>
> > > >> There are still things left to implement. At the moment, the code is
> > > part
> > > >> of the project but is not part of the binary. I would like to merge
> > the
> > > >> current PR:
> > > >> https://github.com/apache/tomee/pull/277 <
> > > >> https://github.com/apache/tomee/pull/277>
> > > >>
> > > >> I think this will give a chance for the community to contribute some
> > of
> > > >> the missing pieces. I can make a list in JIRA.
> > > >>
> > > >> So, if there is no strong opinions about merging this, I will be
> doing
> > > >> this in the end of the day.
> > > >>
> > > >> Cheers,
> > > >> Roberto
> > > >>
> > > >>> On 30 Dec 2018, at 23:42, Roberto Cortez 
> > wrote:
> > > >>>
> > > >>> Thanks! I’ll have a look!
> > > >>>
> > > >>>> On 28 Dec 2018, at 20:34, David Jencks 
> > > >> wrote:
> > > >>>>
> > > >>>> Perhaps I didn’t recall correctly, or perhaps I implemented it for
> > > >> Jetty (at eclipse).  The code I’ve found at
> > > >>
> > >
> >
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
> > > >> <
> > > >>
> > >
> >
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
> > > >
> > > >> includes a FormAuthenticator and a JaspiAuthenticator.  I don’t
> recall
> > > any
> > > >> details of how I modified tomcat’s auth setup: I might have made one
> > > that
> > > >> was more adapted to JASPIC and the geronimo security framework than
> > the
> > > >> plain tomcat one.  If this code is of any use to you, great,
> > otherwise,
> > > >> good luck!
> > > >>>>
> > > >>>> many thanks
> > > >>>> David Jencks
> > > >>>>
> > > >>>>> On Dec 28, 2018, at 1:47 AM, Roberto Cortez
> > > >>  wrote:
> > > >>>>>
> > > >>>>> Hi David,
> > > >>>>>
> > > >>>>> Actually, the EE 8 Security spec tells you to use a JASPIC bridge
> > > >> underneath the implementation, so your code might be a good fit. Can
> > you
> > > >> po

Re: Java EE Security API for EE 8

[Gurkan Erdogdu]

Hello Roberto
We probably need to move javax.security.enterprise.* package to geronimo
specs project (https://github.com/apache/geronimo-specs) and then adding
dependency to our javaee-api. After that we also need to release
geronimo-specs. If you want, I can work on to create a new project in
geronimo-specs.
Regards.
Gurkan

On Wed, Jan 9, 2019 at 8:32 PM Roberto Cortez 
wrote:

> Hi,
>
> I’ve merged the current state of the code.
>
> In the meanwhile, I’ll write some documentation to help to understand the
> implementation.
>
> Cheers,
> Roberto
>
> > On 8 Jan 2019, at 15:19, Gurkan Erdogdu  wrote:
> >
> > Hello Roberto,
> > Thank you for initiating this integration.
> > Can you prepare a small documentation (and also send to here) which helps
> > contributors to understand the internals about your current commit.
> > Regards.
> > Gurkan
> >
> >
> > On Tue, Jan 8, 2019 at 6:14 PM Roberto Cortez
> 
> > wrote:
> >
> >> Hi folks,
> >>
> >> I think I’m now done with the FormAuthentication.
> >>
> >> There are still things left to implement. At the moment, the code is
> part
> >> of the project but is not part of the binary. I would like to merge the
> >> current PR:
> >> https://github.com/apache/tomee/pull/277 <
> >> https://github.com/apache/tomee/pull/277>
> >>
> >> I think this will give a chance for the community to contribute some of
> >> the missing pieces. I can make a list in JIRA.
> >>
> >> So, if there is no strong opinions about merging this, I will be doing
> >> this in the end of the day.
> >>
> >> Cheers,
> >> Roberto
> >>
> >>> On 30 Dec 2018, at 23:42, Roberto Cortez  wrote:
> >>>
> >>> Thanks! I’ll have a look!
> >>>
> >>>> On 28 Dec 2018, at 20:34, David Jencks 
> >> wrote:
> >>>>
> >>>> Perhaps I didn’t recall correctly, or perhaps I implemented it for
> >> Jetty (at eclipse).  The code I’ve found at
> >>
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
> >> <
> >>
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
> >
> >> includes a FormAuthenticator and a JaspiAuthenticator.  I don’t recall
> any
> >> details of how I modified tomcat’s auth setup: I might have made one
> that
> >> was more adapted to JASPIC and the geronimo security framework than the
> >> plain tomcat one.  If this code is of any use to you, great, otherwise,
> >> good luck!
> >>>>
> >>>> many thanks
> >>>> David Jencks
> >>>>
> >>>>> On Dec 28, 2018, at 1:47 AM, Roberto Cortez
> >>  wrote:
> >>>>>
> >>>>> Hi David,
> >>>>>
> >>>>> Actually, the EE 8 Security spec tells you to use a JASPIC bridge
> >> underneath the implementation, so your code might be a good fit. Can you
> >> point me out to the sources so I can have a look?
> >>>>>
> >>>>> Thank you!
> >>>>>
> >>>>> Cheers,
> >>>>> Roberto
> >>>>>
> >>>>>> On 28 Dec 2018, at 03:40, David Jencks 
> >> wrote:
> >>>>>>
> >>>>>> IIRC I wrote a JASPIC form authentication for the geronimo server
> >> long ago. Although the JASPIC deployment model was somewhat
> >> incomprehensibly bizarre, the conversation model was very nice.
> Depending
> >> on what the EE 8 api is (I haven’t looked) the JASPIC implementation
> might
> >> be a source for webserver-independent code for from authentication that
> >> could be easily adapted.
> >>>>>>
> >>>>>> David Jencks
> >>>>>>
> >>>>>>> On Dec 27, 2018, at 3:53 PM, Roberto Cortez
> >>  wrote:
> >>>>>>>
> >>>>>>> Update:
> >>>>>>>
> >>>>>>> I’ve started the implementation of the FormAuthenticationMechanism.
> >> Is not as easy as it sounds, since it requires some conversation chat
> >> across requests. I thought about wrapping all the logic and use the
> Tomcat
> >> FormAuthenticator, since it does ex

Re: How can I contribute?

[Gurkan Erdogdu]

Hi Richard
He can start with adding comments to Java source files. There are documents
here, http://tomee.apache.org/dev/ which reflects Java files under tomee
source code. He can open an issue under
https://issues.apache.org/jira/browse/TOMEE-2450 as subtask (example :
https://issues.apache.org/jira/browse/TOMEE-2451)
Regards.
Gurkan

On Thu, Jan 10, 2019 at 6:53 AM Richard Monson-Haefel <
monsonhae...@gmail.com> wrote:

> Hi Everyone.  What should Venu work on? Can you give him some ideas?
>
> On Wed, Jan 9, 2019 at 9:49 PM Venu Krishnan  wrote:
>
> > Thanks Richard, have gone through the community wiki, downloaded source
> > code and built it.
> >
> > Could you please advice me on what to work on. I see in other posts
> > advising to working micro profile examples(TOMEE-2285) for new comers,
> but
> > I am open to any suggestions.
> >
> > Thanks
> > Venu
> >
> >
> > On Sat, Jan 5, 2019 at 9:34 AM Richard Monson-Haefel <
> > monsonhae...@gmail.com>
> > wrote:
> >
> > > Welcome, Venu!
> > >
> > > A great place to start is on our contributor's tips page.  Read that
> and
> > > when ready, ping the list for advice on what to work on.  Here is the
> > link
> > >
> > > http://tomee.apache.org/community/index.html
> > >
> > > We're glad to have you on board!
> > >
> > > On Fri, Jan 4, 2019 at 11:07 PM Venu Krishnan 
> > > wrote:
> > >
> > > > Hello Team:
> > > >
> > > > This is Venu from Toronto, Canada. Have been a TomEE user for quite
> > > > sometime and would like to learn more by contributing to it with open
> > > > source community, I have 10+ years of experience focused on backend
> > > > development in Java, JEE, Spring, webservices, middleware
> technologies
> > > in a
> > > > financial domain.
> > > >
> > > > I have been a silent watcher of dev mailing list for sometime now and
> > > want
> > > > to introduce myself to team and start working with you all.
> > > >
> > > > Apache open source projects are always inspiring and particularly
> TomEE
> > > > that I would like to start with.
> > > >
> > > > Thanks and looking forward.
> > > >
> > > > Regards
> > > >
> > >
> > >
> > > --
> > > Richard Monson-Haefel
> > > https://twitter.com/rmonson
> > > https://www.linkedin.com/in/monsonhaefel/
> > >
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Java EE Security API for EE 8

[Gurkan Erdogdu]

Hello Roberto,
Thank you for initiating this integration.
Can you prepare a small documentation (and also send to here) which helps
contributors to understand the internals about your current commit.
Regards.
Gurkan


On Tue, Jan 8, 2019 at 6:14 PM Roberto Cortez 
wrote:

> Hi folks,
>
> I think I’m now done with the FormAuthentication.
>
> There are still things left to implement. At the moment, the code is part
> of the project but is not part of the binary. I would like to merge the
> current PR:
> https://github.com/apache/tomee/pull/277 <
> https://github.com/apache/tomee/pull/277>
>
> I think this will give a chance for the community to contribute some of
> the missing pieces. I can make a list in JIRA.
>
> So, if there is no strong opinions about merging this, I will be doing
> this in the end of the day.
>
> Cheers,
> Roberto
>
> > On 30 Dec 2018, at 23:42, Roberto Cortez  wrote:
> >
> > Thanks! I’ll have a look!
> >
> >> On 28 Dec 2018, at 20:34, David Jencks 
> wrote:
> >>
> >> Perhaps I didn’t recall correctly, or perhaps I implemented it for
> Jetty (at eclipse).  The code I’ve found at
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/
> <
> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/geronimo-tomcat7/src/main/java/org/apache/geronimo/tomcat/security/authentication/>
> includes a FormAuthenticator and a JaspiAuthenticator.  I don’t recall any
> details of how I modified tomcat’s auth setup: I might have made one that
> was more adapted to JASPIC and the geronimo security framework than the
> plain tomcat one.  If this code is of any use to you, great, otherwise,
> good luck!
> >>
> >> many thanks
> >> David Jencks
> >>
> >>> On Dec 28, 2018, at 1:47 AM, Roberto Cortez
>  wrote:
> >>>
> >>> Hi David,
> >>>
> >>> Actually, the EE 8 Security spec tells you to use a JASPIC bridge
> underneath the implementation, so your code might be a good fit. Can you
> point me out to the sources so I can have a look?
> >>>
> >>> Thank you!
> >>>
> >>> Cheers,
> >>> Roberto
> >>>
>  On 28 Dec 2018, at 03:40, David Jencks 
> wrote:
> 
>  IIRC I wrote a JASPIC form authentication for the geronimo server
> long ago. Although the JASPIC deployment model was somewhat
> incomprehensibly bizarre, the conversation model was very nice. Depending
> on what the EE 8 api is (I haven’t looked) the JASPIC implementation might
> be a source for webserver-independent code for from authentication that
> could be easily adapted.
> 
>  David Jencks
> 
> > On Dec 27, 2018, at 3:53 PM, Roberto Cortez
>  wrote:
> >
> > Update:
> >
> > I’ve started the implementation of the FormAuthenticationMechanism.
> Is not as easy as it sounds, since it requires some conversation chat
> across requests. I thought about wrapping all the logic and use the Tomcat
> FormAuthenticator, since it does exactly what we need. Unfortunately, it is
> too tied to the Tomcat code and it would require to instantiate a lot to
> Tomcat objects to be able to use it. I’m not sure if it would be worth it.
> I ended up following the spec suggestion to use a CDI interceptor and I’m
> copying / reusing some pieces of the FormAuthentication when possible.
> >
> > PR updated:
> > https://github.com/apache/tomee/pull/277 <
> https://github.com/apache/tomee/pull/277>
> >
> > Cheers,
> > Roberto
> >
> >> On 26 Dec 2018, at 22:11, Roberto Cortez
>  wrote:
> >>
> >> Hi folks,
> >>
> >> I’ve updated the PR with new changes:
> >>
> >> - I’ve implemented a CDI Extension to create
> AuthenticationMechanism beans and a CDI class to keep track of the mapping
> between the authentication mechanism and the servlet that should be
> checked. When a Servlet is executed the mapping is checked and if there is
> and associated AuthenticationMechanism, we validate the request with the
> associated type (Basic, Form, etc).
> >>
> >> - Implemented the BasicAuthenticationMechanism and all the plumbing
> required to be executed. This required an HttpMessageContext to pass
> information around, plus store some state to make decisions on things to
> do, including the CallbackHandler to pass in additional Callbacks to create
> the Principal and Groups
> >>
> >> - A default IdentityStore, using the Tomcat UserDatabase, that
> reads user data from tomcat-users.xml
> >>
> >> I’ll probably move to implement the missing
> AuthenticationMechanisms (FORM and Custom) next.
> >>
> >> Any feedback, always welcomed :)
> >>
> >> Cheers,
> >> Roberto
> >>
> >>> On 19 Dec 2018, at 10:00, Bruno Baptista 
> wrote:
> >>>
> >>> TomEE Security works for me.
> >>>
> >>> Bruno Baptista
> >>> https://twitter.com/brunobat_
> >>>
> >>>
> >>> On 19/12/18 00:20, Roberto Cortez wrote:
>  Hi folks,
> 
> 

Re: Javadoc is online / How deployment works

[Gurkan Erdogdu]

Hello team
I have just opened an issue,
https://issues.apache.org/jira/browse/TOMEE-2450 to track all Java source
code comments. This will be the parent issue to track all sub-tasks. If you
want to work on Java Source file to update with comments, please open a
sub-task under this issue. I have already opened for me,
https://issues.apache.org/jira/browse/TOMEE-2451
I am not able to assign this to me, because I have no authorization.
Regards
Gurkan

On Mon, Jan 7, 2019 at 6:04 AM David Blevins 
wrote:

> > On Jan 6, 2019, at 1:23 PM, Gurkan Erdogdu  wrote:
> >
> > Thank you David.
> > One question, do we need to comment on the interface or concrete class?
> For
> > example, Assembler interface in org.apache.openejb.spi package? I think
> > commenting on the interface is better and then for extra comments in
> > concrete class.
>
> I think that's a good approach; interface where possible, concrete class
> where there are implementation specific details.  The goals are definitely
> interface worthy.  All the information about AnnotationDeployer and
> AppModule is specific to the concrete class, also known as the
> ClassicAssembler.
>
> Here's some old docs on it.
>
>  - http://tomee.apache.org/dev/design-assembler.html
>
> Likely we should move that info into the classes themselves, then delete
> those pages so we don't have repetitive (and therefore hard to maintain)
> sources of truth.
>
>
> -David
>
>
>

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Thanks all.
Hope clear all conflicts. Jon, can you now merge the PR?
Regards.
Gurkan

On Mon, Jan 7, 2019 at 5:21 PM Jean-Louis Monteiro 
wrote:

> Yes I agree and take it as you describe so it's all good. It's definitely a
> step forward
>
> Le lun. 7 janv. 2019 à 12:21, Gurkan Erdogdu  a
> écrit :
>
> > Hello Jean-Louis and team,
> > I want to emphasize again that this PR will not change anything regarding
> > system properties. Its sole aim is to centralize all literal system
> > properties into its own module. Maybe, for the future, if needed, we can
> > update this module to add more configuration related functions. Currently
> > all literal constants are distributed around the codebase. Before adding
> > any more property, we need to discuss it first in here. So, one can
> easily
> > find the used property this way.
> > Regards.
> > Gurkan
> >
> > On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com>
> > wrote:
> >
> > > Just want to make sure we don't forget System Properties were meant to
> be
> > > used to override configuration and not to be the main configuration
> > system
> > > for TomEE.
> > >
> > > We can discuss it and decide to change our mind and TomEE, but as per
> > now,
> > > I'm not really keen to relying on system properties to configure TomEE.
> > I'd
> > > rather take the opportunity to yank some system properties when
> possible.
> > >
> > >
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu 
> > wrote:
> > >
> > > > Thanks Jon.
> > > >
> > > > I don't have any aim to replace service-jar.xml approach. We will
> just
> > > add
> > > > another YAML based configuration support. Therefore, all tomee.xml,
> > > > resources.xml etc will be stay in there. YAML is just an additional
> > > > feature.
> > > >
> > > > Introducing new module , tomee-config, allow us to centralise all
> > > > configuration into one place and all other modules can use it via
> > > > dependency. In the future, we can remove all configuration codes from
> > > > openejb-core, etc. into this module. There are lots of system
> > properties
> > > > using in different modules, therefore each such module will add their
> > > > properties into TomEESystemConfig class and then use it.
> > > >
> > > > Currently, openejb-core is a one large module. We may also think to
> > > divide
> > > > this module into smaller modules which are having special purpose.
> > > >
> > > > Hope it clears your concerns.
> > > >
> > > > Regards.
> > > > Gurkan
> > > >
> > > > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > > > I commented on your PR - thanks for sending that over. I think it
> > would
> > > > be
> > > > > worthwhile structuring the class with the constants in such a way
> > that
> > > > the
> > > > > javadoc could end up on the website via David's site generation
> code.
> > > > That
> > > > > would be extremely cool and I'm sure a very useful piece of
> > > > documentation.
> > > > >
> > > > > While I appreciate your service-jar.xml visibility comment, I
> suspect
> > > > that
> > > > > is because of something missing in its documentation, as opposed to
> > an
> > > > > issue with the design choice. I don't necessarily object to
> something
> > > > that
> > > > > can parse the config in YAML (I believe there is something that
> > handles
> > > > > JSON already), providing the existing config mechanism in XML, with
> > the
> > > > > defaults in service-jar.xml continued to work, and that I wouldn't
> be
> > > > > forced to migrate from XML to YAML. Many users make use of
> tomee.xml
> > > and
> > > > > resources.xml in a huge number of applications. Forcing a migration
> > on
> > > > them
> > > > > to YAML "just because" doesn't make sense to me. The concept of the

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Hello Jean-Louis and team,
I want to emphasize again that this PR will not change anything regarding
system properties. Its sole aim is to centralize all literal system
properties into its own module. Maybe, for the future, if needed, we can
update this module to add more configuration related functions. Currently
all literal constants are distributed around the codebase. Before adding
any more property, we need to discuss it first in here. So, one can easily
find the used property this way.
Regards.
Gurkan

On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro 
wrote:

> Just want to make sure we don't forget System Properties were meant to be
> used to override configuration and not to be the main configuration system
> for TomEE.
>
> We can discuss it and decide to change our mind and TomEE, but as per now,
> I'm not really keen to relying on system properties to configure TomEE. I'd
> rather take the opportunity to yank some system properties when possible.
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu  wrote:
>
> > Thanks Jon.
> >
> > I don't have any aim to replace service-jar.xml approach. We will just
> add
> > another YAML based configuration support. Therefore, all tomee.xml,
> > resources.xml etc will be stay in there. YAML is just an additional
> > feature.
> >
> > Introducing new module , tomee-config, allow us to centralise all
> > configuration into one place and all other modules can use it via
> > dependency. In the future, we can remove all configuration codes from
> > openejb-core, etc. into this module. There are lots of system properties
> > using in different modules, therefore each such module will add their
> > properties into TomEESystemConfig class and then use it.
> >
> > Currently, openejb-core is a one large module. We may also think to
> divide
> > this module into smaller modules which are having special purpose.
> >
> > Hope it clears your concerns.
> >
> > Regards.
> > Gurkan
> >
> > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > I commented on your PR - thanks for sending that over. I think it would
> > be
> > > worthwhile structuring the class with the constants in such a way that
> > the
> > > javadoc could end up on the website via David's site generation code.
> > That
> > > would be extremely cool and I'm sure a very useful piece of
> > documentation.
> > >
> > > While I appreciate your service-jar.xml visibility comment, I suspect
> > that
> > > is because of something missing in its documentation, as opposed to an
> > > issue with the design choice. I don't necessarily object to something
> > that
> > > can parse the config in YAML (I believe there is something that handles
> > > JSON already), providing the existing config mechanism in XML, with the
> > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> and
> > > resources.xml in a huge number of applications. Forcing a migration on
> > them
> > > to YAML "just because" doesn't make sense to me. The concept of the
> > > service-jar.xml is a very core design concept in TomEE and I would not
> be
> > > favour of changing it unless there was a really good rationale and a
> > better
> > > design proposed and discussed.
> > >
> > > I agree that system properties can lead to "magic" parameters that
> aren't
> > > well documented, and I'm definitely in favour of improving the
> > > documentation of those properties. The ability to override config with
> > > system properties, however, is useful and also widely used so we'll
> need
> > to
> > > keep it.
> > >
> > > Jon
> > >
> > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu 
> > wrote:
> > >
> > > > For me, using services-jar.xml approach is not so visible to users.
> All
> > > > defaults are configured in this file and packaged within JAR file.
> > Users
> > > > are not able to read the parameter explanation from services-jar.xml
> > > files.
> > > > Also, services.-jar.xml is somebit different from using the system
> > > > properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > > > based c

Re: Javadoc is online / How deployment works

[Gurkan Erdogdu]

Thank you David.
One question, do we need to comment on the interface or concrete class? For
example, Assembler interface in org.apache.openejb.spi package? I think
commenting on the interface is better and then for extra comments in
concrete class.
Regards.
Gurkan

On Sat, Jan 5, 2019 at 10:59 PM David Blevins 
wrote:

> Javadoc is now online!  I still have more ideas for hacking on it, but
> it's good enough to open up for more people to start filling in
> documentation.
>
> Some important classes
>
> When you deploy an application, all annotations and xml are merged into
> one single meta-data tree by this class.  After this point, annotations and
> xml are no longer read or referenced.  It outputs an AppModule which is a
> mutable object and a little bit "fancy."
>
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/config/AnnotationDeployer.html
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/config/AppModule.html
>
> The next major step is this class which will take this data and analyze
> it, figuring out what corresponding container parts would need to be built
> in order to run the app as described.  It outputs an AppInfo which is an
> immutable data object that can have no methods or logic whatsoever.  After
> this point, the complexity of roughly 100k lines of deployment code is
> erased and all that remains is the AppInfo tree.  This tree can be thought
> of as an AST (abstract syntax tree) using compiler terms.
>
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/config/ConfigurationFactory.html
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/assembler/classic/AppInfo.html
>
> The AppInfo is blindly built by the Assembler.  The Assembler does no
> validation.  It should have been done in the steps leading to the creation
> of the AppInfo.  The objects built by the Assembler are the true,
> thread-safe, runtime objects that make your apps actually work (aka the
> "runtime").  The Assembler is the only bit of code allowed to see both the
> AppInfo and the runtime classes.  The runtime classes themselves are not
> allowed to see the AppInfo tree or the Assembler.  After this point the
> AppInfo tree and Assembler itself are gone.
>
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/assembler/classic/Assembler.html
>
> Now you have a working and running container wrapped around your code and
> ready to serve requests.  This runtime is completely unaware of what came
> before it or built it and therefore it's most simple self.  This runtime is
> as immutable as possible and thread-safe.
>
> This process is a major part of why TomEE is so light at runtime.  The
> deployment process is a bit like launching a space shuttle where heavy bits
> keep falling away until only a tiny part remains.
>
> The best way to understand that code is to study the Assembler is it is
> the last "heavy bit" that builds the actual runtime, before falling away
> itself.
>
>
>
> Contribution Opportunity:
>
>  - Take this email and try and fill out the Javadoc of the referenced
> classes
>
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Thank you Jon!

On Fri, Jan 4, 2019 at 5:35 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Thanks for the explanation, I appreciate it. As long as there's no
> objections I'll merge the PR in.
>
> Jon
>
> On Fri, Jan 4, 2019 at 6:28 AM Gurkan Erdogdu  wrote:
>
> > Thanks Jon.
> >
> > I don't have any aim to replace service-jar.xml approach. We will just
> add
> > another YAML based configuration support. Therefore, all tomee.xml,
> > resources.xml etc will be stay in there. YAML is just an additional
> > feature.
> >
> > Introducing new module , tomee-config, allow us to centralise all
> > configuration into one place and all other modules can use it via
> > dependency. In the future, we can remove all configuration codes from
> > openejb-core, etc. into this module. There are lots of system properties
> > using in different modules, therefore each such module will add their
> > properties into TomEESystemConfig class and then use it.
> >
> > Currently, openejb-core is a one large module. We may also think to
> divide
> > this module into smaller modules which are having special purpose.
> >
> > Hope it clears your concerns.
> >
> > Regards.
> > Gurkan
> >
> > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > I commented on your PR - thanks for sending that over. I think it would
> > be
> > > worthwhile structuring the class with the constants in such a way that
> > the
> > > javadoc could end up on the website via David's site generation code.
> > That
> > > would be extremely cool and I'm sure a very useful piece of
> > documentation.
> > >
> > > While I appreciate your service-jar.xml visibility comment, I suspect
> > that
> > > is because of something missing in its documentation, as opposed to an
> > > issue with the design choice. I don't necessarily object to something
> > that
> > > can parse the config in YAML (I believe there is something that handles
> > > JSON already), providing the existing config mechanism in XML, with the
> > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> and
> > > resources.xml in a huge number of applications. Forcing a migration on
> > them
> > > to YAML "just because" doesn't make sense to me. The concept of the
> > > service-jar.xml is a very core design concept in TomEE and I would not
> be
> > > favour of changing it unless there was a really good rationale and a
> > better
> > > design proposed and discussed.
> > >
> > > I agree that system properties can lead to "magic" parameters that
> aren't
> > > well documented, and I'm definitely in favour of improving the
> > > documentation of those properties. The ability to override config with
> > > system properties, however, is useful and also widely used so we'll
> need
> > to
> > > keep it.
> > >
> > > Jon
> > >
> > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu 
> > wrote:
> > >
> > > > For me, using services-jar.xml approach is not so visible to users.
> All
> > > > defaults are configured in this file and packaged within JAR file.
> > Users
> > > > are not able to read the parameter explanation from services-jar.xml
> > > files.
> > > > Also, services.-jar.xml is somebit different from using the system
> > > > properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > > > based configuration.
> > > >
> > > > But first step is to centralise all of these system parameters into
> two
> > > > classes. Maybe, we will see that some of them are unnecessary etc.
> > > >
> > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista 
> > > wrote:
> > > >
> > > > > Yes, there is.
> > > > >
> > > > > This is also the most basic MP spec and nothing prevents us from
> > using
> > > > > it everywhere.
> > > > >
> > > > > There might be Jakarta EE restrictions in how to handle
> > configurations
> > > > > that need to be assessed.
> > > > >
> > > > > Overall, I think that if we are going to mess with configs, we
> should
> > &

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Thanks Jon.

I don't have any aim to replace service-jar.xml approach. We will just add
another YAML based configuration support. Therefore, all tomee.xml,
resources.xml etc will be stay in there. YAML is just an additional
feature.

Introducing new module , tomee-config, allow us to centralise all
configuration into one place and all other modules can use it via
dependency. In the future, we can remove all configuration codes from
openejb-core, etc. into this module. There are lots of system properties
using in different modules, therefore each such module will add their
properties into TomEESystemConfig class and then use it.

Currently, openejb-core is a one large module. We may also think to divide
this module into smaller modules which are having special purpose.

Hope it clears your concerns.

Regards.
Gurkan

On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> I commented on your PR - thanks for sending that over. I think it would be
> worthwhile structuring the class with the constants in such a way that the
> javadoc could end up on the website via David's site generation code. That
> would be extremely cool and I'm sure a very useful piece of documentation.
>
> While I appreciate your service-jar.xml visibility comment, I suspect that
> is because of something missing in its documentation, as opposed to an
> issue with the design choice. I don't necessarily object to something that
> can parse the config in YAML (I believe there is something that handles
> JSON already), providing the existing config mechanism in XML, with the
> defaults in service-jar.xml continued to work, and that I wouldn't be
> forced to migrate from XML to YAML. Many users make use of tomee.xml and
> resources.xml in a huge number of applications. Forcing a migration on them
> to YAML "just because" doesn't make sense to me. The concept of the
> service-jar.xml is a very core design concept in TomEE and I would not be
> favour of changing it unless there was a really good rationale and a better
> design proposed and discussed.
>
> I agree that system properties can lead to "magic" parameters that aren't
> well documented, and I'm definitely in favour of improving the
> documentation of those properties. The ability to override config with
> system properties, however, is useful and also widely used so we'll need to
> keep it.
>
> Jon
>
> On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu  wrote:
>
> > For me, using services-jar.xml approach is not so visible to users. All
> > defaults are configured in this file and packaged within JAR file. Users
> > are not able to read the parameter explanation from services-jar.xml
> files.
> > Also, services.-jar.xml is somebit different from using the system
> > properties to turn-on/off something. I am also thinking to introduce YAML
> > based configuration.
> >
> > But first step is to centralise all of these system parameters into two
> > classes. Maybe, we will see that some of them are unnecessary etc.
> >
> > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista 
> wrote:
> >
> > > Yes, there is.
> > >
> > > This is also the most basic MP spec and nothing prevents us from using
> > > it everywhere.
> > >
> > > There might be Jakarta EE restrictions in how to handle configurations
> > > that need to be assessed.
> > >
> > > Overall, I think that if we are going to mess with configs, we should
> > > use state of the art.
> > >
> > > Cheers
> > >
> > > Bruno Baptista
> > > https://twitter.com/brunobat_
> > >
> > >
> > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > I think with microprofile-config we may have a chicken and the egg
> > > problem,
> > > > isn't it?
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista 
> > > wrote:
> > > >
> > > >> Hi Gurkan,
> > > >>
> > > >> I agree we have a problem with the documentation of the different
> > > >> properties and that we need to improve it.
> > > >>
> > > >> Doing the inventory and using the proposed syntax looks ok to me
> but I
> > > >> also think we should go even further.
> > > >>
> > > >> How about to migrate all the properties to use microprofile-config?
> > > >>
> 

Re: TomEE logo poll

[Gurkan Erdogdu]

+1

On Wed, Jan 2, 2019 at 2:51 PM Daniel Cunha  wrote:

> +1
>
> Em qua, 2 de jan de 2019 às 08:40, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> escreveu:
>
> > Would be nice to get some +1 or -1 from some committers here :)
> >
> > On Fri, Dec 28, 2018 at 9:31 PM Bruno Baptista 
> wrote:
> >
> > > +1
> > >
> > > Bruno Baptista
> > > https://twitter.com/brunobat_
> > >
> > >
> > > On 28/12/18 16:32, Ivan Junckes Filho wrote:
> > > > Hey guys, we have been through this discussion before but I don't
> think
> > > we
> > > > ever had a conclusion. In my opinion would be very important for the
> > > > project to have a logo and now TomEE is getting a lot of exposure why
> > not
> > > > take advantage of the moment and promote TomEE even more with a great
> > > logo?
> > > >
> > > > These are some options proposed in the past:
> > > > https://issues.apache.org/jira/browse/TOMEE-574
> > > >
> > > > We could do something like David did here for JakartaEE:
> > > > https://github.com/eclipse-ee4j/ee4j/issues/11
> > > >
> > > > And the winning logo would be the one with the most number of thumbs
> > up.
> > > >
> > > > What do you guys think?
> > > >
> > >
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

I created a pull request, https://github.com/apache/tomee/pull/343
New maven project tomee-config is introduced with single class,
TomEESystemConfig. This will include all system properties for tomee.*
Also updated TomcatWebAppBuilder to remove some tomee.* properties and use
the config class provided. Need to remove all others from the code base and
use this class.
Can you please check?

On Wed, Jan 2, 2019 at 1:31 PM Jean-Louis Monteiro 
wrote:

> Agreed. For such a critical and low level need on the system, I'm not so
> fan about creating a hard dependency on a spec and an implementation.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Jan 2, 2019 at 11:26 AM Roberto Cortez  >
> wrote:
>
> > I think we should stay away from MP Config for now.
> >
> > TomEE does a lot more regarding substitution and config on several places
> > that MP Config doesn’t support.
> >
> > > On 2 Jan 2019, at 09:55, Bruno Baptista  wrote:
> > >
> > > Sounds like a good plan. :)
> > >
> > > Bruno Baptista
> > > https://twitter.com/brunobat_ <https://twitter.com/brunobat_>
> > >
> > > On 02/01/19 09:47, Gurkan Erdogdu wrote:
> > >> For me, using services-jar.xml approach is not so visible to users.
> All
> > >> defaults are configured in this file and packaged within JAR file.
> Users
> > >> are not able to read the parameter explanation from services-jar.xml
> > files.
> > >> Also, services.-jar.xml is somebit different from using the system
> > >> properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > >> based configuration.
> > >>
> > >> But first step is to centralise all of these system parameters into
> two
> > >> classes. Maybe, we will see that some of them are unnecessary etc.
> > >>
> > >> On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista 
> > wrote:
> > >>
> > >>> Yes, there is.
> > >>>
> > >>> This is also the most basic MP spec and nothing prevents us from
> using
> > >>> it everywhere.
> > >>>
> > >>> There might be Jakarta EE restrictions in how to handle
> configurations
> > >>> that need to be assessed.
> > >>>
> > >>> Overall, I think that if we are going to mess with configs, we should
> > >>> use state of the art.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Bruno Baptista
> > >>> https://twitter.com/brunobat_
> > >>>
> > >>>
> > >>> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > >>>> I think with microprofile-config we may have a chicken and the egg
> > >>> problem,
> > >>>> isn't it?
> > >>>> --
> > >>>> Jean-Louis Monteiro
> > >>>> http://twitter.com/jlouismonteiro
> > >>>> http://www.tomitribe.com
> > >>>>
> > >>>>
> > >>>> On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista 
> > >>> wrote:
> > >>>>> Hi Gurkan,
> > >>>>>
> > >>>>> I agree we have a problem with the documentation of the different
> > >>>>> properties and that we need to improve it.
> > >>>>>
> > >>>>> Doing the inventory and using the proposed syntax looks ok to me
> but
> > I
> > >>>>> also think we should go even further.
> > >>>>>
> > >>>>> How about to migrate all the properties to use microprofile-config?
> > >>>>>
> > >>>>> Cheers.
> > >>>>>
> > >>>>> Bruno Baptista
> > >>>>> https://twitter.com/brunobat_
> > >>>>>
> > >>>>>
> > >>>>> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> > >>>>>> Hello
> > >>>>>> There are lots of known and unknown system properties in the
> current
> > >>> code
> > >>>>>> base. I would like to introduce TomEESystemProperties and
> > >>>>>> OpenEJBSystemProperties classes to hold these system property
> > constants
> > >>>>> and
> > >>>>>> provide clear comment what it does. For example:
> > >>>>>>
> > >>>>>> class TomEESystemProperties{
> > >>>>>>   public static final String TOMEE_FORCE_RELOADABLE =
> > >>>>>> "tomee.force-reloadable";
> > >>>>>> 
> > >>>>>> }
> > >>>>>>
> > >>>>>> class OpenEJBSystemProperties{
> > >>>>>>  public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > >>>>>> "openejb.crosscontext";
> > >>>>>> 
> > >>>>>> }
> > >>>>>>
> > >>>>>> WDYT?
> > >>>>>> Regards.
> > >>>>>> Gurkan
> > >>>>>>
> >
> >
>

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

For me, using services-jar.xml approach is not so visible to users. All
defaults are configured in this file and packaged within JAR file. Users
are not able to read the parameter explanation from services-jar.xml files.
Also, services.-jar.xml is somebit different from using the system
properties to turn-on/off something. I am also thinking to introduce YAML
based configuration.

But first step is to centralise all of these system parameters into two
classes. Maybe, we will see that some of them are unnecessary etc.

On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista  wrote:

> Yes, there is.
>
> This is also the most basic MP spec and nothing prevents us from using
> it everywhere.
>
> There might be Jakarta EE restrictions in how to handle configurations
> that need to be assessed.
>
> Overall, I think that if we are going to mess with configs, we should
> use state of the art.
>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > I think with microprofile-config we may have a chicken and the egg
> problem,
> > isn't it?
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista 
> wrote:
> >
> >> Hi Gurkan,
> >>
> >> I agree we have a problem with the documentation of the different
> >> properties and that we need to improve it.
> >>
> >> Doing the inventory and using the proposed syntax looks ok to me but I
> >> also think we should go even further.
> >>
> >> How about to migrate all the properties to use microprofile-config?
> >>
> >> Cheers.
> >>
> >> Bruno Baptista
> >> https://twitter.com/brunobat_
> >>
> >>
> >> On 02/01/19 07:20, Gurkan Erdogdu wrote:
> >>> Hello
> >>> There are lots of known and unknown system properties in the current
> code
> >>> base. I would like to introduce TomEESystemProperties and
> >>> OpenEJBSystemProperties classes to hold these system property constants
> >> and
> >>> provide clear comment what it does. For example:
> >>>
> >>> class TomEESystemProperties{
> >>>   public static final String TOMEE_FORCE_RELOADABLE =
> >>> "tomee.force-reloadable";
> >>> 
> >>> }
> >>>
> >>> class OpenEJBSystemProperties{
> >>>  public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> >>> "openejb.crosscontext";
> >>> 
> >>> }
> >>>
> >>> WDYT?
> >>> Regards.
> >>> Gurkan
> >>>
>

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Hi Bruno, Jean-Louis

My initial attempt is to remove constant string literals from the codebase
but only in these two classes. After this removal period, we can further
update the architecture using microprofile config or any other way.

So, there will be only 2 classes to hold:

   - TomEE specific properties
   - OpenEJB specific properties

and replace all string literals with constants from these classes.

If it is ok, I will introduce two new classes and all further configuration
parameters will be defined in it.

Regards.
Gurkan

On Wed, Jan 2, 2019 at 12:34 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Hey Gurkan,
>
> I am ok to better document the system properties.
>
> Few comments though...
>
> - I probably dreamt it, but I think there is an object that tries to load
> openejb.XXX and falls back to tomee.XXX if not found. Not sure if it's
> there or not.
>
> - I think system properties have been abused over the year and that's the
> reason why we are in the current situation.
> They were meant to be used to override any configuration in the system. But
> they are now used as a default configuration system which is bad in my
> opinion. If we need configuration we should use a proper configuration
> system. tomee.xml is very extensible and you can provide defaults for a
> service using service-jar.xml
> If it would have been done this way, system properties could have been used
> to override the configuration as today, but they would have been more
> consistent in terms of names. But also, the configuration would be clearly
> documented in the services-jar.xml with proper defaults.
>
> I am not sure if that is too late to go this path and start deprecating old
> system properties.
>
> Hope it helps
> Jean-Louis
>
>
>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Jan 2, 2019 at 8:21 AM Gurkan Erdogdu  wrote:
>
> > Hello
> > There are lots of known and unknown system properties in the current code
> > base. I would like to introduce TomEESystemProperties and
> > OpenEJBSystemProperties classes to hold these system property constants
> and
> > provide clear comment what it does. For example:
> >
> > class TomEESystemProperties{
> > public static final String TOMEE_FORCE_RELOADABLE =
> > "tomee.force-reloadable";
> > 
> > }
> >
> > class OpenEJBSystemProperties{
> >public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
> > "openejb.crosscontext";
> > 
> > }
> >
> > WDYT?
> > Regards.
> > Gurkan
> >
>

[DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Hello
There are lots of known and unknown system properties in the current code
base. I would like to introduce TomEESystemProperties and
OpenEJBSystemProperties classes to hold these system property constants and
provide clear comment what it does. For example:

class TomEESystemProperties{
public static final String TOMEE_FORCE_RELOADABLE =
"tomee.force-reloadable";

}

class OpenEJBSystemProperties{
   public static final String OPENEJB_CROSSCONTEXT_PROPERTY =
"openejb.crosscontext";

}

WDYT?
Regards.
Gurkan

Re: [TOMEE-2435] New Pull Request

[Gurkan Erdogdu]

Hello Jon
I have created new pull request. Could you please check,
https://github.com/apache/tomee/pull/334

Happy New Year!

Regards.
Gurkan


On Mon, Dec 31, 2018 at 5:11 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Awesome, thanks. I'm ok with this change:
>
> -moduleLocations.removeIf(file -> !match((String) modules,
> file));
> -
> +for (final Iterator i = moduleLocations.iterator();
> i.hasNext(); ) {
> +final File file = i.next();
> +if (!match((String) modules, file)) {
> +i.remove();
> +}
> +}
>
> I don't think anyone else has expressed an opinion one way or another, so
> I'd leave your for-loop as it is.
>
> Jon
>
> On Mon, Dec 31, 2018 at 2:07 PM Gurkan Erdogdu 
> wrote:
>
> > Hi Jon
> > I will update my patch to update wildcard import, loop and diamond <>
> > operator.
> > Regards
> > Gurkan
> >
> > On Mon, Dec 31, 2018 at 2:38 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > Is there any particular reason for flipping the imports to wildcards?
> We
> > > tend to import the individual classes elsewhere in the codebase. My
> > > personal preference would be to leave those as individual imports. It
> > > doesn't make the import list that much longer, and I find its clearer
> > what
> > > is being imported and used. IDEs tend to fold those away unless you're
> > > specifically looking at them too.
> > >
> > > I think like the other changes, and do think it looks neater and easier
> > to
> > > read.
> > >
> > > I personally prefer
> > >
> > > map = new HashMap<>();
> > >
> > > over
> > >
> > > map = new HashMap();
> > >
> > > but I don't think that's a big deal.
> > >
> > > I also note this change:
> > >
> > > -moduleLocations.removeIf(file -> !match((String)
> > modules,
> > > file));
> > > -
> > > +for (final Iterator i =
> > moduleLocations.iterator();
> > > i.hasNext(); ) {
> > > +final File file = i.next();
> > > +if (!match((String) modules, file)) {
> > > +i.remove();
> > > +}
> > > +}
> > >
> > > Which is changing from a lambda to a loop. I'd probably have done it
> like
> > > this, but the effect is the same:
> > >
> > > final Iterator iterator =
> > moduleLocations.iterator();
> > > while (iterator.hasNext()) {
> > > final File file = iterator.next();
> > > if (!match((String) modules, file)) {
> > > iterator.remove();
> > > }
> > > }
> > >
> > > IntelliJ is definitely preferring the moduleLocations.removeIf, and
> will
> > > refactor both of those loops to it with one keystroke. I have the what
> is
> > > probably an unpopular opinion which is that I actually prefer the loop
> > over
> > > the lambda. The reasons are:
> > >
> > > 1. Backporting changes is much harder when you have to work around
> > language
> > > changes like this
> > > 2. I personally find lots of things crammed into one line harder to
> read,
> > > and in this particular case, there's a cast and a negation (so a double
> > > negative) in the removeIf.
> > >
> > > Jon
> > >
> > > On Mon, Dec 31, 2018 at 10:21 AM Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > Yep, I'll take a look. Thanks for the PR.
> > > >
> > > > Jon
> > > >
> > > > On Mon, Dec 31, 2018 at 9:10 AM Gurkan Erdogdu 
> > > > wrote:
> > > >
> > > >> Hi
> > > >> I have created a PR (https://github.com/apache/tomee/pull/332) for
> > > >> (TOMEE-2435)
> > > >> Simplify the Code in org.apache.openejb.OpenEjbContainer$Provider
> > > >> <https://issues.apache.org/jira/browse/TOMEE-2435>
> > > >>
> > > >> If anybody can check and merge, it is appreciated :)
> > > >> Regards.
> > > >> Gurkan
> > > >>
> > > >
> > >
> >
>

Re: [TOMEE-2435] New Pull Request

[Gurkan Erdogdu]

Hi Jon
I will update my patch to update wildcard import, loop and diamond <>
operator.
Regards
Gurkan

On Mon, Dec 31, 2018 at 2:38 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Is there any particular reason for flipping the imports to wildcards? We
> tend to import the individual classes elsewhere in the codebase. My
> personal preference would be to leave those as individual imports. It
> doesn't make the import list that much longer, and I find its clearer what
> is being imported and used. IDEs tend to fold those away unless you're
> specifically looking at them too.
>
> I think like the other changes, and do think it looks neater and easier to
> read.
>
> I personally prefer
>
> map = new HashMap<>();
>
> over
>
> map = new HashMap();
>
> but I don't think that's a big deal.
>
> I also note this change:
>
> -moduleLocations.removeIf(file -> !match((String) modules,
> file));
> -
> +for (final Iterator i = moduleLocations.iterator();
> i.hasNext(); ) {
> +final File file = i.next();
> +if (!match((String) modules, file)) {
> +i.remove();
> +}
> +}
>
> Which is changing from a lambda to a loop. I'd probably have done it like
> this, but the effect is the same:
>
> final Iterator iterator = moduleLocations.iterator();
> while (iterator.hasNext()) {
> final File file = iterator.next();
> if (!match((String) modules, file)) {
> iterator.remove();
> }
> }
>
> IntelliJ is definitely preferring the moduleLocations.removeIf, and will
> refactor both of those loops to it with one keystroke. I have the what is
> probably an unpopular opinion which is that I actually prefer the loop over
> the lambda. The reasons are:
>
> 1. Backporting changes is much harder when you have to work around language
> changes like this
> 2. I personally find lots of things crammed into one line harder to read,
> and in this particular case, there's a cast and a negation (so a double
> negative) in the removeIf.
>
> Jon
>
> On Mon, Dec 31, 2018 at 10:21 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Yep, I'll take a look. Thanks for the PR.
> >
> > Jon
> >
> > On Mon, Dec 31, 2018 at 9:10 AM Gurkan Erdogdu 
> > wrote:
> >
> >> Hi
> >> I have created a PR (https://github.com/apache/tomee/pull/332) for
> >> (TOMEE-2435)
> >> Simplify the Code in org.apache.openejb.OpenEjbContainer$Provider
> >> <https://issues.apache.org/jira/browse/TOMEE-2435>
> >>
> >> If anybody can check and merge, it is appreciated :)
> >> Regards.
> >> Gurkan
> >>
> >
>

[TOMEE-2435] New Pull Request

[Gurkan Erdogdu]

Hi
I have created a PR (https://github.com/apache/tomee/pull/332) for (TOMEE-2435)
Simplify the Code in org.apache.openejb.OpenEjbContainer$Provider


If anybody can check and merge, it is appreciated :)
Regards.
Gurkan

Re: How Can I Help?

[Gurkan Erdogdu]

Hi Jeff
Import TomEE source code into IntelliJ. Run TomEE with jpda enabled. Here
are the steps:

   - Add breakpoint in source code (TomEE is launched via
   *org.apache.tomee.catalina.ServerListener* in tomee-catalina, put a
   breakpoint at* lifecycleEvent(final LifecycleEvent event)*)
   - export *JPDA_SUSPEND=y* or *set JPDA_SUSPEND=y* (Linux and Windows)
   - Go to *TomEE/bin* folder
   - *./catalina.sh jpda run*
   - IntelliJ click *Run/Attach to Local Process*... and select the
   suspended TomEE port. (In default, it will suspend in port 8000. Attach to
   8000 in Intellij)

Hope it help
Happy hacking!
Gurkan

On Sat, Dec 29, 2018 at 6:45 PM Jeff Mitchell 
wrote:

> Thank you, Gurkan!
>
> I’ve forked the repo, cloned to my local machine, and built the server.
> I’m using IntelliJ and would like to start the server and start stepping
> through the code. Are there any instructions for how to do this?
>
> Thanks,
> Jeff
>
> > On Dec 29, 2018, at 2:13 AM, Gurkan Erdogdu  wrote:
> >
> > Hi Jeff
> > Welcome! You can start to look at
> > http://tomee.apache.org/community/index.html
> > To familiar with the TomEE source code, I think your first step is to get
> > the source code and try to produce your own release. Check
> > http://tomee.apache.org/community/sources.html
> > Regards.
> > Gurkan
> >
> > On Sat, Dec 29, 2018 at 4:42 AM Jeff Mitchell 
> > wrote:
> >
> >> Hi folks,
> >>
> >> My name is Jeff Mitchell and I’ve worked as a Java developer for a good
> >> part of my career. I’m currently working on a Java EE 7 project and I
> love
> >> the technology. I’d REALLY like to get better at what I do and to learn
> >> from people who are smarter and more experienced than me so I've come to
> >> you guys. The Tomitribe blog posts encouraged me to get involved.
> >>
> >> So… what can I do to help the project?
> >>
> >> Thanks,
> >> Jeff
>
>

Re: How Can I Help?

[Gurkan Erdogdu]

Hi Jeff
Welcome! You can start to look at
http://tomee.apache.org/community/index.html
To familiar with the TomEE source code, I think your first step is to get
the source code and try to produce your own release. Check
http://tomee.apache.org/community/sources.html
Regards.
Gurkan

On Sat, Dec 29, 2018 at 4:42 AM Jeff Mitchell 
wrote:

> Hi folks,
>
> My name is Jeff Mitchell and I’ve worked as a Java developer for a good
> part of my career. I’m currently working on a Java EE 7 project and I love
> the technology. I’d REALLY like to get better at what I do and to learn
> from people who are smarter and more experienced than me so I've come to
> you guys. The Tomitribe blog posts encouraged me to get involved.
>
> So… what can I do to help the project?
>
> Thanks,
> Jeff

Re: ORB Dependencies and Java 11

[Gurkan Erdogdu]

Hi David
I have created JIRA issue to track this :
https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
Could you please check?
Regards.
Gurkan

On Thu, Dec 6, 2018 at 1:38 AM David Blevins 
wrote:

> Gurkan, you have any references on the imports?  Could be a good place for
> contribution.
>
> I know we don't support Corba itself, so we'd probably have to figure out
> how we're tied to those classes and what to do about it.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: CMP/JPA mapping not accounting for in persistence.xml

[Gurkan Erdogdu]

For the ORB case, there are places where ORB class is imported
(openejb-core and openejb-client). For java 11, this will probably not
compile and needs to have some 3th party Jar. For CMP case, as you have
already experienced, the codebase is very complicated and it is really old
technology and has not been updated since years. Therefore, it is a good
idea to declare it  as --deprecated-- and remove it from the future 8.1.x
or 9.0.x versions.
Regards.
Gurkan


On Wed, Dec 5, 2018 at 8:33 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Thanks for the background David, that's much appreciated.
>
> I agree about the webapp. Our last CVE was due to an XSS issue in that
> webapp - I'd be inclined to remove it as well. Our Arquillian test suite
> tests all the distros *and* has a couple of phases doing an install with
> the webapp, so losing the webapp could shorten the build a bit too.
>
> Back on the CMP changes, my Arquillian test is now working, and I'm quite
> happy with the change itself. If there's no objections, I'll merge this in
> tomorrow. I'll do some documentation and check some more stuff out with
> this functionality after that merge.
>
> Thanks
>
> Jon
>
> On Wed, Dec 5, 2018 at 1:09 AM David Blevins 
> wrote:
>
> > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> > >
> > > I don't know that we have stuff that is deprecated pending removal at
> the
> > > moment. In terms of removing the CMP/BMP stuff... well, people are
> using
> > > it, which is why I'm working on it :-). I would be ok with marking it
> as
> > > deprecated, as long as we print out an explicit warning if your
> > application
> > > is using it, so you know to migrate. In terms of the gain... I don't
> > know.
> > > There'd be less code, but I suspect still the same dependencies, so
> we'd
> > be
> > > removing a small part of openejb-core effectively. I think its a good
> > > discussion, but I'd prefer to see graceful deprecation with clear
> > warnings
> > > before removal.
> >
> > Contextual information on the CMP implementation.  We actually had a
> > separate CMP implementation in OpenEJB 2.0 that was working and passed
> the
> > TCK and used to certify Geronimo for J2EE 1.5.
> >
> > When JPA was added in EJB 3.0 / Java EE 5, we made a deliberate decision
> > to throw out all of that code and write a new CMP implementation in
> OpenEJB
> > 3.0 on top of JPA to protect ourselves in the future from the inevitable
> > cost of CMP legacy.  What we have is actually a very thin layer on top of
> > JPA, which I think provides people more value than cost.
> >
> > If someone is still stuck on CMP, our implementation is the best in the
> > industry in terms of helping you migrate to JPA, because it *is* JPA and
> > you can freely mix the two and even have them backed by the same
> > persistence unit.
> >
> > There is no code in TomEE/OpenEJB that implements Corba or JAX-RPC. All
> > the Corba and ORB related code stayed in Geronimo as we didn't want it
> > OpenEJB 3.0 because even for 2006 it would have been instant legacy.
> Same
> > with JAX-RPC which would have brought in at least 10BM in dependencies.
> >
> > If we hadn't completely rewritten OpenEJB between 2 and 3 I suspect we
> > would have good candidates for the chopping block.
> >
> > One thing I think is a great candidate for the chopping block is the
> > "tomee-webapp" used to bootstrap our Tomcat integration for people who do
> > not have the ability to just use an already built TomEE dis.  I don't
> think
> > it ever took off.  I'm not aware of anyone using it.  Removing it would
> > allow us to drop binaries from our release process.  We could optimize
> our
> > Tomcat integration because there are quirky things we do only for the
> > benefit of that unused webapp.
> >
> > Rather than use that quirky webapp, we could simply build our TomEE
> > distros using the TomEE Maven Plugin.  It's there to help others build
> > their own TomEE distros, but we don't use it only because of the
> > tomee-webapp legacy.  We chose to use the tomee-webapp to "eat our own
> > dogfood", but we should probably switch the dog food to the TomEE Maven
> > Plugin.
> >
> >
> > -David
> >
> >
> >
>

Re: CMP/JPA mapping not accounting for in persistence.xml

[Gurkan Erdogdu]

Great job John. In the mean time,
What do you think to trim  old parts of TomEE which includes

   - Removing ORB support
   - Removing CMP/BMP support
   - Some other non-common or deprecated parts?

If we want to have a maintainable TomEE codebase, instead of adding more
features, we need to have more reliable/readable/lightweight code base. I
will start to add comments/explanations to the methods, remove duplicated
parts etc.

Also, is it possible to return back to commit and then review policy? We
can have some strict rules to correlate the commit with the JIRA issue. If
the commit will have a big impact in the current codebase, before working
on the feature, we can discuss it first and starts to work if the community
all agree. Otherwise, it includes lots of commits within one shot that hard
to understand the content.  I think that  community consensus is necessary
before adding big changes/updates to the current codebase.

WDYT? Comments/advises are so welcome!

Regards.
Gurkan


On Tue, Dec 4, 2018 at 8:46 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> My issue seems more basic than CMP actually - a straight session bean with
> a business method that does a no-op is also failing using a Local and
> LocalHome interface throws this exception. I stripped the test right down
> to the basics, and also tried it in a sample. Not sure what I'm not seeing
> at this point. I'll keep you posted if I find anything.
>
> Jon
>
> On Tue, Dec 4, 2018 at 4:41 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > I'm kinda enjoying the challenge. And yes, I'll definitely be kicking out
> > some docs and better examples for this. :)
> >
> > Jon
> >
> > On Tue, Dec 4, 2018 at 4:38 PM David Blevins 
> > wrote:
> >
> >> In the bike shed vs nuclear reactor analogy of open source, you're
> >> working on a nuclear reactor and therefore not getting much
> participation.
> >> This particular code is super hard and the guy who wrote it was Dain
> >> Sundstrom, who went on to create Presto a 300 pedabyte data warehouse
> >> Facebook runs on.  This is also the only CMP implementation that runs on
> >> JPA.
> >>
> >> Thank you for working on it.
> >>
> >> We should document it incredibly, because it *is* a "nuclear reactor"
> and
> >> few people can work on it. I'm aware of the high level design, but this
> one
> >> should point at actual code and say "look here and here for the critical
> >> things.  If you have issues, do this and do that."
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >> > On Dec 4, 2018, at 3:48 AM, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >> >
> >> > I hacked together a little JVMTI agent to help debug this, and I
> think I
> >> > have tracked down where the NPE is - looks to be field is null in the
> >> > metadata that is handed over to OpenJPA. Looks like I now have enough
> of
> >> > stacktrace to debug it. When I track down my mistake, I'll let you
> know
> >> > (and no doubt kick myself as well :-) )
> >> >
> >> > Jon
> >> >
> >> > On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
> >> > jonathan.gallim...@gmail.com> wrote:
> >> >
> >> >> I have pushed some further work on this, but I'm now stuck. I have
> >> tried
> >> >> to ensure that this is working ok with CMP beans with a 1-m
> >> relationship,
> >> >> but I am getting a very weird NPE from here:
> >> >>
> >>
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
> >> >>
> >> >> Weirdly, the business method on MovieBusinessBean works ok:
> >> >>
> >>
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56
> >> .
> >> >> All I can see in terms of the stack trace is an NPE thrown inside the
> >> >> proxy, called from line 58 of MoviesServlet. Only started happening
> >> when I
> >> >> added the addActor method.
> >> >>
> >> >> I'll kick hacking away on it, but any review of the code, any samples
> >> of
> >> >> CMP code with relationships working, or general debugging tips are
> much
> >> >> appreciated.
> >> >>
> >> >> Jon
> >> >>
> >> >> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
> >> >> jonathan.gallim...@gmail.com> wrote:
> >> >>
> >> >>> This is my work in progress so far:
> >> >>> https://github.com/apache/tomee/pull/222.
> >> >>>
> >> >>> I'd like to incorporate some Arquillian tests today, and ensure that
> >> this
> >> >>> works with things like relationships between entities.
> >> >>>
> >> >>> The change here is fairly straightforward though; we pick up a
> >> >>> persistence unit called "cmp", if one has been defined, and read all
> >> the
> >> >>> elements on it. If an entity has been defined in one of those
> mappings
> >> >>> files, we add the entity class to a set, and the CMP/JPA processing
> >> will
> >> >>> simply ignore it. The persistence provider sh

Re: New Java EE Schemas for Java EE Deployment Descriptors

[Gurkan Erdogdu]

Hi David
First of all, thank you for your clear and well written response (as
always).
I have been working (nearly 20 hours) to convert all openejb-jee and
openejb-jee-sxc to formal standard  EE 8 descriptors but it is a painful
process for me. The generated schemas are not fit in to our current
implementation and the current code base needs to be updated heavily. There
are two options here:

   - Stay with the current descriptor logic but it must be updated manually
   for every new/updated EE descriptors. Also, we need to validate descriptors
   which are written according to  EE 8 descriptors with new namespaces.
   - Remove the old implementation and use the newly generated schemas
   (Lots of work, I really mean it)
   - Keep the old implementation, update each main class such as
   FacesConfig, EjbJar, Application etc. to use newly written delegate classes
   which delegate each method call to new classes. But, some codes are
   directly accessing the public fields of the old descriptors so it may not
   be fit.

>From my perspective, now Jakarata EE allows us to use Jakarata EE TCK
freely, so we may stick to EE descriptors and rethink to certify TomEE
against these TCKs.
Regards.
Gurkan

On Mon, Dec 3, 2018 at 2:33 AM David Blevins 
wrote:

> > On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu  wrote:
> >
> > Hi folks,
> > I am working on the Java EE schema update to support Java EE 7 and Java
> EE8
> > schemas which are specified in
> >
> https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html
> >
> > Seems that two modules openejb-jee and openejb-jee-accessor modules are
> > mostly updated by manually after generated by xjc compiler. Moreover, I
> did
> > not able to find the any XJB binding file.
> >
> > In pom.xml, there is a plugin (jaxb2-maven-plugin) but seems that it is
> not
> > working correctly.
> > Do you have any comment on these modules? We need to generate codes
> > automatically without updating any manual intervention.
> >
> > Currently we only support Java EE 6 schemas and using the trick (updating
> > newer namespaces to Java EE 6 old namespace) and do not support Java EE7
> > and 8 deployment descriptors.
> >
> > Here is the JIRA Issue:
> > https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2306
>
> Hi Gurkan,
>
> I've added David Jencks to the thread in case he's around and wants to
> give some of his historical perspective.  He is retired and enjoying life,
> so I suspect he won't, but it never hurts.
>
> There's long pro-customization and anti-customization history on this
> topic between OpenEJB/Geronimo.  We've done it both ways in both projects,
> this is a rough timeline -- years are approximate:
>
>  - OpenEJB & Geronimo anti-customization: 2003 - 2006
>  - OpenEJB pro-customization, Geronimo anti-customization 2006-2009
>  - OpenEJB & Geronimo pro-customization: 2009 onward
>
> There really is no easy answers without pain points.  Both project started
> as you say, generating automatically without any customizations, and
> committers on both projects eventually shifted away from it.  There's a
> trade-off and it comes down to where you want the benefits and where you're
> willing to live with the cost.  This is a high-level perspective of what we
> all noticed.
>
>  - Read-only generated tree:
> - pro: easy when schemas change once every 2-3 years
> - con: inability to customize pushes complexity into consuming code
> year-round
>
>  - Generated then customized tree:
> - pro: increasingly easier to to consume year-round
> - con: hard when schemas change once every 2-3 years
>
> The con of "Generated then customized tree" really only applies to
> existing schemas that change.  New schemas introduced can easily be
> generated.
>
> The story arch of this goes basically both OpenEJB and Geronimo used
> generated trees that were not checked into the source.  The pain points
> associated with that resulted in OpenEJB trying it differently when OpenEJB
> 3 was launched in 2006.  Geronimo kept with generated trees believing
> manually changing them was a mistake. After a few years on both projects
> and everyone having the experience with both approaches, Geronimo
> eventually removed it's generated tree and switched the whole server over
> to using the optimized OpenEJB JAXB tree.
>
> This topic comes up every few years when it is time to update the
> descriptors, which is completely natural.
>
> The topic of customized or not is particularly challenging when you don't
> control the schema.  There are a few terrible aspects of the Java EE
> schemas that make it really hard to work with &q

New Java EE Schemas for Java EE Deployment Descriptors

[Gurkan Erdogdu]

Hi folks,
I am working on the Java EE schema update to support Java EE 7 and Java EE8
schemas which are specified in
https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

Seems that two modules openejb-jee and openejb-jee-accessor modules are
mostly updated by manually after generated by xjc compiler. Moreover, I did
not able to find the any XJB binding file.

In pom.xml, there is a plugin (jaxb2-maven-plugin) but seems that it is not
working correctly.
Do you have any comment on these modules? We need to generate codes
automatically without updating any manual intervention.

Currently we only support Java EE 6 schemas and using the trick (updating
newer namespaces to Java EE 6 old namespace) and do not support Java EE7
and 8 deployment descriptors.

Here is the JIRA Issue:
https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2306

Happy coding!
Gurkan

Re: [VOTE] Release Apache TomEE 7.1.0

[Gurkan Erdogdu]

+1

Gurkan


On Thu, Aug 30, 2018 at 6:24 AM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Hi Everyone,
>
> Here is the first roll of TomEE 7.1.0. Please can you take a look and
> vote? Everyone,
> committer or not, is encouraged to test and vote.
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1119
>
> Source zip:
>
> https://repository.apache.org/content/repositories/orgapachetomee-1119/org/apache/tomee/tomee-project/7.1.0/tomee-project-7.1.0-source-release.zip
>
> Dist area:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1119/
>
> Legal:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1119/legal.zip
>
> Keys:
> https://dist.apache.org/repos/dist/release/tomee/KEYS
>
> Please vote:
>  +1: Release
>  -1 Do not release because ...
>
> The vote will be open for 3 days or the consensus is binding (At least 3
> binding votes).
>
> Many thanks
>
> Jon
>

Re: [VOTE] Allow an MicroProfile-focused TomEE 7.1 release

[Gurkan Erdogdu]

>
> we can focus entirely in TomEE 8.

+1
Gurkan

On Fri, Aug 24, 2018 at 1:43 PM Roberto Cortez 
wrote:

> I think the idea was to release something quick with MP work on a stable
> version. The earliest conversations about this are from March / April and
> TomEE 8 was not ready back then.
>
> Right now, we have TomEE 8 with full MP 1.3 support and TomEE 7.1 with
> partial MP 1.2 support. I think there is not much we can do moving forward
> in 7.1, since implementations require CDI 2.0 and we can focus entirely in
> TomEE 8.
>
> Cheers,
> Roberto
>
> > On 24 Aug 2018, at 18:26, Mark Struberg 
> wrote:
> >
> > +0.5
> >
> >
> > If there are people willing to work on 7.1, then go on!
> > I'll personally focus my bit of spare time to work on TomEE8.
> > Happy if people pick this up and backport to 7.1 though.
> >
> > LieGrue,
> > strub
> >
> >
> >> Am 09.08.2018 um 15:57 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >>
> >> That's good feedback, and much appreciated. I have a couple of things to
> >> clear "right now", but then I should be back onto working on Java 11
> >> support. Its likely that I'll work on that as opposed to TomEE 8 / MP,
> and
> >> time permitting, I'd like to work on MP / Jakarta EE items after the J11
> >> support.
> >>
> >> Long story short though, I believe there are people to work on the
> various
> >> items, and I'm sure those things can happen in parallel.
> >>
> >> Specifically, there is a concern that if lots of people work on TomEE
> >> 7.1.x, progress is slowed on TomEE 8, and if I'm reading the feedback
> >> correctly, some folks would prefer to drop TomEE 7.1.x altogether.
> >>
> >> Personally, I think those working on MP / Jakarta EE items should be
> free
> >> to do so, with the guidance of "please commit to master first".
> Importantly
> >> though, if they wish to backport to another branch, they should not be
> >> prevented from doing so.
> >>
> >> Similarly, I want to work on Java 11 support. I too will commit that to
> >> master, but I'd certainly want to backport that support as far back as
> >> 1.7.x if it is possible, and I feel I shouldn't be prevented from doing
> so.
> >>
> >> Hopefully that provides some re-assurance about commitment to Java 11,
> and
> >> some clarification around the VOTE.
> >>
> >> Jon
> >>
> >> On Thu, Aug 9, 2018 at 12:39 PM, Alex The Rocker 
> >> wrote:
> >>
> >>> Non-binding:
> >>>
> >>> -1 : if there's a lack of resource i'd prefer to see first TomEE
> >>> compatibility with Java 11 LTS addressed as soon as possible (hoping a
> >>> fix for at least https://issues.apache.org/jira/browse/TOMEE-2200...).
> >>>
> >>> Indeed, Java 11 LTS is supposed to be soon available (25/09 according
> >>> to http://openjdk.java.net/projects/jdk/11/) and most major projects
> >>> (Hadoop, etc.) are waiting for this LTS (Long Term Support) version to
> >>> move beyond Java 8.
> >>>
> >>> I have the felling that any major release from TomEE arriving
> >>> somewhere in November should be as ready as possible to live with this
> >>> "new Java for the couple of upcoming years..."
> >>>
> >>> Thanks,
> >>> Alexandre
> >>> Le jeu. 9 août 2018 à 08:09, David Blevins  a
> >>> écrit :
> 
>  For a few months we've discussed doing and not doing a TomEE 7
> flavored
> >>> release of MicroProfile 1.x for Java EE 7 users on Java 8, tentatively
> >>> versioned TomEE 7.1.
> 
>  Earliest email with TomEE 7.1 in the subject is around April, though I
> >>> vaguely recall it mentioned before.  I recall seeing a request from
> Mark to
> >>> wait on it till after 7.0.5 was released.  That's now out and a TomEE
> 7.1.x
> >>> branch has been created and being actively worked on.
> 
>  There seem to be concerns that this will draw attention away from
> TomEE
> >>> 8, which is understandable, and some sentiment that this work should
> stop
> >>> and everyone focus on TomEE 8.  I haven't seen anyone suggest not
> working
> >>> on TomEE 8, so I'll assume that as a constant that doesn't need to be
> voted
> >>> on.
> 
>  As the concern is largely resources, I propose the following
> compromise:
> 
>  - MicroProfile related PRs that can possibly apply to TomEE 8 must be
> >>> merged to master *before* the equivalent can be merged to TomEE 7.1.x.
> In
> >>> short, everyone must work on TomEE 8.
> 
>  - Those who wish to focus time only on TomEE 8 may do so, someone else
> >>> can merge the PR to 7.1.x if they have the energy.  In short, only the
> >>> willing need work on TomEE 7.1.x
> 
>  With this in mind, the vote:
> 
>  +1 Allow work on TomEE 7.1 to proceed with the above two conditions
>  +-O Abstain or don't feel strongly
>  -1 I have a better idea
> 
> 
> 
>  -David
> 
> >>>
> >
>
>

Re: [DISCUSS] Goal - release this week and very frequently thereafter

[Gurkan Erdogdu]

Thanks for your input David.
What about release new TomEE version at every first week of each month?
Also, this action must not  be specific to MP features but also covers
overall TomEE features (bug, security vulnerabilities, component and
dependency update etc.). In the mean time, (IMO) in our release process, we
need to separate MP included TomEE versus core TomEE? I think we need to
update pom.xml release process for this.
Best.
Gurkan


On Tue, Aug 14, 2018 at 2:24 AM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> I like it and yes I'd like to help.
>
> Jon
>
> On Mon, 13 Aug 2018, 21:31 David Blevins,  wrote:
>
> > Our status is every time we discuss a release, we never agree and then
> one
> > never happens.  We could have a trail of releases behind us by now.
> >
> > MicroProfile work is ongoing in both TomEE 8 and TomEE 7.1.  It's not
> > feature complete, but there are complete features and it is usable now.
> > The fear is we'll get stuck an a "milestone or final" discussion for the
> > next 3 weeks and in that time we could have had a few releases up.  Add
> to
> > this that we always throw away our first few release attempts and
> > repeatedly re-roll.
> >
> > I'd like to propose this compromise to getting us unstuck.  For the next
> > two months week do four releases, spaced evenly apart starting this week:
> >
> >  - Fri Aug 17th TomEE 8 and TomEE 7.1 milestone
> >  - Fri Aug 31th TomEE 8 and TomEE 7.1 milestone or final
> >  - Fri Sep 14th TomEE 8 and TomEE 7.1 milestone or final
> >  - Fri Sep 28th TomEE 8 and TomEE 7.1 final
> >
> > We call the first one a milestone and if it is not perfect, release it
> > anyway.  When we notice we aren't messing them up we aim for the final of
> > both.  That could happen the release after or at any point in the middle.
> >
> > What I think this gains us:
> >
> >  - Takes pressure of the "final" discussion and release process
> >  - Allows those of us not yet comfortable with final to get comfortable
> >  - Very likely speeds up our chances of getting a releasable final sooner
> >  - Ability to get some public momentum and anticipation
> >  - Releasing is increasingly easier the more you do
> >  - Provides opportunities to train more people in the release process
> >
> > It feels like an everyone wins compromise.
> >
> > What do you think about this approach to getting "unstuck" and would you
> > like to help cut releases?
> >
> > Absolutely there's a high chance we don't pull it off as perfectly as
> > imagined, but it feels like we'll do more harm to ourselves by not
> trying.
> > First MP feature was February, we're now August.  We're definitely
> missing
> > out on opportunities to get our stuff out there.
> >
> > With this plan we'll either be 8.0 and 7.1 or even as far as 8.0.2 and
> > 7.1.2 by end of September.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
> >
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

Hi Roberto
Great work! and thank you for the update.
Best.

On Mon, Aug 13, 2018 at 7:19 PM, Roberto Cortez  wrote:

> An update status:
>
> TomEE 7.1:
> - MicroProfile 1.2.
> - Support for Config, JWT, Fault Tolerance and Health added.
> - Metrics seems to require CDI 2.0 that is not available on TomEE 7, so it
> is out for now.
> - Health has an issue with the JSON response because of JSONB annotation.
> May need the JSONB Provider as well.
> - PR’s: TOMEE-2209 - TomEE 7.1 Added MP Specs: Fault Tolerance and Health.
> <https://github.com/apache/tomee/pull/145>
>
> TomEE 8:
> - MicroProfile 1.2 and 1.3
> - Support for Config, JWT, Fault Tolerance, Health, Metrics, Rest Client
> and OpenAPI.
> - Still working on the Open Tracing support.
> - Requires the JSONB Provider.
> - PR’s: TOMEE-2209 - TomEE 8 Microprofile 1.2 Support <
> https://github.com/apache/tomee/pull/141>, TOMEE-2210 - TomEE 8
> Microprofile 1.3 Support <https://github.com/apache/tomee/pull/146>,
> TOMEE-2221 - Added Johnzon Jsonb Provider. <https://github.com/apache/
> tomee/pull/142>
>
> Main JIRAS:
> TOMEE-2209 <https://issues.apache.org/jira/browse/TOMEE-2209>
> TOMEE-2210 <https://issues.apache.org/jira/browse/TOMEE-2210>
> TOMEE-2221 <https://issues.apache.org/jira/browse/TOMEE-2221>
>
> Hope it helps!
>
> Cheers,
> Roberto
>
> > On 9 Aug 2018, at 21:33, Gurkan Erdogdu  wrote:
> >
> >>
> >> Sure. Here it is:
> >> https://issues.apache.org/jira/browse/TOMEE-2209 <
> >> https://issues.apache.org/jira/browse/TOMEE-2209>
> >
> > Thank you.
> >
> > On Thu, Aug 9, 2018 at 7:41 PM, Roberto Cortez
> 
> > wrote:
> >
> >> Would a main JIRA Issue “MicroProfile Support” and sub-tasks with
> >> everything related under the parent task work?
> >>
> >>> On 9 Aug 2018, at 17:36, David Blevins 
> wrote:
> >>>
> >>>> On Aug 9, 2018, at 4:28 AM, Gurkan Erdogdu 
> wrote:
> >>>>
> >>>> Can you also please open JIRA issue (main issue and we
> >>>> can create sub-tasks under it) to track MP related work?
> >>>
> >>> Agreed.  And for those reading, our release notes are generated from
> >> JIRA (or at least they used to be).  So we should file JIRAs with the
> >> subject written from the perspective of someone reading the release
> notes.
> >> That's clean and simple subjects.
> >>>
> >>> It would be very common for me to file a handful of JIRAs even though
> >> one would do it from a tracking perspective.  It was also common for me
> to
> >> go back through commits at release time and spend 2 days filing them
> >> because the release notes were too thin.
> >>>
> >>> Here's the template:
> >>>
> >>> - https://svn.apache.org/repos/asf/tomee/sandbox/release-
> >> tools/src/main/resources/release-notes.vm
> >>>
> >>> As far as JIRAs, I'd probably aim for release notes looking like this:
> >>>
> >>>
> >>>   Upgrades:
> >>>
> >>>- ...
> >>>
> >>>   New Features:
> >>>
> >>>- MicroProfile 1.3 Support
> >>>- MicroProfile JWT 1.0
> >>>- MicroProfile FaultTolerance 1.0
> >>>[list them all cleanly]
> >>>
> >>> That'd mean you'd have to file a JIRA of type "New Feature" with the
> >> clean subject "MicroProfile JWT 1.0."  If you used talkative text like,
> >> "Adding some MP-JWT Stuff", you'll get strange looking release notes.
> >>>
> >>>
> >>>   Upgrades:
> >>>
> >>>- ...
> >>>
> >>>   New Features:
> >>>
> >>>- Implement MP in TomEE
> >>>[list them all cleanly]
> >>>
> >>>   Tasks & Subtasks:
> >>>
> >>>- Update the pom.xml with MP-JWT
> >>>- Fix integration issue with JWT Filter
> >>>[list them all cleanly]
> >>>
> >>> This doesn't clearly communicate our status to the world and just puts
> >> more work on the release manager who would have to ensure the release
> notes
> >> make sense, so it's to not just file JIRAs, but think of the future
> release
> >> note readers when we file them.
> >>>
> >>>
> >>> -David
> >>>
> >>>
> >>
> >>
>
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

>
> Sure. Here it is:
> https://issues.apache.org/jira/browse/TOMEE-2209 <
> https://issues.apache.org/jira/browse/TOMEE-2209>

Thank you.

On Thu, Aug 9, 2018 at 7:41 PM, Roberto Cortez 
wrote:

> Would a main JIRA Issue “MicroProfile Support” and sub-tasks with
> everything related under the parent task work?
>
> > On 9 Aug 2018, at 17:36, David Blevins  wrote:
> >
> >> On Aug 9, 2018, at 4:28 AM, Gurkan Erdogdu  wrote:
> >>
> >> Can you also please open JIRA issue (main issue and we
> >> can create sub-tasks under it) to track MP related work?
> >
> > Agreed.  And for those reading, our release notes are generated from
> JIRA (or at least they used to be).  So we should file JIRAs with the
> subject written from the perspective of someone reading the release notes.
> That's clean and simple subjects.
> >
> > It would be very common for me to file a handful of JIRAs even though
> one would do it from a tracking perspective.  It was also common for me to
> go back through commits at release time and spend 2 days filing them
> because the release notes were too thin.
> >
> > Here's the template:
> >
> > - https://svn.apache.org/repos/asf/tomee/sandbox/release-
> tools/src/main/resources/release-notes.vm
> >
> > As far as JIRAs, I'd probably aim for release notes looking like this:
> >
> >
> >Upgrades:
> >
> > - ...
> >
> >New Features:
> >
> > - MicroProfile 1.3 Support
> > - MicroProfile JWT 1.0
> > - MicroProfile FaultTolerance 1.0
> > [list them all cleanly]
> >
> > That'd mean you'd have to file a JIRA of type "New Feature" with the
> clean subject "MicroProfile JWT 1.0."  If you used talkative text like,
> "Adding some MP-JWT Stuff", you'll get strange looking release notes.
> >
> >
> >Upgrades:
> >
> > - ...
> >
> >New Features:
> >
> > - Implement MP in TomEE
> > [list them all cleanly]
> >
> >Tasks & Subtasks:
> >
> > - Update the pom.xml with MP-JWT
> > - Fix integration issue with JWT Filter
> > [list them all cleanly]
> >
> > This doesn't clearly communicate our status to the world and just puts
> more work on the release manager who would have to ensure the release notes
> make sense, so it's to not just file JIRAs, but think of the future release
> note readers when we file them.
> >
> >
> > -David
> >
> >
>
>

Re: [VOTE] Allow an MicroProfile-focused TomEE 7.1 release

[Gurkan Erdogdu]

>
> Sorry I do not understand you point: I replied to the list (using
> dev@tomee.apache.org) and not just to you.
> What is your point?
>
I see but this is a VOTE thread regarding MP in TomEE. Please send a new
email to dev@ list for Java 11 LTS support  issue
Regards.
Gurkan

On Thu, Aug 9, 2018 at 3:04 PM, Alex The Rocker 
wrote:

> Hello Gurkan,
>
> Sorry I do not understand you point: I replied to the list (using
> dev@tomee.apache.org) and not just to you.
> What is your point?
>
> Kind regards,
> Alexandre
> Le jeu. 9 août 2018 à 13:56, Gurkan Erdogdu  a écrit
> :
> >
> > >
> > > Non-binding:
> > >
> > > -1 : if there's a lack of resource i'd prefer to see first TomEE
> > > compatibility with Java 11 LTS addressed as soon as possible (hoping a
> > > fix for at least https://issues.apache.org/jira/browse/TOMEE-2200...).
> > >
> > > Indeed, Java 11 LTS is supposed to be soon available (25/09 according
> > > to http://openjdk.java.net/projects/jdk/11/) and most major projects
> > > (Hadoop, etc.) are waiting for this LTS (Long Term Support) version to
> > > move beyond Java 8.
> > >
> > > I have the felling that any major release from TomEE arriving
> > > somewhere in November should be as ready as possible to live with this
> > > "new Java for the couple of upcoming years..."
> > >
> > > Thanks,
> > > Alexandre
> > >
> > > Thanks for your input but this VOTE  email is not related with your
> input.
> > Can you please send a new email with this? (Please don't reply to my
> email
> > in this thread :=) Thanks.
> > Gurkan
> >
> >
> >
> > On Thu, Aug 9, 2018 at 2:39 PM, Alex The Rocker 
> > wrote:
> >
> > > Non-binding:
> > >
> > > -1 : if there's a lack of resource i'd prefer to see first TomEE
> > > compatibility with Java 11 LTS addressed as soon as possible (hoping a
> > > fix for at least https://issues.apache.org/jira/browse/TOMEE-2200...).
> > >
> > > Indeed, Java 11 LTS is supposed to be soon available (25/09 according
> > > to http://openjdk.java.net/projects/jdk/11/) and most major projects
> > > (Hadoop, etc.) are waiting for this LTS (Long Term Support) version to
> > > move beyond Java 8.
> > >
> > > I have the felling that any major release from TomEE arriving
> > > somewhere in November should be as ready as possible to live with this
> > > "new Java for the couple of upcoming years..."
> > >
> > > Thanks,
> > > Alexandre
> > > Le jeu. 9 août 2018 à 08:09, David Blevins  a
> > > écrit :
> > > >
> > > > For a few months we've discussed doing and not doing a TomEE 7
> flavored
> > > release of MicroProfile 1.x for Java EE 7 users on Java 8, tentatively
> > > versioned TomEE 7.1.
> > > >
> > > > Earliest email with TomEE 7.1 in the subject is around April, though
> I
> > > vaguely recall it mentioned before.  I recall seeing a request from
> Mark to
> > > wait on it till after 7.0.5 was released.  That's now out and a TomEE
> 7.1.x
> > > branch has been created and being actively worked on.
> > > >
> > > > There seem to be concerns that this will draw attention away from
> TomEE
> > > 8, which is understandable, and some sentiment that this work should
> stop
> > > and everyone focus on TomEE 8.  I haven't seen anyone suggest not
> working
> > > on TomEE 8, so I'll assume that as a constant that doesn't need to be
> voted
> > > on.
> > > >
> > > > As the concern is largely resources, I propose the following
> compromise:
> > > >
> > > >  - MicroProfile related PRs that can possibly apply to TomEE 8 must
> be
> > > merged to master *before* the equivalent can be merged to TomEE 7.1.x.
> In
> > > short, everyone must work on TomEE 8.
> > > >
> > > >  - Those who wish to focus time only on TomEE 8 may do so, someone
> else
> > > can merge the PR to 7.1.x if they have the energy.  In short, only the
> > > willing need work on TomEE 7.1.x
> > > >
> > > > With this in mind, the vote:
> > > >
> > > >   +1 Allow work on TomEE 7.1 to proceed with the above two conditions
> > > >  +-O Abstain or don't feel strongly
> > > >   -1 I have a better idea
> > > >
> > > >
> > > >
> > > > -David
> > > >
> > >
>

Re: [VOTE] Allow an MicroProfile-focused TomEE 7.1 release

[Gurkan Erdogdu]

>
> Non-binding:
>
> -1 : if there's a lack of resource i'd prefer to see first TomEE
> compatibility with Java 11 LTS addressed as soon as possible (hoping a
> fix for at least https://issues.apache.org/jira/browse/TOMEE-2200...).
>
> Indeed, Java 11 LTS is supposed to be soon available (25/09 according
> to http://openjdk.java.net/projects/jdk/11/) and most major projects
> (Hadoop, etc.) are waiting for this LTS (Long Term Support) version to
> move beyond Java 8.
>
> I have the felling that any major release from TomEE arriving
> somewhere in November should be as ready as possible to live with this
> "new Java for the couple of upcoming years..."
>
> Thanks,
> Alexandre
>
> Thanks for your input but this VOTE  email is not related with your input.
Can you please send a new email with this? (Please don't reply to my email
in this thread :=) Thanks.
Gurkan



On Thu, Aug 9, 2018 at 2:39 PM, Alex The Rocker 
wrote:

> Non-binding:
>
> -1 : if there's a lack of resource i'd prefer to see first TomEE
> compatibility with Java 11 LTS addressed as soon as possible (hoping a
> fix for at least https://issues.apache.org/jira/browse/TOMEE-2200...).
>
> Indeed, Java 11 LTS is supposed to be soon available (25/09 according
> to http://openjdk.java.net/projects/jdk/11/) and most major projects
> (Hadoop, etc.) are waiting for this LTS (Long Term Support) version to
> move beyond Java 8.
>
> I have the felling that any major release from TomEE arriving
> somewhere in November should be as ready as possible to live with this
> "new Java for the couple of upcoming years..."
>
> Thanks,
> Alexandre
> Le jeu. 9 août 2018 à 08:09, David Blevins  a
> écrit :
> >
> > For a few months we've discussed doing and not doing a TomEE 7 flavored
> release of MicroProfile 1.x for Java EE 7 users on Java 8, tentatively
> versioned TomEE 7.1.
> >
> > Earliest email with TomEE 7.1 in the subject is around April, though I
> vaguely recall it mentioned before.  I recall seeing a request from Mark to
> wait on it till after 7.0.5 was released.  That's now out and a TomEE 7.1.x
> branch has been created and being actively worked on.
> >
> > There seem to be concerns that this will draw attention away from TomEE
> 8, which is understandable, and some sentiment that this work should stop
> and everyone focus on TomEE 8.  I haven't seen anyone suggest not working
> on TomEE 8, so I'll assume that as a constant that doesn't need to be voted
> on.
> >
> > As the concern is largely resources, I propose the following compromise:
> >
> >  - MicroProfile related PRs that can possibly apply to TomEE 8 must be
> merged to master *before* the equivalent can be merged to TomEE 7.1.x. In
> short, everyone must work on TomEE 8.
> >
> >  - Those who wish to focus time only on TomEE 8 may do so, someone else
> can merge the PR to 7.1.x if they have the energy.  In short, only the
> willing need work on TomEE 7.1.x
> >
> > With this in mind, the vote:
> >
> >   +1 Allow work on TomEE 7.1 to proceed with the above two conditions
> >  +-O Abstain or don't feel strongly
> >   -1 I have a better idea
> >
> >
> >
> > -David
> >
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

>
> In TomEE 8:
>
> I have completed MP 1.2 Support (since last week). This adds Config, Fault
> Tolerance, JWT, Health Check and Metrics. I did open a PR for it:
> https://github.com/apache/tomee/pull/141  tomee/pull/141>
>
> I have been working in the MP 1.3 Support. So far I was able to update
> Config, Metrics and add Rest Client and Open API. I had a few issues with
> Open API, which was tricky for me to integrate. There were a couple of
> funny / interesting issues around it. I’m only missing Open Tracing, which
> I hope I can add it soon enough. Here is a branch for it:
> https://github.com/radcortez/tomee/tree/tomee8-microprofile-1.3 <
> https://github.com/radcortez/tomee/tree/tomee8-microprofile-1.3>
>
> One thing that we do need is to change the JAXRS Provider to be a JsonB
> compliant. This is because some of the objects used by the MP specs
> responses use JsonB annotations and the current provider just ignores
> those. I’ve also opened a PR for that (might need some changes):
> https://github.com/apache/tomee/pull/142  tomee/pull/142>
>
>
Thank you Roberto. Can you also please open JIRA issue (main issue and we
can create sub-tasks under it) to track MP related work?
Regards.
Gurkan



On Thu, Aug 9, 2018 at 12:04 PM, Roberto Cortez  wrote:

> Hi,
>
> Ok, let me try to summarize what is happening.
>
> In TomEE 8:
>
> I have completed MP 1.2 Support (since last week). This adds Config, Fault
> Tolerance, JWT, Health Check and Metrics. I did open a PR for it:
> https://github.com/apache/tomee/pull/141  tomee/pull/141>
>
> I have been working in the MP 1.3 Support. So far I was able to update
> Config, Metrics and add Rest Client and Open API. I had a few issues with
> Open API, which was tricky for me to integrate. There were a couple of
> funny / interesting issues around it. I’m only missing Open Tracing, which
> I hope I can add it soon enough. Here is a branch for it:
> https://github.com/radcortez/tomee/tree/tomee8-microprofile-1.3 <
> https://github.com/radcortez/tomee/tree/tomee8-microprofile-1.3>
>
> One thing that we do need is to change the JAXRS Provider to be a JsonB
> compliant. This is because some of the objects used by the MP specs
> responses use JsonB annotations and the current provider just ignores
> those. I’ve also opened a PR for that (might need some changes):
> https://github.com/apache/tomee/pull/142  tomee/pull/142>
>
> In TomEE 7.1
>
> I’ve merged the initial work to setup the MP dist. It currently has MP
> Config and MP JWT. Once I’m done with the TomEE 8 work, I plan to merge it
> back to TomEE 7.1. In the end the goal would be to have MP support for both
> TomEE 8 and TomEE 7.1.
>
> I hope it helps.
>
> Cheers,
> Roberto
>
> > On 9 Aug 2018, at 08:18, David Blevins  wrote:
> >
> >> On Aug 9, 2018, at 12:11 AM, Romain Manni-Bucau 
> wrote:
> >>
> >> let's be concrete, who will implement the specs on tomee 7 and under
> >> which deadline?
> >
> > I'd like to suggest we stop talking and start doing.  Let's let people
> prove they are serious by letting them work.  If they produce nothing, no
> harm no foul.
> >
> > The 7.1 topic has been on the dev list since April and I believe is
> talked to death.  If the work is showing up, let's give it some space to
> succeed.  These emails don't help TomEE 8 or 7.1.
> >
> >
> > -David
> >
>
>

Re: [VOTE] Allow an MicroProfile-focused TomEE 7.1 release

[Gurkan Erdogdu]

+1 to start MP work on TomEE 8 master and then back port to the 7.1.

On Thu, Aug 9, 2018 at 12:33 PM, Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> +1
>
> Still don't see why a vote is needed. Let's move on and work on TomEE now
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Thu, Aug 9, 2018 at 11:05 AM, Roberto Cortez
>  > wrote:
>
> > +1
> >
> > > On 9 Aug 2018, at 09:54, Matthew Broadhead <
> matthew.broadh...@nbmlaw.co.uk.INVALID>
> > wrote:
> > >
> > > +0
> > >
> > > if TomEE 8 is available then i will use that, and probably never
> install
> > 7.1.x.  they both target java 8 anyway so it won't help if you are stuck
> on
> > a lower version?
> > >
> > > On 09/08/18 08:08, David Blevins wrote:
> > >> For a few months we've discussed doing and not doing a TomEE 7
> flavored
> > release of MicroProfile 1.x for Java EE 7 users on Java 8, tentatively
> > versioned TomEE 7.1.
> > >>
> > >> Earliest email with TomEE 7.1 in the subject is around April, though I
> > vaguely recall it mentioned before.  I recall seeing a request from Mark
> to
> > wait on it till after 7.0.5 was released.  That's now out and a TomEE
> 7.1.x
> > branch has been created and being actively worked on.
> > >>
> > >> There seem to be concerns that this will draw attention away from
> TomEE
> > 8, which is understandable, and some sentiment that this work should stop
> > and everyone focus on TomEE 8.  I haven't seen anyone suggest not working
> > on TomEE 8, so I'll assume that as a constant that doesn't need to be
> voted
> > on.
> > >>
> > >> As the concern is largely resources, I propose the following
> compromise:
> > >>
> > >>  - MicroProfile related PRs that can possibly apply to TomEE 8 must be
> > merged to master *before* the equivalent can be merged to TomEE 7.1.x. In
> > short, everyone must work on TomEE 8.
> > >>
> > >>  - Those who wish to focus time only on TomEE 8 may do so, someone
> else
> > can merge the PR to 7.1.x if they have the energy.  In short, only the
> > willing need work on TomEE 7.1.x
> > >>
> > >> With this in mind, the vote:
> > >>
> > >>   +1 Allow work on TomEE 7.1 to proceed with the above two conditions
> > >>  +-O Abstain or don't feel strongly
> > >>   -1 I have a better idea
> > >>
> > >>
> > >>
> > >> -David
> > >>
> > >
> >
> >
>

Re: Microprofile JWT impl Enum injection

[Gurkan Erdogdu]

>
> I updated this so we don't have special code to convert enum, but rather
> we use xbean-reflect's conversion capabilities which handles enum and much
> more.
>

Thank you David.

On Thu, Aug 9, 2018 at 8:00 AM, David Blevins 
wrote:

> I updated this so we don't have special code to convert enum, but rather
> we use xbean-reflect's conversion capabilities which handles enum and much
> more.
>
> Small change:
>
>  - https://github.com/apache/tomee/commit/1217e64a8a3eef021e9cad1e6eb02a
> 4e5d2d38c4
>
> Xbean-reflect's conversion capabilities are basically as simple as:
>
>  - `PropertyEditors.getValue(type, claimValue)`
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Aug 3, 2018, at 1:16 PM, Ivan Junckes Filho 
> wrote:
> >
> > Thank you JL.
> >
> > On Fri, Aug 3, 2018 at 5:13 PM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> > wrote:
> >
> >> Hey Ivan,
> >>
> >> Thanks for the patch.
> >> I have reviewed and merge the PR against master and the backport to
> >> tomee-7.1.x
> >>
> >>
> >>
> >> --
> >> Jean-Louis Monteiro
> >> http://twitter.com/jlouismonteiro
> >> http://www.tomitribe.com
> >>
> >> On Fri, Aug 3, 2018 at 9:51 PM, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> >> wrote:
> >>
> >>> Hello guys, I did a fix so the Microprofile JWT impl has support for
> >>> injecting Enums. Basically checks if the injection point is an enum and
> >>> then convert it.
> >>>
> >>> Please review:
> >>> https://github.com/apache/tomee/pull/143
> >>>
> >>> Thanks.
> >>>
> >>
>
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

>
> We can definitely vote, but would be great if we can way a day or two to
> discuss what we'd be voting and what our status is and how to best address
> our concerns.
>
+1


> We all universally agree we want MP in TomEE 8 and are actively working on
> it
>
I am not sure there is an active MP work in TomEE


> Some of us see value in and are actively working on MP support in a TomEE
> 7.1 in addition to TomEE 8
>
>From my perspective, I would like to have fully latest MP2 in TomEE 8, not
in TomEE 7.1 but I am not against it. Currently we have little power.

My understanding of the concern is that we end up ignoring TomEE 8, which
> is a concern I would share.
>
I did not understand what you mean by ignoring TomEE 8 .Can you please a
bit elaborate? Who ignore?


Perhaps the most effective vote would be to vote to require those who do
> work on a TomEE 7.1 to also submit the same PR to TomEE 8. If a PR comes
> into TomEE 7.1 only and that work is needed in TomEE 8, but there isn't a
> PR, we reject it.
>
-1. Different people can work on TomEE 7.1 and TomEE 8. We need to
differentiate TomEE 7.1 from TomEE 8. TomEE 7.1 is just in there to only
include MP1. We don't want to wait TomEE 7.1 for TomEE 8.


We remind the person we voted that TomEE 8 is the priority and TomEE 7.1
> work can happen as long as we don't ignore TomEE 8.
>
Our priority must be TomEE 8.

If someone wants to submit an MicroProfile PR to TomEE 8 only, go right
> ahead, those who want to see a TomEE 7.1 will have to back port it if
> they're serious about a TomEE 7.1
>
++1, exactly. MP2 must be started in TomEE 8 and if want to see at TomEE
7.1, any volunteer can back port to it.

Regards.
Gurkan


On Thu, Aug 9, 2018 at 2:10 AM, David Blevins 
wrote:

> > On Aug 8, 2018, at 2:48 PM, Gurkan Erdogdu  wrote:
> >
> >>
> >> What I don't understand on this is that if there are people willing to
> do
> >> the work on both, why would we stop them?  Delivering to both the Java
> EE 7
> >> and Java EE 8 TomEE users would be a good thing.
> >>
> > I am not against both Java EE 7 and Java EE 8 specific MP
> implementations.
> > Just need to have contribution power both on this. We can definitely add
> > this option to the vote thread. So the vote will include:
> >
> >   - Go only with MP1 with Java EE 7 (TomEE 7.1)
> >   - Go only with MP2 with Java EE 8 (TomEE 8.0)
> >   - Go for both
>
> We can definitely vote, but would be great if we can way a day or two to
> discuss what we'd be voting and what our status is and how to best address
> our concerns.
>
> Here's my understanding of our status.
>
>  - We all universally agree we want MP in TomEE 8 and are actively working
> on it
>  - Some of us see value in and are actively working on MP support in a
> TomEE 7.1 in addition to TomEE 8
>
> I haven't seen anyone propose a TomEE 7.1-only option.  My understanding
> of the concern is that we end up ignoring TomEE 8, which is a concern I
> would share.
>
> Perhaps the most effective vote would be to vote to require those who do
> work on a TomEE 7.1 to also submit the same PR to TomEE 8.  If a PR comes
> into TomEE 7.1 only and that work is needed in TomEE 8, but there isn't a
> PR, we reject it.  We remind the person we voted that TomEE 8 is the
> priority and TomEE 7.1 work can happen as long as we don't ignore TomEE 8.
> If someone wants to submit an MicroProfile PR to TomEE 8 only, go right
> ahead, those who want to see a TomEE 7.1 will have to back port it if
> they're serious about a TomEE 7.1
>
> I'd certainly vote +1 for that.
>
>
> -David
>
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

>
> What I don't understand on this is that if there are people willing to do
> the work on both, why would we stop them?  Delivering to both the Java EE 7
> and Java EE 8 TomEE users would be a good thing.
>
I am not against both Java EE 7 and Java EE 8 specific MP implementations.
Just need to have contribution power both on this. We can definitely add
this option to the vote thread. So the vote will include:

   - Go only with MP1 with Java EE 7 (TomEE 7.1)
   - Go only with MP2 with Java EE 8 (TomEE 8.0)
   - Go for both

Romain, would you like to create this VOTE thread? Or any other comment
before the vote process?
Regards.
Gurkan

On Thu, Aug 9, 2018 at 12:40 AM, David Blevins 
wrote:

> > On Aug 8, 2018, at 1:58 PM, Gurkan Erdogdu  wrote:
> >
> >>
> >> Going straight on 8.x is easier and gives at
> >> least the same features to end users -
> >>
> >
> > +1 on this but this will also needs a VOTE. Can you please create a VOTE
> > thread on this to decide?
>
> What I don't understand on this is that if there are people willing to do
> the work on both, why would we stop them?  Delivering to both the Java EE 7
> and Java EE 8 TomEE users would be a good thing.
>
>
> -David
>
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

>
> Going straight on 8.x is easier and gives at
> least the same features to end users -
>

+1 on this but this will also needs a VOTE. Can you please create a VOTE
thread on this to decide?
Regards.
Gurkan

On Wed, Aug 8, 2018 at 11:53 PM, Romain Manni-Bucau 
wrote:

> Le mer. 8 août 2018 22:45, Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> a écrit :
>
> > On Wed, Aug 8, 2018 at 9:32 PM, Gurkan Erdogdu 
> > wrote:
> >
> > > Hi all,
> > > Can you please summarize the current state of MP in TomEE versions? I
> > > really lost and confused that different people is working on some
> > > (different) part of MP stuff. I really lost on all of these patches and
> > > different branches.
> > >
> >
> > 1.7.x -> EE6, no MP
> > 7.0.x -> EE7, no MP
> > 7.1.x -> EE7, Java 8, MP (not sure what level / specs)
> >
>
> Anyone planning to impl it? Going straight on 8.x is easier and gives at
> least the same features to end users - backporting mp impl on cdi 1 is some
> work and bugfixes in owb.
>
> 8.0.x (Master) -> EE8, Java 8, MP (not sure what level / specs)
> >
>
>
> MP2++
>
> >
> >
> > >
> > > Also, before adding anything to the codebase, can we first create a
> JIRA
> > > issue to track?
> > >
> >
> > That's a reasonable callout - are you seeing that happen?
> >
>

Re: MP Summary in TomEE

[Gurkan Erdogdu]

Thanks Jon and Romain for your emails. Romain, sorry but I don't get it
right fully in your email :)
>From my perspective, without clear definitions and consensus on the mailing
list, it is not logical to move with partially defined MP.
I think we also need to remove TomEE specific JWT Auth module and also uses
Geronimo one.

Hi Roberto,
Did you create the Jira issue for the MP areas you have been working on?
(If not can you please create a one and if necessary we can create sub
items?)
Can you please summarize your current ideas in this JIRA ticket?
Regards.
Gurkan


On Wed, Aug 8, 2018 at 11:45 PM, Romain Manni-Bucau 
wrote:

> Hi Gurkan,
>
> From what I know tomee hosts a not finished mp jwt auth impl and that is
> it. It was however made cdi "in container" friendly which means we can
> import all geronimo impl as it (even through tomee:build goal of our mojo
> which is good for end users cause doing an pp distro is easily broken as
> delivery if you dont use the full stack and respect the spec).
>
> Roberto was hacking in that area I think but not sure anyone else was doing
> anything.
>
> Le mer. 8 août 2018 22:32, Gurkan Erdogdu  a écrit :
>
> > Hi all,
> > Can you please summarize the current state of MP in TomEE versions? I
> > really lost and confused that different people is working on some
> > (different) part of MP stuff. I really lost on all of these patches and
> > different branches.
> >
> > Also, before adding anything to the codebase, can we first create a JIRA
> > issue to track?
> >
> > Regards.
> > Gurkan
> >
>

MP Summary in TomEE

[Gurkan Erdogdu]

Hi all,
Can you please summarize the current state of MP in TomEE versions? I
really lost and confused that different people is working on some
(different) part of MP stuff. I really lost on all of these patches and
different branches.

Also, before adding anything to the codebase, can we first create a JIRA
issue to track?

Regards.
Gurkan

Re: TomEE 8 Jsonb Provider

[Gurkan Erdogdu]

Hello Mark
Instead of using this thread, can you please create a new VOTE thread on
this (versioning for the TomEE 8 release) ?
Regards.
Gurkan

On Tue, Aug 7, 2018 at 3:33 PM, Mark Struberg 
wrote:

> Folks, probably it's easier to push hard for a first TomEE8 release?
> Things like the JsonbProvider will fall into place quite naturally.
>
> We just have to be clear about how we name that baby.
> So far we have 2 options on the table:
>
> A.) Go 8.0.0, 8.0.1, etc now and openly declaring that we address JavaEE8
> but are not certified.
>  Plus release 8.1.0 one JakartaEE8 TCK is available and we pass it.
>
> B.) Go 8.0.0-M1, M2, etc. And do a 8.0.0 once we pass the JakartaEE8 TCK.
> Note that this will mean that we will see a good year without any proper
> non-M release. And this might hurt adoption.
>
> LieGrue,
> strub
>
>
>
>
>
>
> > Am 02.08.2018 um 17:59 schrieb Romain Manni-Bucau  >:
> >
> > if we want to provide a flag yes but since we'll break as much not
> > providing the lib (it is as hard to set the flag than to add a lib) and
> > since staying small and minimalistic always has been something very core
> of
> > TomEE I start to think we should just drop it and well document that.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  rmannibucau> |
> > LinkedIn  | Book
> >  ee-8-high-performance>
> >
> >
> > Le jeu. 2 août 2018 à 17:52, Roberto Cortez 
> a
> > écrit :
> >
> >> If we want to have a flag that allows the user to return to the old
> >> provider, don't we need to keep johnson-jaxrs?
> >> I'm in favour of adding a simple flag that switches between old / new.
> >> Something like openejb.jaxrs.legacy.providers = true / false.
> >>On Thursday, August 2, 2018, 4:42:13 PM GMT+1, Romain Manni-Bucau <
> >> rmannibu...@gmail.com> wrote:
> >>
> >> Sure, the target is quite clear I think, but we should mitigate the side
> >> effect for our users, this is why a flag can be worth it.
> >> That said we can drop johnzon-jaxrs going to johnzon-jsonb so not sure
> it
> >> will be better than when we dropped jettison. Only positive thing is the
> >> default serialization will not change, only API is different if it was
> set
> >> explicitly (@JsonbProperty or so).
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >> https://www.packtpub.com/application-development/java-
> ee-8-high-performance
> >>>
> >>
> >>
> >> Le jeu. 2 août 2018 à 17:37, Roberto Cortez  >
> >> a
> >> écrit :
> >>
> >>>
> >>> Maybe we need some more opinions. I don't know how strong is the
> >>> integration between json-b and jax-rs in EE8, but I would expect for
> >>> response objects annotated with jsonb annotations to be respected and
> >> have
> >>> this working OOTB in the standard server without additional
> >> configuration.
> >>> I wonder if we should write an hybrid provider that would use the Jsonb
> >>> one if the response object finds Jsonb annotations and if not fallback
> to
> >>> the TomEE 7 one?On Thursday, August 2, 2018, 4:31:41 PM GMT+1,
> Romain
> >>> Manni-Bucau  wrote:
> >>>
> >>> Yep, or we just do it OOTB for the MP distro in a first step.
> >>> I don't have any strong opinion since in all cases we'll break some
> users
> >>> :(.
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>>
> >> https://www.packtpub.com/application-development/java-
> ee-8-high-performance
> 
> >>>
> >>>
> >>> Le jeu. 2 août 2018 à 17:26, Roberto Cortez
>  >>>
> >>> a
> >>> écrit :
> >>>
>  I understand.
>  I think we need to do it, since I've found a couple of issues with the
> >> MP
>  TCK using models with Jsonb annotations that were not being applied
> due
> >>> to
>  the missing provider. And Jsonb is also part of EE 8, so I believe
> this
>  should be the default behaviour.
>  To return to the old behaviour, we could have instructions to setup
> the
>  old provider via system.properties, right? Via cxf.jaxrs.providers?
>    On Thursday, August 2, 2018, 3:47:48 PM GMT+1, Romain Manni-Bucau <
>  rmannibu...@gmail.com> wrote:
> 
>  Hi Roberto,
> 
>  You can't get this one and the old johnzon mapper at the same time
> >> (both
>  will conflict).
>  I'm all for migrating to jsonb but note it will break end us

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

>
> If you accept SNAPSHOTs in that statement then it is since months.
>

For me, this statement is only valid after you release the 8.0.0-SNAPSHOT.
Some couple of user can internally deploy the SNAPSHOT version in your
projects, but you can not assume that every user was doing this because the
8.0 branch has not been formally released :)
Regards.
Gurkan

On Sun, Jul 29, 2018 at 6:32 PM, Romain Manni-Bucau 
wrote:

> Le dim. 29 juil. 2018 à 17:30, Gurkan Erdogdu  a
> écrit :
>
> > At a minimum, if some users (move from 7.0.x to 8.0.x) are successfully
> > used it in production systems for a period of time, then I can call it
> > stable release.
>
>
> If you accept SNAPSHOTs in that statement then it is since months.
>
>
> > At the first release, when you say that it is production
> > ready, it is somebit unrealistic. But, if you still want to release it as
> > 8.0.0, you can warn the user that this is the first release and not ready
> > for production.
> > Anyway, I just wanted to share my opinion. If the project members want to
> > go this way, you can absolutely do.
> > Regards.
> > Gurkan
> >
> > On Sun, Jul 29, 2018 at 6:16 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > This is actually what we did since the beginning of TomEE.
> > > Also keep in mind milestone, alpha, beta = don't even look at the
> release
> > > for all users who don't want to check a SNAPSHOT so at the end the gain
> > of
> > > doing a milestone is mainly to loose time in a release process and not
> to
> > > get any feedback - at least that's what we saw here. Therefore the fact
> > to
> > > directly go live is probably saner and doesn't prevent to fix issues
> > > quickly.
> > >
> > > 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 dim. 29 juil. 2018 à 17:14, Gurkan Erdogdu  a
> > > écrit :
> > >
> > > > From my perspective, this is not realistic. You are releasing the
> first
> > > > version for JDK 8, MP 1 after getting 8.0 branch to master, and at
> the
> > > > first release you are saying that this is production ready. At least,
> > we
> > > > will need to let users some time to try it and give feedbakcs. I
> don't
> > > say
> > > > that M1 goes to M2, M3 etc. But, at least, you need to receive some
> > > > feedback from the users who will move from Tomcat 7.0.x to 8.0.x. I
> can
> > > not
> > > > tell our users that you can directly move from 7.0.x to 8.0.x at the
> > > > initial release.
> > > > Regards.
> > > > Gurkan
> > > >
> > > > On Sun, Jul 29, 2018 at 6:07 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Being said all the stack is already in prod and the glue code is
> too
> > > (it
> > > > is
> > > > > in 7.x for most of it and some users even deploy the snapshot in
> > prod)
> > > I
> > > > > really think we should go directly to 8.0.0. Since we already
> > > decoralated
> > > > > from the spec and certification for the 7.x then we don't need to
> use
> > > the
> > > > > milestone workaround we used for the 1.x to ensure 1.0.0 was
> > > certificed.
> > > > So
> > > > > yes, 8.0.0 directly is really ok :).
> > > > >
> > > > > 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 dim. 29 juil. 2018 à 17:0

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

At a minimum, if some users (move from 7.0.x to 8.0.x) are successfully
used it in production systems for a period of time, then I can call it
stable release. At the first release, when you say that it is production
ready, it is somebit unrealistic. But, if you still want to release it as
8.0.0, you can warn the user that this is the first release and not ready
for production.
Anyway, I just wanted to share my opinion. If the project members want to
go this way, you can absolutely do.
Regards.
Gurkan

On Sun, Jul 29, 2018 at 6:16 PM, Romain Manni-Bucau 
wrote:

> This is actually what we did since the beginning of TomEE.
> Also keep in mind milestone, alpha, beta = don't even look at the release
> for all users who don't want to check a SNAPSHOT so at the end the gain of
> doing a milestone is mainly to loose time in a release process and not to
> get any feedback - at least that's what we saw here. Therefore the fact to
> directly go live is probably saner and doesn't prevent to fix issues
> quickly.
>
> 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 dim. 29 juil. 2018 à 17:14, Gurkan Erdogdu  a
> écrit :
>
> > From my perspective, this is not realistic. You are releasing the first
> > version for JDK 8, MP 1 after getting 8.0 branch to master, and at the
> > first release you are saying that this is production ready. At least, we
> > will need to let users some time to try it and give feedbakcs. I don't
> say
> > that M1 goes to M2, M3 etc. But, at least, you need to receive some
> > feedback from the users who will move from Tomcat 7.0.x to 8.0.x. I can
> not
> > tell our users that you can directly move from 7.0.x to 8.0.x at the
> > initial release.
> > Regards.
> > Gurkan
> >
> > On Sun, Jul 29, 2018 at 6:07 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Being said all the stack is already in prod and the glue code is too
> (it
> > is
> > > in 7.x for most of it and some users even deploy the snapshot in prod)
> I
> > > really think we should go directly to 8.0.0. Since we already
> decoralated
> > > from the spec and certification for the 7.x then we don't need to use
> the
> > > milestone workaround we used for the 1.x to ensure 1.0.0 was
> certificed.
> > So
> > > yes, 8.0.0 directly is really ok :).
> > >
> > > 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 dim. 29 juil. 2018 à 17:04, Gurkan Erdogdu  a
> > > écrit :
> > >
> > > > If you release as 8.0.0, you means that it is production ready? Is
> > 8.0.0
> > > > production ready at the first release? At least, at the first release
> > you
> > > > can add some indication that it is not production ready or it is the
> > > first
> > > > release etc such as M1, CR1. This is the general consensus on release
> > > > process.
> > > > Regards.
> > > > Gurkan
> > > >
> > > > On Sun, Jul 29, 2018 at 4:41 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > +1, even a 8.0.0, no need of milestones
> > > > >
> > > > > Le dim. 29 juil. 2018 14:27, Gurkan Erdogdu 
> a
> > > > écrit
> > > > > :
> > > > >
> > > > > > Hi team
> > > > > > Sorry about this question (even discussed before lots of time)
> but
> > > what
> > > > > is
> > > > > > the meaning of creating 7.1 branch? Just MP with JDK 8?
> > > > > > If that's the only reason why not publish TomEE 8 with a
> milestone
> > > like
> > > > > > TomEE 8.0_M1 or something similar including MP?
> > > > > &g

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

>From my perspective, this is not realistic. You are releasing the first
version for JDK 8, MP 1 after getting 8.0 branch to master, and at the
first release you are saying that this is production ready. At least, we
will need to let users some time to try it and give feedbakcs. I don't say
that M1 goes to M2, M3 etc. But, at least, you need to receive some
feedback from the users who will move from Tomcat 7.0.x to 8.0.x. I can not
tell our users that you can directly move from 7.0.x to 8.0.x at the
initial release.
Regards.
Gurkan

On Sun, Jul 29, 2018 at 6:07 PM, Romain Manni-Bucau 
wrote:

> Being said all the stack is already in prod and the glue code is too (it is
> in 7.x for most of it and some users even deploy the snapshot in prod) I
> really think we should go directly to 8.0.0. Since we already decoralated
> from the spec and certification for the 7.x then we don't need to use the
> milestone workaround we used for the 1.x to ensure 1.0.0 was certificed. So
> yes, 8.0.0 directly is really ok :).
>
> 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 dim. 29 juil. 2018 à 17:04, Gurkan Erdogdu  a
> écrit :
>
> > If you release as 8.0.0, you means that it is production ready? Is 8.0.0
> > production ready at the first release? At least, at the first release you
> > can add some indication that it is not production ready or it is the
> first
> > release etc such as M1, CR1. This is the general consensus on release
> > process.
> > Regards.
> > Gurkan
> >
> > On Sun, Jul 29, 2018 at 4:41 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > +1, even a 8.0.0, no need of milestones
> > >
> > > Le dim. 29 juil. 2018 14:27, Gurkan Erdogdu  a
> > écrit
> > > :
> > >
> > > > Hi team
> > > > Sorry about this question (even discussed before lots of time) but
> what
> > > is
> > > > the meaning of creating 7.1 branch? Just MP with JDK 8?
> > > > If that's the only reason why not publish TomEE 8 with a milestone
> like
> > > > TomEE 8.0_M1 or something similar including MP?
> > > > Possible to release TomEE 8.0.M1 using Geronimo MP implementation
> > instead
> > > > of using TomEE 7.1 branch?
> > > > Thanks
> > > > Gurkan
> > > >
> > > >
> > > > On Thu, Jul 26, 2018 at 3:52 PM, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> wrote:
> > > >
> > > > > Everything should be merged and mistake fixed (wrong branch
> deleted)
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > > On Thu, Jul 26, 2018 at 1:43 PM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Ok,
> > > > > > then AFAIK it will not be a "work" branch but just an aggregator
> > > branch
> > > > > so
> > > > > > I see two good compromises:
> > > > > >
> > > > > > 1. use tomee 7.0 (we just add a mp module with tomee-maven-plugin
> > > Vn-1
> > > > to
> > > > > > import MP impls and bundle it), no compile issue, tomee 7.0 stays
> > > java
> > > > 7
> > > > > > and MP is aligned on java 8
> > > > > > 2. we make 7.1 directly a branch and we release it at the same
> time
> > > > than
> > > > > > 8.0.0
> > > > > >
> > > > > > wdyt?
> > > > > >
> > > > > > 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.packt

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

If you release as 8.0.0, you means that it is production ready? Is 8.0.0
production ready at the first release? At least, at the first release you
can add some indication that it is not production ready or it is the first
release etc such as M1, CR1. This is the general consensus on release
process.
Regards.
Gurkan

On Sun, Jul 29, 2018 at 4:41 PM, Romain Manni-Bucau 
wrote:

> +1, even a 8.0.0, no need of milestones
>
> Le dim. 29 juil. 2018 14:27, Gurkan Erdogdu  a écrit
> :
>
> > Hi team
> > Sorry about this question (even discussed before lots of time) but what
> is
> > the meaning of creating 7.1 branch? Just MP with JDK 8?
> > If that's the only reason why not publish TomEE 8 with a milestone like
> > TomEE 8.0_M1 or something similar including MP?
> > Possible to release TomEE 8.0.M1 using Geronimo MP implementation instead
> > of using TomEE 7.1 branch?
> > Thanks
> > Gurkan
> >
> >
> > On Thu, Jul 26, 2018 at 3:52 PM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > Everything should be merged and mistake fixed (wrong branch deleted)
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > > On Thu, Jul 26, 2018 at 1:43 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Ok,
> > > > then AFAIK it will not be a "work" branch but just an aggregator
> branch
> > > so
> > > > I see two good compromises:
> > > >
> > > > 1. use tomee 7.0 (we just add a mp module with tomee-maven-plugin
> Vn-1
> > to
> > > > import MP impls and bundle it), no compile issue, tomee 7.0 stays
> java
> > 7
> > > > and MP is aligned on java 8
> > > > 2. we make 7.1 directly a branch and we release it at the same time
> > than
> > > > 8.0.0
> > > >
> > > > wdyt?
> > > >
> > > > 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. 26 juil. 2018 à 12:52, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> a écrit :
> > > >
> > > > > No. As far as I'm concerned its supported for as long as someone is
> > > > willing
> > > > > to support it. I'm willing to support it, and I'm willing to
> support
> > > > 1.7.x
> > > > > also.
> > > > >
> > > > > Jon
> > > > >
> > > > > On Thu, Jul 26, 2018 at 11:39 AM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Ok so means we drop tomee 7.0 support with next release?
> > > > > >
> > > > > >
> > > > > > Le jeu. 26 juil. 2018 12:20, Jonathan Gallimore <
> > > > > > jonathan.gallim...@gmail.com> a écrit :
> > > > > >
> > > > > > > On Thu, Jul 26, 2018 at 11:18 AM, Mark Struberg
> > > > > >  > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Yes, the following steps are now up to get done:
> > > > > > > >
> > > > > > > > 1.) Move the current master to a tomee-7.0.x branch
> > > > > > > >
> > > > > > >
> > > > > > > Done
> > > > > > >
> > > > > > >
> > > > > > > > 2.) Create a new tomee-7.1.x branch, upgrade to Java8 and add
> > > > > > > MicroProfile
> > > > > > > >
> > > > > > >
> > > > > > > JL doing
> > > > > > >
> > > > > > >
> > > > > > > > 2.) Move the tomee-8.x branch to master and get stuff rolling
> > > here
> > > > as
> > > > > > > well.
> > > > > > > >
> > > > > > >
> > > > > > > Done.
> > > > > > >
> > > > > > > There was a force-push involved to update master. Hope that
> > doesn't
> > > > > cause
> > > > > > > issues, but apologies if it does.
> > > > > > >
> > > > > > > Jon
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

Hi team
Sorry about this question (even discussed before lots of time) but what is
the meaning of creating 7.1 branch? Just MP with JDK 8?
If that's the only reason why not publish TomEE 8 with a milestone like
TomEE 8.0_M1 or something similar including MP?
Possible to release TomEE 8.0.M1 using Geronimo MP implementation instead
of using TomEE 7.1 branch?
Thanks
Gurkan


On Thu, Jul 26, 2018 at 3:52 PM, Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Everything should be merged and mistake fixed (wrong branch deleted)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Thu, Jul 26, 2018 at 1:43 PM, Romain Manni-Bucau  >
> wrote:
>
> > Ok,
> > then AFAIK it will not be a "work" branch but just an aggregator branch
> so
> > I see two good compromises:
> >
> > 1. use tomee 7.0 (we just add a mp module with tomee-maven-plugin Vn-1 to
> > import MP impls and bundle it), no compile issue, tomee 7.0 stays java 7
> > and MP is aligned on java 8
> > 2. we make 7.1 directly a branch and we release it at the same time than
> > 8.0.0
> >
> > wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | Book
> >  > ee-8-high-performance>
> >
> >
> > Le jeu. 26 juil. 2018 à 12:52, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > No. As far as I'm concerned its supported for as long as someone is
> > willing
> > > to support it. I'm willing to support it, and I'm willing to support
> > 1.7.x
> > > also.
> > >
> > > Jon
> > >
> > > On Thu, Jul 26, 2018 at 11:39 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Ok so means we drop tomee 7.0 support with next release?
> > > >
> > > >
> > > > Le jeu. 26 juil. 2018 12:20, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> a écrit :
> > > >
> > > > > On Thu, Jul 26, 2018 at 11:18 AM, Mark Struberg
> > > >  > > > > >
> > > > > wrote:
> > > > >
> > > > > > Yes, the following steps are now up to get done:
> > > > > >
> > > > > > 1.) Move the current master to a tomee-7.0.x branch
> > > > > >
> > > > >
> > > > > Done
> > > > >
> > > > >
> > > > > > 2.) Create a new tomee-7.1.x branch, upgrade to Java8 and add
> > > > > MicroProfile
> > > > > >
> > > > >
> > > > > JL doing
> > > > >
> > > > >
> > > > > > 2.) Move the tomee-8.x branch to master and get stuff rolling
> here
> > as
> > > > > well.
> > > > > >
> > > > >
> > > > > Done.
> > > > >
> > > > > There was a force-push involved to update master. Hope that doesn't
> > > cause
> > > > > issues, but apologies if it does.
> > > > >
> > > > > Jon
> > > > >
> > > >
> > >
> >
>

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

>
> Because the Geronimo MP is not fully implements the MP specification
>

Sorry I mean Geronimo MP *fully implements* the MP specification

On Thu, Jul 26, 2018 at 9:13 AM, Gurkan Erdogdu  wrote:

> Hi Romain
> Great news!
> I don't see any benefits to replicate the same efforts in two different
> locations. Because the Geronimo MP is not fully implements the MP
> specification and attracted more contributors, we should help them instead
> of implementing the same stuff in here. (I know that there are tons of
> discussions about this subject but we need to do it correctly.)
> WDYT?
> Regards.
> Gurkan
>
> On Thu, Jul 26, 2018 at 7:57 AM, Romain Manni-Bucau  > wrote:
>
>> Hi guys
>>
>> Didnt we plan to switch master to tomee 8 after the 7.0.5? Also not sure
>> we
>> want the 7.1 (we didnt finish the discussion IIRC).
>>
>> As a side note: geronimo is MP complete (yes I didnt resist to the joke)
>> so
>> maybe time to just import it all?
>>
>> Romain
>>
>>
>> Le jeu. 26 juil. 2018 01:26, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> a écrit :
>>
>> > Awesome, thanks Roberto!
>> >
>> > On Wed, Jul 25, 2018 at 7:16 PM, Roberto Cortez
>> > > > > wrote:
>> >
>> > > Hi everyone,
>> > > I've picked up some of the work started by JL on the tomee-7.1.x
>> branch
>> > to
>> > > have a release with some MP support.
>> > > I've updated the branch with the latest 7.0.5 code, plus, fixed some
>> > > issues with the MP Configuration and MP JWT integration.
>> > > I've opened the following PR:https://github.com/apache/tomee/pull/138
>> > >
>> > > Hope it is ok.
>> > > Cheers,Roberto
>> >
>>
>
>

Re: TomEE 7.1 with MP

[Gurkan Erdogdu]

Hi Romain
Great news!
I don't see any benefits to replicate the same efforts in two different
locations. Because the Geronimo MP is not fully implements the MP
specification and attracted more contributors, we should help them instead
of implementing the same stuff in here. (I know that there are tons of
discussions about this subject but we need to do it correctly.)
WDYT?
Regards.
Gurkan

On Thu, Jul 26, 2018 at 7:57 AM, Romain Manni-Bucau 
wrote:

> Hi guys
>
> Didnt we plan to switch master to tomee 8 after the 7.0.5? Also not sure we
> want the 7.1 (we didnt finish the discussion IIRC).
>
> As a side note: geronimo is MP complete (yes I didnt resist to the joke) so
> maybe time to just import it all?
>
> Romain
>
>
> Le jeu. 26 juil. 2018 01:26, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
> > Awesome, thanks Roberto!
> >
> > On Wed, Jul 25, 2018 at 7:16 PM, Roberto Cortez
> >  > > wrote:
> >
> > > Hi everyone,
> > > I've picked up some of the work started by JL on the tomee-7.1.x branch
> > to
> > > have a release with some MP support.
> > > I've updated the branch with the latest 7.0.5 code, plus, fixed some
> > > issues with the MP Configuration and MP JWT integration.
> > > I've opened the following PR:https://github.com/apache/tomee/pull/138
> > >
> > > Hope it is ok.
> > > Cheers,Roberto
> >
>

Re: Closing JIRA Issues

[Gurkan Erdogdu]

Yes I did (and solved some of them) and this is my second reminder email.
There are tons of old JIRA issues (some back to years ago) out there and
needs to be updated.
Could you please help to close those issues?
Regards.
Gurkan

On Wed, Jul 25, 2018 at 7:46 PM, Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Have you done a first round on the JIRAs?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Tue, Jul 24, 2018 at 10:07 PM, Gurkan Erdogdu 
> wrote:
>
> > Hi team,
> > Could you please go over the current JIRA issues and update them
> according
> > to the latest status? (i.e Change their state as Close, Not Fix, or
> Update
> > the Fix for version).
> > Regards.
> > Gurkan
> >
>

Closing JIRA Issues

[Gurkan Erdogdu]

Hi team,
Could you please go over the current JIRA issues and update them according
to the latest status? (i.e Change their state as Close, Not Fix, or Update
the Fix for version).
Regards.
Gurkan

Re: Docker and TomEE, what's our status? (was [RELEASE] TomEE 7.0.5)

[Gurkan Erdogdu]

Hi
+1 For Romain advice
Regards.
Gurkan

On Tue, Jul 24, 2018 at 10:41 PM, Romain Manni-Bucau 
wrote:

> Hi guys,
>
> quick - really overdue - follow up on docker thanks to Otavio mail (mainly
> small 3 points):
>
> 1. We have an apache account on docker https://hub.docker.com/r/apache/, I
> wonder if we want to publish it here with the ASF stamp (on hub, not sure
> we want to do it on the store)?
>
> 2. Also I reviewed the community images some months ago - for some task at
> work - and realized we had a lot of good community images like jelastic
> ones which was even published with openj9. Do we want to do the same if we
> publish as ASF, ie include more jre?
>
> 3. Current naming is not aligned on Tomcat, ie include our complete
> version, jvm version and os version, is it something we would want (think
> so)?
>
> In terms of process if we want to have ASF images we need to create a
> ticket on INFRA and do a few updates to have deploys from tags (see
> https://issues.apache.org/jira/browse/INFRA-13838 for a sample).
>
> Once we have ASF images we should probably add some love on our doc (like
> adding a docker page where we explain how 1. to use it and 2. use it with a
> multistage image to be closer to the prod). We can also probably recommand
> an image cause with the generation which is generally done it is hard for a
> new user to pick one not randomly.
>
> Wdyt? Anyone interested in working on that or some aspects?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
>
> -- Forwarded message -
> From: Otávio Gonçalves de Santana 
> Date: mar. 24 juil. 2018 à 21:11
> Subject: Re: [RELEASE] TomEE 7.0.5
> To: 
>
>
> The newest version is available at docker hub:
> https://store.docker.com/images/tomee
>
> On Mon, Jul 23, 2018 at 11:59 AM, cocorossello 
> wrote:
>
> > Great news!
> >
> > Looking forward for a tomee 8 release, we have been using it for a couple
> > of
> > months now (building from source and private releases), and I can confirm
> > that it works fine with java 10
> >
> >
> >
> > --
> > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-
> > f979441.html
> >
>

Re: [VOTE] Release Apache TomEE 7.0.5 (round 2)

[Gurkan Erdogdu]

Hello team
What is the latest state about this vote? (I am lost because some other
comments also exists in the vote mail chain). My advice is not pollute the
VOTE mail with other stuff instead starting another email thread.
Regards.
Gurkan

On Fri, Jul 20, 2018 at 6:36 PM, Romain Manni-Bucau 
wrote:

> You can set > in the tomee-maven-plugin
> and upgrade the plugin version for the embedded flavor
>
> (don't forget the repository and pluginRespotory pointing on the staging)
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
>
> Le ven. 20 juil. 2018 à 17:33, gilbertoca  a écrit :
>
> > How can I evaluate this build if I just use tomee-maven-plugin and
> > tomee-embedded-maven-plugin?
> >
> > We develop with tomee-embedded-maven-plugin and create/deploy a jar with
> > tomee-maven-plugin.
> >
> > Regards,
> > Gilberto
> >
> >
> > jgallimore wrote
> > > Hi Everyone,
> > >
> > > Here is the second roll of TomEE 7.0.5. Please can you take a look and
> > > vote? Everyone, committer or not, is encouraged to test and vote.
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/orgapachetomee-1115
> > >
> > > Source zip:
> > >
> > https://repository.apache.org/content/repositories/
> orgapachetomee-1115/org/apache/tomee/tomee-project/7.
> 0.5/tomee-project-7.0.5-source-release.zip
> > >
> > > Dist area:
> > > https://dist.apache.org/repos/dist/dev/tomee/staging-1115/
> > >
> > > Legal:
> > > https://dist.apache.org/repos/dist/dev/tomee/staging-1115/legal.zip
> > >
> > > Keys:
> > > https://dist.apache.org/repos/dist/release/tomee/KEYS
> > >
> > > Libraries changed since TomEE 7.0.4:
> > >
> > > Tomcat => 8.5.32
> > > CXF => 3.1.15
> > > Johnzon => 1.0.1
> > > OWB => 1.7.5
> > > XBean => 4.9
> > > XmlSchema core => 2.2.3
> > > OpenJPA => 2.4.3
> > >
> > > Changes since the last roll:
> > >
> > > - Remove javax.xml.soap-api-1.3.5.jar library which was incorrectly
> > > included
> > > - Update to Tomcat 8.5.32
> > > - Change JNDI name used for datasource in CDI TCK test to use an
> > > equivalent
> > > name under the java: namespace
> > >
> > > Changelog:
> > > https://issues.apache.org/jira/browse/TOMEE-2175?jql=project
> > > %20%3D%20TOMEE%20AND%20(status%20%3D%20Resolved%20OR%20statu
> > > s%20%3D%20CLOSED)%20AND%20fixVersion%20%3D%207.0.5%20O
> > > RDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > >
> > > (If anyone knows a better way to get that list, let me know ;-) )
> > >
> > > Please vote:
> > >  +1: Release
> > >  -1 Do not release because ...
> > >
> > > The vote will be open for 3 days or the consensus is binding (At least
> 3
> > > binding votes).
> > >
> > > Many thanks
> > >
> > > Jon
> >
> >
> >
> >
> >
> > --
> > Sent from:
> > http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> >
>

Re: [VOTE] Release Apache TomEE 7.0.5 (round 2)

[Gurkan Erdogdu]

Hi Jon
Thanks for initiating this.
I opened a bug in Tomcat regarding java:/ namespace and it will be
corrected in 8.5.33 and upper versions. If we distribute the TomEE with
8.5.32, it will be a problem for users who uses lookups with openejb. So,
for this release we can stick to 8.5.31. WDYT?
Regards.
Gurkan


On Tue, Jul 10, 2018 at 9:26 PM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Hi Everyone,
>
> Here is the second roll of TomEE 7.0.5. Please can you take a look and
> vote? Everyone, committer or not, is encouraged to test and vote.
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1115
>
> Source zip:
> https://repository.apache.org/content/repositories/
> orgapachetomee-1115/org/apache/tomee/tomee-project/7.
> 0.5/tomee-project-7.0.5-source-release.zip
>
> Dist area:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1115/
>
> Legal:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1115/legal.zip
>
> Keys:
> https://dist.apache.org/repos/dist/release/tomee/KEYS
>
> Libraries changed since TomEE 7.0.4:
>
> Tomcat => 8.5.32
> CXF => 3.1.15
> Johnzon => 1.0.1
> OWB => 1.7.5
> XBean => 4.9
> XmlSchema core => 2.2.3
> OpenJPA => 2.4.3
>
> Changes since the last roll:
>
> - Remove javax.xml.soap-api-1.3.5.jar library which was incorrectly
> included
> - Update to Tomcat 8.5.32
> - Change JNDI name used for datasource in CDI TCK test to use an equivalent
> name under the java: namespace
>
> Changelog:
> https://issues.apache.org/jira/browse/TOMEE-2175?jql=project
> %20%3D%20TOMEE%20AND%20(status%20%3D%20Resolved%20OR%20statu
> s%20%3D%20CLOSED)%20AND%20fixVersion%20%3D%207.0.5%20O
> RDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> (If anyone knows a better way to get that list, let me know ;-) )
>
> Please vote:
>  +1: Release
>  -1 Do not release because ...
>
> The vote will be open for 3 days or the consensus is binding (At least 3
> binding votes).
>
> Many thanks
>
> Jon
>

Re: Help appreciated - Test failure: org.jboss.cdi.tck.tests.context.passivating.dependency.resource.persistence.DataSourcePassivationDependencyTest

[Gurkan Erdogdu]

I have opened a bug in Tomcat,
https://bz.apache.org/bugzilla/show_bug.cgi?id=62527

On Tue, Jul 10, 2018 at 9:12 AM, Gurkan Erdogdu  wrote:

> Hi Jon
> As you said validation error in Tomcat side. Is it possible to change
> lookup from openejb:/ to java:/ ?
> Regards.
> Gurkan
>
> On Tue, Jul 10, 2018 at 1:38 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> Corresponding Tomcat change is here:
>> http://mail-archives.apache.org/mod_mbox/tomcat-dev/201805.
>> mbox/%3c20180509151142.1276a3a0...@svn01-us-west.apache.org%3E
>>
>> TomEE resources are bound in JNDI under openejb:Resource/ so it looks like
>> this is a key issue. As far as I'm aware we don't bind resources under
>> java:, so I'm not sure how we go about fixing this at the moment.
>>
>> Thoughts?
>>
>> Jon
>>
>> On Mon, Jul 9, 2018 at 10:21 PM, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>
>> > Hey folks
>> >
>> > After updating to Tomcat 8.5.32, I have a failing
>> > test: org.jboss.cdi.tck.tests.context.passivating.dependency.resource.
>> > persistence.DataSourcePassivationDependencyTest
>> >
>> > Looks like something in web.xml is referring to openejb:Resource/jdbc,
>> > which Tomcat does not seem to like - can anyone give any pointers?
>> >
>> > Thanks
>> >
>> > Jon
>> >
>> >
>> > Here's the output for the test:
>> >
>> > ---
>> >  T E S T S
>> > ---
>> > Running TestSuite
>> > ...
>> > ... TestNG 6.8.9beta by Cédric Beust (ced...@beust.com)
>> > ...
>> >
>> > Jul 09, 2018 10:15:54 PM org.jboss.cdi.tck.impl.testng.
>> ConfigurationLoggingListener
>> > onStart
>> > INFO: CDI-TCK Implementation version: 20151104-1513
>> > Jul 09, 2018 10:15:54 PM org.jboss.cdi.tck.impl.testng.
>> ConfigurationLoggingListener
>> > onStart
>> > INFO: CDI-TCK Specification version: 1.2.8.Final
>> > Jul 09, 2018 10:15:54 PM org.jboss.cdi.tck.impl.testng.
>> ConfigurationLoggingListener
>> > onStart
>> > INFO: JSR 346 TCK Configuration
>> > -
>> > Beans: org.apache.openejb.tck.cdi.tomee.BeansImpl@3234e239
>> > Contexts: org.apache.webbeans.test.tck.ContextsImpl@3d921e20
>> > EL: org.apache.webbeans.test.tck.ELImpl@36b4cef0
>> > Library dir: /Users/jgallimore/dev/tomee/tck/cdi-tomee/target/
>> > dependency/lib/
>> > Test DS: openejb:Resource/jdbc
>> > Test JMS connection factory: openejb:Resource/jms
>> > Test JMS queue: openejb:Resource/queue
>> > Test JMS topic: openejb:Resource/topic
>> > Test timeout factor: 100
>> >
>> >
>> > Jul 09, 2018 10:15:55 PM org.apache.openejb.arquillian.common.Setup
>> > findHome
>> > INFO: Unable to find home in: /Users/jgallimore/dev/tomee/
>> > tck/cdi-tomee/target/tomee
>> > Jul 09, 2018 10:15:55 PM org.apache.openejb.arquillian.
>> common.MavenCache
>> > getArtifact
>> > INFO: Downloading org.apache.tomee:apache-tomee:7.0.5:zip:plus please
>> > wait...
>> > Jul 09, 2018 10:15:55 PM org.apache.openejb.arquillian.common.Zips
>> unzip
>> > INFO: Extracting '/Users/jgallimore/.m2/repository/org/apache/tomee/
>> > apache-tomee/7.0.5/apache-tomee-7.0.5-plus.zip' to
>> > '/Users/jgallimore/dev/tomee/tck/cdi-tomee/target/tomee'
>> > Jul 09, 2018 10:15:56 PM org.apache.tomee.arquillian.re
>> mote.RemoteTomEEContainer
>> > configure
>> > INFO: Downloaded container to: /Users/jgallimore/dev/tomee/
>> > tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.5
>> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>> PermSize=768m;
>> > support was removed in 8.0
>> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>> > MaxPermSize=1536m; support was removed in 8.0
>> > Please use CMSClassUnloadingEnabled in place of
>> CMSPermGenSweepingEnabled
>> > in the future
>> > objc[14376]: Class JavaLaunchHelper is implemented in both
>> /Library/Java/
>> > JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre/bin/java
>> > (0x10ff3a4c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_
>> > 141.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10ffc64e0). One of
>> > the two will be used. Which one is undefi

Re: Help appreciated - Test failure: org.jboss.cdi.tck.tests.context.passivating.dependency.resource.persistence.DataSourcePassivationDependencyTest

[Gurkan Erdogdu]

Hi Jon
As you said validation error in Tomcat side. Is it possible to change
lookup from openejb:/ to java:/ ?
Regards.
Gurkan

On Tue, Jul 10, 2018 at 1:38 AM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Corresponding Tomcat change is here:
> http://mail-archives.apache.org/mod_mbox/tomcat-dev/
> 201805.mbox/%3c20180509151142.1276a3a0...@svn01-us-west.apache.org%3E
>
> TomEE resources are bound in JNDI under openejb:Resource/ so it looks like
> this is a key issue. As far as I'm aware we don't bind resources under
> java:, so I'm not sure how we go about fixing this at the moment.
>
> Thoughts?
>
> Jon
>
> On Mon, Jul 9, 2018 at 10:21 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Hey folks
> >
> > After updating to Tomcat 8.5.32, I have a failing
> > test: org.jboss.cdi.tck.tests.context.passivating.dependency.resource.
> > persistence.DataSourcePassivationDependencyTest
> >
> > Looks like something in web.xml is referring to openejb:Resource/jdbc,
> > which Tomcat does not seem to like - can anyone give any pointers?
> >
> > Thanks
> >
> > Jon
> >
> >
> > Here's the output for the test:
> >
> > ---
> >  T E S T S
> > ---
> > Running TestSuite
> > ...
> > ... TestNG 6.8.9beta by Cédric Beust (ced...@beust.com)
> > ...
> >
> > Jul 09, 2018 10:15:54 PM org.jboss.cdi.tck.impl.testng.
> ConfigurationLoggingListener
> > onStart
> > INFO: CDI-TCK Implementation version: 20151104-1513
> > Jul 09, 2018 10:15:54 PM org.jboss.cdi.tck.impl.testng.
> ConfigurationLoggingListener
> > onStart
> > INFO: CDI-TCK Specification version: 1.2.8.Final
> > Jul 09, 2018 10:15:54 PM org.jboss.cdi.tck.impl.testng.
> ConfigurationLoggingListener
> > onStart
> > INFO: JSR 346 TCK Configuration
> > -
> > Beans: org.apache.openejb.tck.cdi.tomee.BeansImpl@3234e239
> > Contexts: org.apache.webbeans.test.tck.ContextsImpl@3d921e20
> > EL: org.apache.webbeans.test.tck.ELImpl@36b4cef0
> > Library dir: /Users/jgallimore/dev/tomee/tck/cdi-tomee/target/
> > dependency/lib/
> > Test DS: openejb:Resource/jdbc
> > Test JMS connection factory: openejb:Resource/jms
> > Test JMS queue: openejb:Resource/queue
> > Test JMS topic: openejb:Resource/topic
> > Test timeout factor: 100
> >
> >
> > Jul 09, 2018 10:15:55 PM org.apache.openejb.arquillian.common.Setup
> > findHome
> > INFO: Unable to find home in: /Users/jgallimore/dev/tomee/
> > tck/cdi-tomee/target/tomee
> > Jul 09, 2018 10:15:55 PM org.apache.openejb.arquillian.common.MavenCache
> > getArtifact
> > INFO: Downloading org.apache.tomee:apache-tomee:7.0.5:zip:plus please
> > wait...
> > Jul 09, 2018 10:15:55 PM org.apache.openejb.arquillian.common.Zips unzip
> > INFO: Extracting '/Users/jgallimore/.m2/repository/org/apache/tomee/
> > apache-tomee/7.0.5/apache-tomee-7.0.5-plus.zip' to
> > '/Users/jgallimore/dev/tomee/tck/cdi-tomee/target/tomee'
> > Jul 09, 2018 10:15:56 PM org.apache.tomee.arquillian.
> remote.RemoteTomEEContainer
> > configure
> > INFO: Downloaded container to: /Users/jgallimore/dev/tomee/
> > tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.5
> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=768m;
> > support was removed in 8.0
> > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> > MaxPermSize=1536m; support was removed in 8.0
> > Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled
> > in the future
> > objc[14376]: Class JavaLaunchHelper is implemented in both /Library/Java/
> > JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre/bin/java
> > (0x10ff3a4c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_
> > 141.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10ffc64e0). One of
> > the two will be used. Which one is undefined.
> > 09-Jul-2018 22:15:56.985 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > Server version:Apache Tomcat (TomEE)/8.5.32 (7.0.5)
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > Server built:  Jun 20 2018 19:50:35 UTC
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > Server number: 8.5.32.0
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > OS Name:   Mac OS X
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > OS Version:10.13.5
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > Architecture:  x86_64
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > Java Home: /Library/Java/JavaVirtualMachines/jdk1.8.0_
> > 141.jdk/Contents/Home/jre
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflect.
> NativeMethodAccessorImpl.invoke
> > JVM Version:   1.8.0_141-b15
> > 09-Jul-2018 22:15:56.986 INFO [main] sun.reflec

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

 :: Webapp Remote SUCCESS [
37.862 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests . SUCCESS [
1.934 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests :: Web Profile
SUCCESS [01:34 min]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests :: JAXRS SUCCESS [
23.558 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests :: JAXWS SUCCESS [
10.941 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests :: JMS SUCCESS [
9.822 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests :: CODI SUCCESS [
7.686 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Tests :: Configuration
Tests SUCCESS [  6.342 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Sample :: Moviefun SUCCESS
[ 24.997 s]
[INFO] OpenEJB :: Arquillian Adaptors Parent :: Arquillian TCK SUCCESS [
1.318 s]
[INFO] OpenEJB :: Utils :: Log4j2 . SUCCESS [
0.285 s]
[INFO] OpenEJB :: TomEE :: webaccess .. SUCCESS [
9.763 s]
[INFO] OpenEJB :: TomEE :: Overlay Runner . SUCCESS [
0.235 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]



On Thu, Jul 5, 2018 at 11:48 AM, Romain Manni-Bucau 
wrote:

> Hmm tests are key and even for arquillian module to run all-adapters
> profile.
>
> Id rather fix tests than excluding them and introduce potential regressions
> easily.
>
> On mac main issue is network interface selection. Should be easy to fix,
> no?
>
> Le jeu. 5 juil. 2018 10:26, Gurkan Erdogdu  a écrit :
>
> > Hi Jon
> > Now it is running the tests and let you know.
> >
> > Team,
> > I want to propose to remove some parts of the tests suite especially for
> > iTests case (some legacy tests are included ). For example, stuck at
> >
> > [INFO] Running org.apache.openejb.itest.legacy.LegacyServerTest
> > Jul 05, 2018 11:22:39 AM org.apache.openejb.itest.
> legacy.LegacyServerTest
> > test
> > INFO: Retrieving standalone server: 4.5.2 - This may take a while...
> >
> > WDYT to remove some part of tests (or remove from build) which may not be
> > so important?
> > Regards.
> > Gurkan
> >
> >
> > On Thu, Jul 5, 2018 at 11:16 AM, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > What version of MacOS are you on, and what are the specs of your
> > machine? I
> > > have a 8GB 2.5 Ghz i5 Mac mini here. Its waiting on an OS update, but I
> > can
> > > definitely update it to the latest and greatest so I'm aligned with
> you.
> > > Let me know your Maven version as well. I'll get as close to your setup
> > as
> > > I can.
> > >
> > > Jon
> > >
> > > On Thu, Jul 5, 2018 at 9:14 AM, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > Yes, I will run it on MacOS and post the results here.
> > > >
> > > > Jon
> > > >
> > > > On Thu, Jul 5, 2018 at 9:03 AM, Gurkan Erdogdu 
> > > > wrote:
> > > >
> > > >> Hi Jon
> > > >> I will try to build again but if there is a build problem in macOS,
> I
> > > >> think
> > > >> we need to find the culprit and fix it (such as test timing issue,
> or
> > > some
> > > >> other bug).
> > > >> Can you (or anybody with macOS) also try to build in macOS?
> > > >> Regards.
> > > >> Gurkan
> > > >>
> > > >> On Thu, Jul 5, 2018 at 10:58 AM, Jonathan Gallimore <
> > > >> jonathan.gallim...@gmail.com> wrote:
> > > >>
> > > >> > I note that your ticket says this must be fixed before the
> release.
> > > Can
> > > >> you
> > > >> > confirm that this means you'll be voting -1 and we will need a
> > > re-roll?
> > > >> >
> > > >> > Have you run a full build and can you provide a list of other
> > > failures?
> > > >> >
> > > >> > Jpn
> > > >> >
> > > >> > On Thu, 5 Jul 2018, 06:27 Gurkan Erdogdu, 
> > > wrote:
> > > >> >
> > > >> > > Hello Mark
> > > >> > > Here is the JIRA issue, https://issues.apache.org/jira
> > > >> /browse/TOMEE-2199
> > > >> > > Regards.
> > > >> > > Gurkan
> > > >> > >
> > > >> > > On Wed, Jul 4, 2018 a

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

Hi Jon
Now it is running the tests and let you know.

Team,
I want to propose to remove some parts of the tests suite especially for
iTests case (some legacy tests are included ). For example, stuck at

[INFO] Running org.apache.openejb.itest.legacy.LegacyServerTest
Jul 05, 2018 11:22:39 AM org.apache.openejb.itest.legacy.LegacyServerTest
test
INFO: Retrieving standalone server: 4.5.2 - This may take a while...

WDYT to remove some part of tests (or remove from build) which may not be
so important?
Regards.
Gurkan


On Thu, Jul 5, 2018 at 11:16 AM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> What version of MacOS are you on, and what are the specs of your machine? I
> have a 8GB 2.5 Ghz i5 Mac mini here. Its waiting on an OS update, but I can
> definitely update it to the latest and greatest so I'm aligned with you.
> Let me know your Maven version as well. I'll get as close to your setup as
> I can.
>
> Jon
>
> On Thu, Jul 5, 2018 at 9:14 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Yes, I will run it on MacOS and post the results here.
> >
> > Jon
> >
> > On Thu, Jul 5, 2018 at 9:03 AM, Gurkan Erdogdu 
> > wrote:
> >
> >> Hi Jon
> >> I will try to build again but if there is a build problem in macOS, I
> >> think
> >> we need to find the culprit and fix it (such as test timing issue, or
> some
> >> other bug).
> >> Can you (or anybody with macOS) also try to build in macOS?
> >> Regards.
> >> Gurkan
> >>
> >> On Thu, Jul 5, 2018 at 10:58 AM, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >>
> >> > I note that your ticket says this must be fixed before the release.
> Can
> >> you
> >> > confirm that this means you'll be voting -1 and we will need a
> re-roll?
> >> >
> >> > Have you run a full build and can you provide a list of other
> failures?
> >> >
> >> > Jpn
> >> >
> >> > On Thu, 5 Jul 2018, 06:27 Gurkan Erdogdu, 
> wrote:
> >> >
> >> > > Hello Mark
> >> > > Here is the JIRA issue, https://issues.apache.org/jira
> >> /browse/TOMEE-2199
> >> > > Regards.
> >> > > Gurkan
> >> > >
> >> > > On Wed, Jul 4, 2018 at 9:25 PM, Mark Struberg
> >>  >> > >
> >> > > wrote:
> >> > >
> >> > > > Gurkan, can you please create a ticket for this test?
> >> > > > I assume it's a randomly broken test under OSX.
> >> > > > Also have issues under OSX while it builds all green on Linux.
> >> > > >
> >> > > > LieGrue,
> >> > > > strub
> >> > > >
> >> > > > > Am 04.07.2018 um 15:24 schrieb Jonathan Gallimore <
> >> > > > jonathan.gallim...@gmail.com>:
> >> > > > >
> >> > > > > Just to confirm that a full build with tests from the tag has
> >> passed
> >> > > for
> >> > > > me.
> >> > > > >
> >> > > > > Jon
> >> > > > >
> >> > > > > On Wed, Jul 4, 2018 at 2:05 PM, Jonathan Gallimore <
> >> > > > > jonathan.gallim...@gmail.com> wrote:
> >> > > > >
> >> > > > >> That test passes here:
> >> > > > >>
> >> > > > >> Jonathans-MBP:openejb-core jgallimore$ mvn -Dtest=
> >> > > > >> BeanValidationCustomProviderTest -DfailIfNoTests=false test |
> >> tee
> >> > > > >> build.log
> >> > > > >> [INFO] Scanning for projects...
> >> > > > >> [INFO]
> >> > > > >> [INFO] ---< org.apache.tomee:openejb-core
> >> > > > >>> 
> >> > > > >> [INFO] Building OpenEJB :: Container :: Core 7.0.5
> >> > > > >> [INFO] [ jar
> >> > > > >> ]-
> >> > > > >> [INFO]
> >> > > > >> [INFO] --- maven-remote-resources-plugin:1.5:process
> >> > > > >> (process-resource-bundles) @ openejb-core ---
> >> > > > >> [INFO]
> >> > > > >> [INFO] --- maven-resources-plugin:3.0.2:resources
> >> > (default-resources)

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

Hi Jon
I will try to build again but if there is a build problem in macOS, I think
we need to find the culprit and fix it (such as test timing issue, or some
other bug).
Can you (or anybody with macOS) also try to build in macOS?
Regards.
Gurkan

On Thu, Jul 5, 2018 at 10:58 AM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> I note that your ticket says this must be fixed before the release. Can you
> confirm that this means you'll be voting -1 and we will need a re-roll?
>
> Have you run a full build and can you provide a list of other failures?
>
> Jpn
>
> On Thu, 5 Jul 2018, 06:27 Gurkan Erdogdu,  wrote:
>
> > Hello Mark
> > Here is the JIRA issue, https://issues.apache.org/jira/browse/TOMEE-2199
> > Regards.
> > Gurkan
> >
> > On Wed, Jul 4, 2018 at 9:25 PM, Mark Struberg  >
> > wrote:
> >
> > > Gurkan, can you please create a ticket for this test?
> > > I assume it's a randomly broken test under OSX.
> > > Also have issues under OSX while it builds all green on Linux.
> > >
> > > LieGrue,
> > > strub
> > >
> > > > Am 04.07.2018 um 15:24 schrieb Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com>:
> > > >
> > > > Just to confirm that a full build with tests from the tag has passed
> > for
> > > me.
> > > >
> > > > Jon
> > > >
> > > > On Wed, Jul 4, 2018 at 2:05 PM, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > >> That test passes here:
> > > >>
> > > >> Jonathans-MBP:openejb-core jgallimore$ mvn -Dtest=
> > > >> BeanValidationCustomProviderTest -DfailIfNoTests=false test | tee
> > > >> build.log
> > > >> [INFO] Scanning for projects...
> > > >> [INFO]
> > > >> [INFO] ---< org.apache.tomee:openejb-core
> > > >>> 
> > > >> [INFO] Building OpenEJB :: Container :: Core 7.0.5
> > > >> [INFO] [ jar
> > > >> ]-
> > > >> [INFO]
> > > >> [INFO] --- maven-remote-resources-plugin:1.5:process
> > > >> (process-resource-bundles) @ openejb-core ---
> > > >> [INFO]
> > > >> [INFO] --- maven-resources-plugin:3.0.2:resources
> (default-resources)
> > @
> > > >> openejb-core ---
> > > >> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > > >> [INFO] Copying 43 resources
> > > >> [INFO] Copying 3 resources
> > > >> [INFO]
> > > >> [INFO] --- maven-dependency-plugin:3.0.1:copy (copy) @ openejb-core
> > ---
> > > >> [INFO] Configured Artifact: org.apache.tomee:openejb-
> > > javaagent:7.0.5:jar
> > > >> [INFO] org.apache.tomee:openejb-javaagent:7.0.5:jar already exists
> in
> > > >> /Users/jgallimore/dev/tomee/container/openejb-core/target
> > > >> [INFO]
> > > >> [INFO] --- maven-compiler-plugin:3.6.2:compile (default-compile) @
> > > >> openejb-core ---
> > > >> [INFO] Nothing to compile - all classes are up to date
> > > >> [INFO]
> > > >> [INFO] --- dependency-report-plugin:1.0.2:report (default) @
> > > openejb-core
> > > >> ---
> > > >> [INFO]
> > > >> [INFO] --- maven-bundle-plugin:3.3.0:manifest (bundle-manifest) @
> > > >> openejb-core ---
> > > >> [INFO]
> > > >> [INFO] --- maven-antrun-plugin:1.8:run (default) @ openejb-core ---
> > > >> [INFO] Executing tasks
> > > >>
> > > >> main:
> > > >> [INFO] Executed tasks
> > > >> [INFO]
> > > >> [INFO] --- maven-resources-plugin:3.0.2:testResources
> > > >> (default-testResources) @ openejb-core ---
> > > >> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > > >> [INFO] Copying 103 resources
> > > >> [INFO] Copying 3 resources
> > > >> [INFO]
> > > >> [INFO] --- maven-dependency-plugin:3.0.1:copy
> (AlternateDriverJarTest)
> > > @
> > > >> openejb-core ---
> > > >> [INFO] Configured Artifact: org.apache.derby:derby:10.10.1.1:jar
> > > >> [INFO] Configured Artifact: org.apache.derby:derby:10.9.1.0:jar
> > > >> [INFO] org.apac

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

jb.util.LogStreamAsync run
> >> INFO: OpenWebBeans Container is starting...
> >> Jul 04, 2018 2:02:57 PM org.apache.webbeans.plugins.PluginLoader
> startUp
> >> INFO: Adding OpenWebBeansPlugin : [CdiPlugin]
> >> Jul 04, 2018 2:02:57 PM org.apache.webbeans.config.BeansDeployer
> >> validateInjectionPoints
> >> INFO: All injection points were validated successfully.
> >> Jul 04, 2018 2:02:57 PM org.apache.openejb.util.LogStreamAsync run
> >> INFO: OpenWebBeans Container has started, it took 207 ms.
> >> Jul 04, 2018 2:02:57 PM org.apache.openejb.util.LogStreamAsync run
> >> INFO: Using org.apache.openejb.bval.util.CustomValidatorProvider as
> >> validation provider.
> >> Jul 04, 2018 2:02:57 PM org.apache.openejb.util.LogStreamAsync run
> >> INFO: Created Ejb(deployment-id=ABean, ejb-name=ABean, container=Default
> >> Stateless Container)
> >> Jul 04, 2018 2:02:57 PM org.apache.openejb.util.LogStreamAsync run
> >> INFO: Started Ejb(deployment-id=ABean, ejb-name=ABean, container=Default
> >> Stateless Container)
> >> Jul 04, 2018 2:02:57 PM org.apache.openejb.util.LogStreamAsync run
> >> INFO: Deployed Application(path=/Users/jgallimore/dev/tomee/
> >> container/openejb-core/target/BeanValidationCustomProviderTest)
> >> Jul 04, 2018 2:02:57 PM org.apache.openejb.util.LogStreamAsync run
> >> INFO: Undeploying app: /Users/jgallimore/dev/tomee/
> >> container/openejb-core/target/BeanValidationCustomProviderTest
> >> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.969
> sec
> >> - in org.apache.openejb.bval.BeanValidationCustomProviderTest
> >>
> >> Results :
> >>
> >> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> >>
> >> [INFO]
> >> [INFO] --- maven-surefire-plugin:2.17:test (test-testng) @ openejb-core
> >> ---
> >> [INFO] 
> >> 
> >> [INFO] BUILD SUCCESS
> >> [INFO] 
> >> 
> >> [INFO] Total time: 22.927 s
> >> [INFO] Finished at: 2018-07-04T14:02:58+01:00
> >> [INFO] 
> >> 
> >>
> >> The build on my server is still on-going, but I can confirm that test
> has
> >> run, and passed there too.
> >>
> >> Jon
> >>
> >> On Wed, Jul 4, 2018 at 1:56 PM, Gurkan Erdogdu 
> >> wrote:
> >>
> >>> Here is the test case result part:
> >>>
> >>>  >>>> classname="org.apache.openejb.bval.BeanValidationCustomProviderTest"
> >>>> time="0.245">
> >>>> >>>> type="org.apache.openejb.OpenEJBException">

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

 Here is the test case result part:

 classname="org.apache.openejb.bval.BeanValidationCustomProviderTest"
> time="0.245">
>  type="org.apache.openejb.OpenEJBException">

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

Thank you. What is your build server, OS and JVM details?

On Wed, Jul 4, 2018 at 3:05 PM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> I'll do an explicit build against that tag on my build server now and
> confirm.
>
> Jon
>
> On Wed, Jul 4, 2018 at 12:56 PM, Gurkan Erdogdu 
> wrote:
>
> > Tried to execute mvn clean install from the root location but failed :
> > (Environment macOSX, java version "1.8.0_161")
> >
> > Results :
> >
> > Tests in error:
> >   BeanValidationCustomProviderTest.valid » OpenEJB Unable to read
> OpenEJB
> > config...
> >
> > Tests run: 3926, Failures: 0, Errors: 1, Skipped: 2
> >
> > What is your build environment? Did you run all the tests succesfully?
> >
> >
> > On Wed, Jul 4, 2018 at 2:37 PM, Matthew Broadhead <
> > matthew.broadh...@nbmlaw.co.uk.invalid> wrote:
> >
> > > i have downloaded tomee-plus-7.0.5 and have it running on my
> development
> > > machine.  everything seems fine so far.  i will let you know if there
> are
> > > any problems
> > >
> > >
> > > On 04/07/18 10:33, Jonathan Gallimore wrote:
> > >
> > >> Hi Everyone,
> > >>
> > >> Here is the initial roll of TomEE 7.0.5. Please can you take a look
> and
> > >> vote? Everyone, committer or not, is encouraged to test and vote.
> > >>
> > >> Staging repo:
> > >> https://repository.apache.org/content/repositories/
> orgapachetomee-1113
> > >>
> > >> Source zip:
> > >> /org/apache/tomee/tomee-project/7.0.5/tomee-project-7.0.5-
> > >> source-release.zip
> > >> <https://repository.apache.org/service/local/repositories/
> > >> orgapachetomee-1113/content/org/apache/tomee/tomee-
> > >> project/7.0.5/tomee-project-7.0.5-source-release.zip>
> > >>
> > >> Dist area:
> > >> https://dist.apache.org/repos/dist/dev/tomee/staging-1113/
> > >>
> > >> Legal:
> > >> https://dist.apache.org/repos/dist/dev/tomee/staging-1113/legal.zip
> > >>
> > >> Keys:
> > >> https://dist.apache.org/repos/dist/release/tomee/KEYS
> > >>
> > >> Changelog:
> > >> https://issues.apache.org/jira/browse/TOMEE-2175?jql=
> > >> project%20%3D%20TOMEE%20AND%20(status%20%3D%20Resolved%
> > >> 20OR%20status%20%3D%20CLOSED)%20AND%20fixVersion%20%3D%207.
> > >> 0.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > >>
> > >> (If anyone knows a better way to get that list, let me know ;-) )
> > >>
> > >> Please vote:
> > >>   +1: Release
> > >>   -1 Do not release because ...
> > >>
> > >> The vote will be open for 3 days or the consensus is binding (At
> least 3
> > >> binding votes).
> > >>
> > >> Many thanks
> > >>
> > >> Jon
> > >>
> > >>
> > >
> >
>

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

Tried to execute mvn clean install from the root location but failed :
(Environment macOSX, java version "1.8.0_161")

Results :

Tests in error:
  BeanValidationCustomProviderTest.valid » OpenEJB Unable to read OpenEJB
config...

Tests run: 3926, Failures: 0, Errors: 1, Skipped: 2

What is your build environment? Did you run all the tests succesfully?


On Wed, Jul 4, 2018 at 2:37 PM, Matthew Broadhead <
matthew.broadh...@nbmlaw.co.uk.invalid> wrote:

> i have downloaded tomee-plus-7.0.5 and have it running on my development
> machine.  everything seems fine so far.  i will let you know if there are
> any problems
>
>
> On 04/07/18 10:33, Jonathan Gallimore wrote:
>
>> Hi Everyone,
>>
>> Here is the initial roll of TomEE 7.0.5. Please can you take a look and
>> vote? Everyone, committer or not, is encouraged to test and vote.
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/orgapachetomee-1113
>>
>> Source zip:
>> /org/apache/tomee/tomee-project/7.0.5/tomee-project-7.0.5-
>> source-release.zip
>> > orgapachetomee-1113/content/org/apache/tomee/tomee-
>> project/7.0.5/tomee-project-7.0.5-source-release.zip>
>>
>> Dist area:
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1113/
>>
>> Legal:
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1113/legal.zip
>>
>> Keys:
>> https://dist.apache.org/repos/dist/release/tomee/KEYS
>>
>> Changelog:
>> https://issues.apache.org/jira/browse/TOMEE-2175?jql=
>> project%20%3D%20TOMEE%20AND%20(status%20%3D%20Resolved%
>> 20OR%20status%20%3D%20CLOSED)%20AND%20fixVersion%20%3D%207.
>> 0.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>
>> (If anyone knows a better way to get that list, let me know ;-) )
>>
>> Please vote:
>>   +1: Release
>>   -1 Do not release because ...
>>
>> The vote will be open for 3 days or the consensus is binding (At least 3
>> binding votes).
>>
>> Many thanks
>>
>> Jon
>>
>>
>

Re: [VOTE] Apache TomEE 7.0.5

[Gurkan Erdogdu]

Thanks Jon.
Can you also provide the github source tag URL instead of providing the
source as zip?
Regards.
Gurkan

On Wed, Jul 4, 2018 at 11:33 AM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Hi Everyone,
>
> Here is the initial roll of TomEE 7.0.5. Please can you take a look and
> vote? Everyone, committer or not, is encouraged to test and vote.
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1113
>
> Source zip:
> /org/apache/tomee/tomee-project/7.0.5/tomee-project-7.
> 0.5-source-release.zip
>  1113/content/org/apache/tomee/tomee-project/7.0.5/tomee-
> project-7.0.5-source-release.zip>
>
> Dist area:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1113/
>
> Legal:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1113/legal.zip
>
> Keys:
> https://dist.apache.org/repos/dist/release/tomee/KEYS
>
> Changelog:
> https://issues.apache.org/jira/browse/TOMEE-2175?jql=
> project%20%3D%20TOMEE%20AND%20(status%20%3D%20Resolved%
> 20OR%20status%20%3D%20CLOSED)%20AND%20fixVersion%20%3D%207.
> 0.5%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> (If anyone knows a better way to get that list, let me know ;-) )
>
> Please vote:
>  +1: Release
>  -1 Do not release because ...
>
> The vote will be open for 3 days or the consensus is binding (At least 3
> binding votes).
>
> Many thanks
>
> Jon
>

Release Guidelines

[Gurkan Erdogdu]

Hello team,
Do we have a any well-written guidelines for release procedures? If not, we
need to have one which enables the new committers to become release
managers?

Mark, Romain, Jon: Could you able to provide the some insight on this?

Any help appreciated.
Regards.
Gurkan

Re: Latest Status Release TomEE 7.0.5

[Gurkan Erdogdu]

Hi Jon
Great, thank you :) Ready to test it...
Gurkan

On Tue, Jul 3, 2018 at 11:59 AM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> I am doing it _right now_. :-)
>
> Jon
>
> On Tue, Jul 3, 2018 at 9:49 AM, Gurkan Erdogdu 
> wrote:
>
> > Hello all,
> > What is the latest status about this release? We postpone the release
> > regularly. What needs to be done to release? More than happy to help.
> > Regards.
> > Gurkan
> >
>

Latest Status Release TomEE 7.0.5

[Gurkan Erdogdu]

Hello all,
What is the latest status about this release? We postpone the release
regularly. What needs to be done to release? More than happy to help.
Regards.
Gurkan

Re: [DISCUSS] Extract examples into own git repo

[Gurkan Erdogdu]

Hi Mark
++1 for this. Examples must not be a test suite, and it is a great idea to
separate them from the main source code. It must be independently build and
execute from main TomEE codebase.
Best
Gurkan

On Wed, Jun 27, 2018 at 9:48 AM, Mark Struberg 
wrote:

> Hi folks!
>
> While trying to release TomEE-7.0.5 I figured that the Examples as part of
> the TomEE core project are really counter productive.
>
> * they break the maven-release-plugin, because they don't use the same
> version
> * They pollute the build (samples alone take 15 minutes of our build),
> which might lower contributions
> * They are bound to a specific tomee version, so they cannot easily be
> tested against another version
> * We have many people who want to probably add samples without wanting to
> go through all the hassle to build full tomee
>
> Of course there are also downsides, mainly:
> * by having the samples as part of our build we also have improved test
> coverage.
>
> Well, since right now almost nobody runs the tests when building TomEE
> (but instead rely on our CI, because it takes so long) it makes no
> difference anyway. I'd rather have a core project with decently good test
> coverage - and people also run it -  than having a bit better coverage
> which nobody runs.
>
> So I propose to move the Examples to a separate repo and add a separate CI
> for it.
> Of course we should look at how to set it up so we can have samples for
> multiple EE versions.
>
> wdyt?
>
> LieGrue,
> strub
>
>

TomEE Test Class Wiriting Rules and Documentation

[Gurkan Erdogdu]

Hi all
Currently for the https://issues.apache.org/jira/browse/TOMEE-2150 case, I
have just replicated the one of the test class to test issue scenario.
Romain said that there are some test rules

(we can add this kind of test but please don't use EJBContainer, rather an
> application composer test which avoids all the scanning which is not that
> great in our internal modules cause it is easy to get side effects. )
>

Do we have any documentation in our web site to help other developers to
understand the test writing rules? If not, we need to have one.

Currently majority of the tests does not get into this category. Problem
here is that if anybody wants to contribute to the project, one of the
thing they will do is to look at tests and replicate them.

Regards.
Gurkan

JIRA Issues

[Gurkan Erdogdu]

All,
I am now looking over TOMEE jira issues to fix them ASAP. Could you help on
this? Some of the issues have creation date very old. Any comment on the
issues are well appreciated?
Thanks.
Gurkan

Re: starting with the 7.0.5 release steps.

[Gurkan Erdogdu]

No, full Web Profile Java EE TCK

On Thu, Jun 21, 2018 at 9:24 AM, Romain Manni-Bucau 
wrote:

> Hmm, bval and cdi tck right? This is almost nothing of ee tck coverage
> sadly.
>
> Le jeu. 21 juin 2018 08:22, Gurkan Erdogdu  a écrit :
>
> > Aha 3 h is ok, assumed 13 h :) Actually I was running the TCK in my
> laptop
> > less than 3h
> >
> > On Thu, Jun 21, 2018 at 9:20 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Last time i checked it was 3h of tck - assuming you have the setup -
> and
> > 3h
> > > of tomee build (all-adapters profile to ensure we cover all tomee
> flavors
> > > and not only one as in the default build).
> > >
> > > However 3h of tck is due to a highly parallel execution (kudo David)
> and
> > > will not be that few without the full infra. So if you want to check
> some
> > > coverage it easily takes that much or more yes.
> > >
> > > Le jeu. 21 juin 2018 07:30, Gurkan Erdogdu  a
> > écrit :
> > >
> > > > Romain, do you mean that each release running with TCK takes 13h?
> > > >
> > > > On Wed, Jun 20, 2018 at 9:33 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Le mer. 20 juin 2018 à 07:59, Mark Struberg
> >  > > >
> > > > a
> > > > > écrit :
> > > > >
> > > > > > A build should work out of the box and not require 2 weeks of
> first
> > > > > fixing
> > > > > > sporadically broken unit tests.
> > > > > >
> > > > >
> > > > > A long time ago we agree the CI was the platform of truth. Indeed
> the
> > > > fixes
> > > > > are welcomed but we cant run the 13h of build locally each time
> (yes
> > > TCK
> > > > > are part of our project quality and therefore should be considered
> > part
> > > > of
> > > > > our build ;))
> > > > >
> > > > >
> > > > > >
> > > > > > And a release usually should be
> > > > > >
> > > > > > $> mvn release:prepare
> > > > > > $> mvn release:perform
> > > > > >
> > > > >
> > > > > Doesn't fit tomee cause of the lifecycle of these two tasks which
> are
> > > > > design but centralized sources (not git which allows to bypass part
> > of
> > > > the
> > > > > loonngg steps by design).
> > > > > Feel free to update the doc to the actual procedure if the existing
> > > pages
> > > > > are not that great but these steps are not the real issue we hit.
> The
> > > one
> > > > > we face is generally the review since we have a lot (did I say a
> lot?
> > > ;))
> > > > > of artifacts and this is why it got tooled in the "tools" repo (sub
> > svn
> > > > > tree).
> > > > >
> > > > > Feel free to ping me if you need help to push the artifacts, can
> > have a
> > > > > spot in the day today for that (likely beginning of the afternoon,
> > > after
> > > > it
> > > > > will be hard for me).
> > > > >
> > > > >
> > > > > >
> > > > > > that's it.
> > > > > >
> > > > > > Everything else is not really user friendly and will make it
> harder
> > > for
> > > > > > any new committer to get on board.
> > > > > > I get the argument test coverage. But some of these examples
> still
> > > use
> > > > > the
> > > > > > javaee6 apis, etc...
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > > >
> > > > > > > Am 20.06.2018 um 06:48 schrieb Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > 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
> &g

Re: starting with the 7.0.5 release steps.

[Gurkan Erdogdu]

Aha 3 h is ok, assumed 13 h :) Actually I was running the TCK in my laptop
less than 3h

On Thu, Jun 21, 2018 at 9:20 AM, Romain Manni-Bucau 
wrote:

> Last time i checked it was 3h of tck - assuming you have the setup - and 3h
> of tomee build (all-adapters profile to ensure we cover all tomee flavors
> and not only one as in the default build).
>
> However 3h of tck is due to a highly parallel execution (kudo David) and
> will not be that few without the full infra. So if you want to check some
> coverage it easily takes that much or more yes.
>
> Le jeu. 21 juin 2018 07:30, Gurkan Erdogdu  a écrit :
>
> > Romain, do you mean that each release running with TCK takes 13h?
> >
> > On Wed, Jun 20, 2018 at 9:33 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Le mer. 20 juin 2018 à 07:59, Mark Struberg  >
> > a
> > > écrit :
> > >
> > > > A build should work out of the box and not require 2 weeks of first
> > > fixing
> > > > sporadically broken unit tests.
> > > >
> > >
> > > A long time ago we agree the CI was the platform of truth. Indeed the
> > fixes
> > > are welcomed but we cant run the 13h of build locally each time (yes
> TCK
> > > are part of our project quality and therefore should be considered part
> > of
> > > our build ;))
> > >
> > >
> > > >
> > > > And a release usually should be
> > > >
> > > > $> mvn release:prepare
> > > > $> mvn release:perform
> > > >
> > >
> > > Doesn't fit tomee cause of the lifecycle of these two tasks which are
> > > design but centralized sources (not git which allows to bypass part of
> > the
> > > loonngg steps by design).
> > > Feel free to update the doc to the actual procedure if the existing
> pages
> > > are not that great but these steps are not the real issue we hit. The
> one
> > > we face is generally the review since we have a lot (did I say a lot?
> ;))
> > > of artifacts and this is why it got tooled in the "tools" repo (sub svn
> > > tree).
> > >
> > > Feel free to ping me if you need help to push the artifacts, can have a
> > > spot in the day today for that (likely beginning of the afternoon,
> after
> > it
> > > will be hard for me).
> > >
> > >
> > > >
> > > > that's it.
> > > >
> > > > Everything else is not really user friendly and will make it harder
> for
> > > > any new committer to get on board.
> > > > I get the argument test coverage. But some of these examples still
> use
> > > the
> > > > javaee6 apis, etc...
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > > > Am 20.06.2018 um 06:48 schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >:
> > > > >
> > > > > 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 <
> > > > jonathan.gallim...@gmail.com>
> > > > > 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.
> > > > >>>
> > > > >>> 

Re: starting with the 7.0.5 release steps.

[Gurkan Erdogdu]

Romain, do you mean that each release running with TCK takes 13h?

On Wed, Jun 20, 2018 at 9:33 AM, Romain Manni-Bucau 
wrote:

> Le mer. 20 juin 2018 à 07:59, Mark Struberg  a
> écrit :
>
> > A build should work out of the box and not require 2 weeks of first
> fixing
> > sporadically broken unit tests.
> >
>
> A long time ago we agree the CI was the platform of truth. Indeed the fixes
> are welcomed but we cant run the 13h of build locally each time (yes TCK
> are part of our project quality and therefore should be considered part of
> our build ;))
>
>
> >
> > And a release usually should be
> >
> > $> mvn release:prepare
> > $> mvn release:perform
> >
>
> Doesn't fit tomee cause of the lifecycle of these two tasks which are
> design but centralized sources (not git which allows to bypass part of the
> loonngg steps by design).
> Feel free to update the doc to the actual procedure if the existing pages
> are not that great but these steps are not the real issue we hit. The one
> we face is generally the review since we have a lot (did I say a lot? ;))
> of artifacts and this is why it got tooled in the "tools" repo (sub svn
> tree).
>
> Feel free to ping me if you need help to push the artifacts, can have a
> spot in the day today for that (likely beginning of the afternoon, after it
> will be hard for me).
>
>
> >
> > that's it.
> >
> > Everything else is not really user friendly and will make it harder for
> > any new committer to get on board.
> > I get the argument test coverage. But some of these examples still use
> the
> > javaee6 apis, etc...
> >
> > LieGrue,
> > strub
> >
> > > Am 20.06.2018 um 06:48 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > 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 <
> > jonathan.gallim...@gmail.com>
> > > 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
> > 
> > >>>
> > >>
> >
> >
>

Re: starting with the 7.0.5 release steps.

[Gurkan Erdogdu]

++1
I am a big supporter of easy build of the full system with couple of
commands.
What can we do to ease the build?

On Wed, Jun 20, 2018 at 8:59 AM, Mark Struberg 
wrote:

> A build should work out of the box and not require 2 weeks of first fixing
> sporadically broken unit tests.
>
> And a release usually should be
>
> $> mvn release:prepare
> $> mvn release:perform
>
> that's it.
>
> Everything else is not really user friendly and will make it harder for
> any new committer to get on board.
> I get the argument test coverage. But some of these examples still use the
> javaee6 apis, etc...
>
> LieGrue,
> strub
>
> > Am 20.06.2018 um 06:48 schrieb 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 <
> jonathan.gallim...@gmail.com>
> > 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
> 
> >>>
> >>
>
>

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

[Gurkan Erdogdu]

 Hi David+1 to merge in TomEE. Regards.Gurkan
   On Monday, March 19, 2018, 3:02:20 AM GMT+3, David Blevins 
 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: TomEE MicroProfile Dist with Config

[Gurkan Erdogdu]

Hi allYep, 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).
 
CheersGurkan

On Tuesday, March 6, 2018, 12:32:03 AM GMT+3, Romain Manni-Bucau 
 wrote:  
 
 Le 5 mars 2018 22:07, "Jonathan Gallimore"  a
écrit :

On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau 
wrote:

>
>
> Le 5 mars 2018 21:35, "Jonathan Gallimore" 
> 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 and MicroProfile

[Gurkan Erdogdu]

 Even if we use IRC or similar tools, we need to get all of these discussion to 
our mailing lists. ASF main idea is to use the mailing lists for these 
discussions. I think such decisions taken from other places really kills the 
projects and community

CheersGurkan

On Thursday, February 22, 2018, 11:38:02 AM GMT+3, Romain Manni-Bucau 
 wrote:  
 
 2018-02-22 9:35 GMT+01:00 Gurkan Erdogdu :

> >>>After all the same (active!) people are involved in most of those
> projects anyway. When you have lots of similar projects, it is not easy to
> create and maintain the healthy community , only couple of active
> developers works on these projects without general community consensus . I
> prefer to have one project which covers all of these similar technologies.
>

Except it doesn't work in practise I think - we tried and failed - cause
communities are actually different. Sadly it goes through IRC/twitter a lot
and seems mails are no more mainstream but core dev are the same, users are
not.
If we see a cost we can't pay we'll probably merge them but it is clearly
not the case today so no real point merging them and loosing users.


>
> CheersGurkan
>    On Thursday, February 22, 2018, 11:10:57 AM GMT+3, Mark Struberg
>  wrote:
>
>  > 4. Hammock: real MP server based on cdi (tomee cant be that)
> Well, MP defines just a _minimal_ requirement and a set of additional
> technologies.TomEE can easily implement these and call itself a
> MicroProfile server.
> BUT: it will be really hard to trim down TomEE to this bare minimum what
> the MP specification defines. It will always be bigger than Meecrowave or
> Hammock! But does 'bigger' mean fat? No, 40MB is certainly more weight than
> 9MB, but in most cases it doesn't even matter.In some it does though.
>
>
> For me there is a clear and concise way of scaling:
> * if you only need servlets and no DI -> use pure Tomcat * if you also
> need CDI and JAX-RS -> use Meecrowave (or Hammock)* if you need XA, JAX-WS,
> EJB, etc -> use TomEE
> After all the same (active!) people are involved in most of those projects
> anyway.
> LieGrue,strub
>    On Thursday, 22 February 2018, 07:54:27 CET, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Hi Gurkan,
>
> All has clarified after your mail:
>
> 1. Geronimo: ee* umbrella project for subspec
> 2. Meecrowave: light cxf/tomcat/johnzon/owb server (no MP target by
> itself!), name is not even on the website.
> 3. TomEE: javaee server + tomee or RA specific projects
> 4. Hammock: real MP server based on cdi (tomee cant be that)
>
> So there is no real confusion since the overlaps are very small once you
> checked out the projects IMHO.
>
> Le 22 févr. 2018 07:43, "Gurkan Erdogdu" 
> a écrit :
>
>  Hi allSeveral months ago I advised to create another profile under TomEE
> (or create another TLP project) instead of duplicating the work in
> Meecrowave project but Romain and Mark rejected. Now, come to the same
> point :) There are lots of separate projects (or subprojects, or modules)
> in Apache (Geronimo, TomEE, Meecrowave. I think all of these modules must
> belong to TomEE. Lots of users are confused with this
>
> https://lists.apache.org/thread.html/9d6058ba109f27cd74c29cd93bebfc
> e29160145723407e203e43d145@%3Cdev.openwebbeans.apache.org%3E
>
> CheersGurkan
>
>
>
>    On Thursday, February 22, 2018, 12:41:19 AM GMT+3, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Le 21 févr. 2018 22:33, "Bruno Baptista"  a écrit :
>
> Hi All,
> Is it a given that in the future we will use on TomEE both:
>
> https://github.com/apache/geronimo-config
> https://github.com/apache/geronimo-safeguard
>
> Can we assume that from now on?
>
>
> In the MP distro probably yes. Stack (dependencies) will pby be refined for
> safeguard since current one is not that friendly for tomee IMHO - tomcat
> classloading part + size - but not yet a blocker. Config is good for a
> tomee-mp.
>
> Cheers
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
>
> On 21-02-2018 18:49, Roberto Cortez wrote:
>
> > Hi guys,
> > I've been looking a little bit in how to use some of the existent Apache
> > MP implementations with TomEE and here are some ideas / conclusions.
> > MicroProfile Configuration:Using https://github.com/apache/
> geronimo-config
> .
> > Just adding the jar, plus API to TomEE libs seems to be enough.
> > MicroProfile Fault Tolerance:Using https://github
> > .com/apache/geronimo-safeguard. Added the jars and the API to TomEE libs
> > and also required to set TomEE configuration tomee.webapp.classloader.
> enrichment.prefixes
> &

Re: TomEE and MicroProfile

[Gurkan Erdogdu]

>>>After all the same (active!) people are involved in most of those projects 
>>>anyway. When you have lots of similar projects, it is not easy to create and 
>>>maintain the healthy community , only couple of active developers works on 
>>>these projects without general community consensus . I prefer to have one 
>>>project which covers all of these similar technologies.

CheersGurkan
On Thursday, February 22, 2018, 11:10:57 AM GMT+3, Mark Struberg 
 wrote:  
 
 > 4. Hammock: real MP server based on cdi (tomee cant be that)
Well, MP defines just a _minimal_ requirement and a set of additional 
technologies.TomEE can easily implement these and call itself a MicroProfile 
server.
BUT: it will be really hard to trim down TomEE to this bare minimum what the MP 
specification defines. It will always be bigger than Meecrowave or Hammock! But 
does 'bigger' mean fat? No, 40MB is certainly more weight than 9MB, but in most 
cases it doesn't even matter.In some it does though.


For me there is a clear and concise way of scaling:
* if you only need servlets and no DI -> use pure Tomcat * if you also need CDI 
and JAX-RS -> use Meecrowave (or Hammock)* if you need XA, JAX-WS, EJB, etc -> 
use TomEE
After all the same (active!) people are involved in most of those projects 
anyway.
LieGrue,strub
    On Thursday, 22 February 2018, 07:54:27 CET, Romain Manni-Bucau 
 wrote:  
 
 Hi Gurkan,

All has clarified after your mail:

1. Geronimo: ee* umbrella project for subspec
2. Meecrowave: light cxf/tomcat/johnzon/owb server (no MP target by
itself!), name is not even on the website.
3. TomEE: javaee server + tomee or RA specific projects
4. Hammock: real MP server based on cdi (tomee cant be that)

So there is no real confusion since the overlaps are very small once you
checked out the projects IMHO.

Le 22 févr. 2018 07:43, "Gurkan Erdogdu" 
a écrit :

 Hi allSeveral months ago I advised to create another profile under TomEE
(or create another TLP project) instead of duplicating the work in
Meecrowave project but Romain and Mark rejected. Now, come to the same
point :) There are lots of separate projects (or subprojects, or modules)
in Apache (Geronimo, TomEE, Meecrowave. I think all of these modules must
belong to TomEE. Lots of users are confused with this

https://lists.apache.org/thread.html/9d6058ba109f27cd74c29cd93bebfc
e29160145723407e203e43d145@%3Cdev.openwebbeans.apache.org%3E

CheersGurkan



    On Thursday, February 22, 2018, 12:41:19 AM GMT+3, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:

 Le 21 févr. 2018 22:33, "Bruno Baptista"  a écrit :

Hi All,
Is it a given that in the future we will use on TomEE both:

https://github.com/apache/geronimo-config
https://github.com/apache/geronimo-safeguard

Can we assume that from now on?


In the MP distro probably yes. Stack (dependencies) will pby be refined for
safeguard since current one is not that friendly for tomee IMHO - tomcat
classloading part + size - but not yet a blocker. Config is good for a
tomee-mp.

Cheers

Bruno Baptista
http://twitter.com/brunobat_



On 21-02-2018 18:49, Roberto Cortez wrote:

> Hi guys,
> I've been looking a little bit in how to use some of the existent Apache
> MP implementations with TomEE and here are some ideas / conclusions.
> MicroProfile Configuration:Using https://github.com/apache/geronimo-config
.
> Just adding the jar, plus API to TomEE libs seems to be enough.
> MicroProfile Fault Tolerance:Using https://github
> .com/apache/geronimo-safeguard. Added the jars and the API to TomEE libs
> and also required to set TomEE configuration tomee.webapp.classloader.
enrichment.prefixes
> to safeguard-impl. This is to add the required CDI Beans that are part of
> safeguards into the webapp context. With this, it seems to work just fine.
> If this would be part of the dist, I guess we would need to add the
> required CDI Beans into org.apache.openejb.cdi.CdiScanner.
> MicroProfile Rest Client:Apache CXF added a MP Rest Client module. The
> issue is that it is added into the 3.2.x line, which is JAX-RS 2.1. If we
> look into the MP spec, the Rest Client should be compatible with JAX-RS
> 2.0, which is implemented in CFX 3.1.x line. Upgrading TomEE to CFX 3.2.x
> doesn't really work due to the JAX-RS 2.1 dependency. As a workaround,
I've
> also tried to use just the CFX 3.2.x module lib MP Rest Client, but there
> is some dependent code. Made a few local changed and got it to work, but
> ideally, the MP Rest client should be ported back to CFX 3.1.x to support
> MP 1.3.
> Couldn't find any other Apache implementations for the other MP specs.
> I've also think that it could be interesting to distribute a TomEE flavour
> with just the MP stuff, to slim down the binary.
> Any thoughts?
> Cheers,Roberto
>    

Re: TomEE and MicroProfile

[Gurkan Erdogdu]

 Hi allSeveral months ago I advised to create another profile under TomEE (or 
create another TLP project) instead of duplicating the work in Meecrowave 
project but Romain and Mark rejected. Now, come to the same point :) There are 
lots of separate projects (or subprojects, or modules) in Apache (Geronimo, 
TomEE, Meecrowave. I think all of these modules must belong to TomEE. Lots of 
users are confused with this

https://lists.apache.org/thread.html/9d6058ba109f27cd74c29cd93bebfce29160145723407e203e43d145@%3Cdev.openwebbeans.apache.org%3E

CheersGurkan



On Thursday, February 22, 2018, 12:41:19 AM GMT+3, Romain Manni-Bucau 
 wrote:  
 
 Le 21 févr. 2018 22:33, "Bruno Baptista"  a écrit :

Hi All,
Is it a given that in the future we will use on TomEE both:

https://github.com/apache/geronimo-config
https://github.com/apache/geronimo-safeguard

Can we assume that from now on?


In the MP distro probably yes. Stack (dependencies) will pby be refined for
safeguard since current one is not that friendly for tomee IMHO - tomcat
classloading part + size - but not yet a blocker. Config is good for a
tomee-mp.

Cheers

Bruno Baptista
http://twitter.com/brunobat_



On 21-02-2018 18:49, Roberto Cortez wrote:

> Hi guys,
> I've been looking a little bit in how to use some of the existent Apache
> MP implementations with TomEE and here are some ideas / conclusions.
> MicroProfile Configuration:Using https://github.com/apache/geronimo-config.
> Just adding the jar, plus API to TomEE libs seems to be enough.
> MicroProfile Fault Tolerance:Using https://github
> .com/apache/geronimo-safeguard. Added the jars and the API to TomEE libs
> and also required to set TomEE configuration 
> tomee.webapp.classloader.enrichment.prefixes
> to safeguard-impl. This is to add the required CDI Beans that are part of
> safeguards into the webapp context. With this, it seems to work just fine.
> If this would be part of the dist, I guess we would need to add the
> required CDI Beans into org.apache.openejb.cdi.CdiScanner.
> MicroProfile Rest Client:Apache CXF added a MP Rest Client module. The
> issue is that it is added into the 3.2.x line, which is JAX-RS 2.1. If we
> look into the MP spec, the Rest Client should be compatible with JAX-RS
> 2.0, which is implemented in CFX 3.1.x line. Upgrading TomEE to CFX 3.2.x
> doesn't really work due to the JAX-RS 2.1 dependency. As a workaround, I've
> also tried to use just the CFX 3.2.x module lib MP Rest Client, but there
> is some dependent code. Made a few local changed and got it to work, but
> ideally, the MP Rest client should be ported back to CFX 3.1.x to support
> MP 1.3.
> Couldn't find any other Apache implementations for the other MP specs.
> I've also think that it could be interesting to distribute a TomEE flavour
> with just the MP stuff, to slim down the binary.
> Any thoughts?
> Cheers,Roberto
>  

Re: [Discuss] Review-than-commit 3 month trial

[Gurkan Erdogdu]

Romain>>>>@Gurkan: concretely nothing changed factually since we discussed it 
and concluded we can't pay the overhead at the moment so why pushing it?I 
looked at the commit history from github 
(https://github.com/apache/tomee/graphs/contributors). Only some couple of 
members provide contributions in last couple of years. We need a more 
stable/healthy community to increase the chance of long living the project. You 
are wrong, the reason behind the such discussion is not related with prod, 
website or project source code. We are looking for some alternative solution 
(at least temporarily) because of the mentioned problems. I suspect that this 
type of conflicts may occur in the future again. I am pushing this for the 
success and future of Apache TomEE. I am not a PMC member or committer of TomEE 
project, but I just wanted to give my comments as ASF member. 
Regards.Gurkan-





On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain Manni-Bucau 
 wrote:

@Gurkan: concretely nothing changed factually since we discussed it and
concluded we can't pay the overhead at the moment so why pushing it?
Concretely the issue was very particular in term of process cause affecting
almost directly our "prod" versus our project source doesn't and we can
therefore tolerate more latency. And side note (probably some wording issue
but just to make it obvious if not): if it is to go back to the normal
process anyway after then we can gain these 3 months and already work as we
and we'll do ;).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 7:28 GMT+02:00 Gurkan Erdogdu :

> Hi MarkThis is only for fixing the appeared (very important) problem in
> the community. So, I don't see what will happen to the project in 3 months
> period with RTC process? So, at least 3 months, every commit will be
> approved by the community via consensus. After that, we can safely return
> back to the normal process.
>
> Thanks.Gurkan
> On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark Struberg
>  wrote:
>
> RTC in my experience _only_ works on release branches, but is a total
> community killer on the mainstream branch (master, dev, whatever you call
> it).
>
> We usually don't have so many concurrent commits on the same topic. There
> was recently an exceptional case and it got resolved.
> Thus -1
>
> Of course discussions might be done first. But not via PR but via mail.
> Usually the devs have a good feeling about what is sensible and what not.
> For some deep change one usually sends a patch first for review. That is
> nothing we need to enforce - every good programmer will do just that!
> Otoh there are 99.99% of stuff which you just get done and commit it. And
> if there is something fishy, then it get's caught via the commit log mails
> anyway.
>
> LieGrue,
> strub
>
>
> > Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >
> > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins 
> > wrote:
> >
> >> There’s a discussion on the private list on this topic, but given the
> >> recent thread I think it makes sense to move that here.
> >>
> >> The vote would be only on this question:
> >>
> >>  - Is RTC worth trying for 3 months? (+1,+/-0,-1)
> >>
> >> I’ve seen some voices in favor, but do not want to propose a vote
> >> without a heads-up.  Specifically, even if many people like the idea
> >> we should talk about how we want to do it.
> >>
> >> # Review-than-commit
> >>
> >> For those that do not know, Review-than-commit is essentially what
> >> Github Pull Requests are.  Prior to github, Apache describes them as:
> >>
> >> - Commit policy which requires that all changes receive consensus
> >>  approval in order to be committed.
> >>
> >> I think we’ve seen evidence that:
> >>
> >> - Slowing ourselves down can be a good thing.
> >>
> >> - Moving ahead after discussion is a good thing.  Discussion should
> >>  precede even the first commit.
> >>
> >> - More eyes and talk around commits can help documentation efforts.
> >>
> >> - As 3 +1s are required, a one-to-one conversation with no one else
> >>  included is naturally discouraged.
> >>
> >> # Trial basis
> >>
> >> My thought is to go RTC for 3 m

Re: [Discuss] Review-than-commit 3 month trial

[Gurkan Erdogdu]

Hi MarkThis is only for fixing the appeared (very important) problem in the 
community. So, I don't see what will happen to the project in 3 months period 
with RTC process? So, at least 3 months, every commit will be approved by the 
community via consensus. After that, we can safely return back to the normal 
process.

Thanks.Gurkan
On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark Struberg 
 wrote:

RTC in my experience _only_ works on release branches, but is a total community 
killer on the mainstream branch (master, dev, whatever you call it). 

We usually don't have so many concurrent commits on the same topic. There was 
recently an exceptional case and it got resolved.
Thus -1

Of course discussions might be done first. But not via PR but via mail.
Usually the devs have a good feeling about what is sensible and what not. 
For some deep change one usually sends a patch first for review. That is 
nothing we need to enforce - every good programmer will do just that!
Otoh there are 99.99% of stuff which you just get done and commit it. And if 
there is something fishy, then it get's caught via the commit log mails anyway.

LieGrue,
strub


> Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore 
> :
> 
> On Mon, Jul 3, 2017 at 2:04 AM, David Blevins 
> wrote:
> 
>> There’s a discussion on the private list on this topic, but given the
>> recent thread I think it makes sense to move that here.
>> 
>> The vote would be only on this question:
>> 
>>  - Is RTC worth trying for 3 months? (+1,+/-0,-1)
>> 
>> I’ve seen some voices in favor, but do not want to propose a vote
>> without a heads-up.  Specifically, even if many people like the idea
>> we should talk about how we want to do it.
>> 
>> # Review-than-commit
>> 
>> For those that do not know, Review-than-commit is essentially what
>> Github Pull Requests are.  Prior to github, Apache describes them as:
>> 
>> - Commit policy which requires that all changes receive consensus
>>  approval in order to be committed.
>> 
>> I think we’ve seen evidence that:
>> 
>> - Slowing ourselves down can be a good thing.
>> 
>> - Moving ahead after discussion is a good thing.  Discussion should
>>  precede even the first commit.
>> 
>> - More eyes and talk around commits can help documentation efforts.
>> 
>> - As 3 +1s are required, a one-to-one conversation with no one else
>>  included is naturally discouraged.
>> 
>> # Trial basis
>> 
>> My thought is to go RTC for 3 months as a trial.  After 3 months, no
>> action means we revert back to our present CTR.  A new vote would be
>> required to continue RTC in any form, as-was or modified.
>> 
> 
> Unless its obviously unanimous that everyone dislikes RTC at the end of 3
> months, I'd suggest we call a vote to decide how to proceed. Not quite sure
> how that fits into +1/0/-1 however, so may be it should be a 3 month trial,
> followed by 2 weeks for review and discussion (during which we'd still be
> RTC) and then a vote?
> 
> 
>> 
>> The trial-basis is to acknowledge that we are voting on a guess of
>> potential benefits.  This allows us to "try before we buy" and the
>> vote really comes down to if we want to try.  We need not make a
>> decision based on other people's experience and have a means to gain
>> our own experience with a built-in escape clause that triggers lazily.
>> 
>> RTC may sound like a good idea, but our implemention of it may be bad
>> in practise.  It may sound like a bad idea, but we may discover
>> positives we hadn't anticipated.  We don't currently know.
>> 
>> # How would we do it?
>> 
>> Some things that would be good to discuss:
>> 
>>  - How could we use github pull requests?  Other communities do use
>>    them and I suspect there are options we have not explored.
>> 
> 
> I'd be in favour of that, as that process seems to be very well known.
> 
> 
>> 
>>  - Should all reviews be on the dev list? With Github PRs comments
>>    and JIRA comments, there needs to be a source of truth.
>> 
> 
> I think both the discussion and review should happen on the dev list.
> GH/JIRA comments are fine in themselves, but there may be (should be)
> discussion on dev@ before a PR is opened, so having all that discussion in
> one place is important for me. Even if GH comments prove popular, its not
> hard to copy/paste it to dev@ with a link.
> 
> 
>> 
>>  - Should we fully document the process before we try so we can get
>>    the most value from a 3 month trial?
>> 
> 
> I'd be in favour of discussing and documenting.
> 
> 
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com